GHSA-FWHJ-785H-43HH: Denial of Service via Null Pointer Dereference in OliveTin

OliveTin exposes a REST API to manage and execute shell commands defined in its configuration. A vulnerability exists in how the application handles the lifecycle of execution tracking, specifically when invalid action identifiers are provided to the StartActionByGet endpoint. The application fails to properly validate the existence of an action binding before creating an internal execution log entry, leading to a corrupt state.

This corrupt state manifests as a "orphan" log entry where the Binding property is nil. While this initial creation does not immediately crash the server, subsequent interactions with this entry—via endpoints such as KillAction or RestartAction—assume the Binding is valid. When these handlers attempt to access properties of the nil binding, the Go runtime triggers a panic.

Because the vulnerable endpoints do not require authentication for these specific lookup operations, the vulnerability is reachable by any client with network access to the OliveTin interface. The resulting panic terminates the main server process, requiring an external restart to restore service availability.

The root cause is a logic error in the StartActionByGet handler combined with missing nil checks in downstream handlers. When StartActionByGet receives a request with a non-existent actionId, it proceeds to generate an ExecutionTrackingId and registers a log entry in the server's internal memory map. Critically, this log entry is created with a nil value for its Binding field because the requested action ID could not be resolved.

The application logic in other handlers, such as KillAction, retrieves this log entry using the ExecutionTrackingId. These handlers operate under the assumption that any existing log entry must have a valid, non-nil Binding. The code attempts to dereference entry.Binding.Action without verifying if Binding is initialized.

In the Go programming language, accessing a field of a nil pointer causes a runtime panic (specifically runtime error: invalid memory address or nil pointer dereference). Since this panic occurs on a goroutine handling an HTTP request and is not recovered, it propagates up the stack and crashes the entire application process.

The vulnerability is patched by introducing defensive checks in multiple handlers to ensure pointers are valid before dereferencing them. The fix also improves the initial validation logic to prevent the creation of invalid log entries.

Below is a conceptual representation of the vulnerable code path in KillAction and the subsequent fix applied in commit bb14c5da3e64b03f207c7f38139eb60e97c278fc.

Vulnerable Code (Before Fix):

func KillAction(w http.ResponseWriter, r *http.Request) {
    // Retrieve the log entry using the ID from the request
    entry := getLogEntry(r.FormValue("executionTrackingId"))
    
    // CRITICAL: Unsafe dereference of 'Binding'
    // If 'Binding' is nil (orphan entry), this causes a PANIC
    if entry.Binding.Action.AllowKill {
        // ... execution logic ...
    }
}

Patched Code (After Fix):

func KillAction(w http.ResponseWriter, r *http.Request) {
    entry := getLogEntry(r.FormValue("executionTrackingId"))
    
    // FIX: Explicitly check if Binding is nil before access
    if entry.Binding == nil {
        http.Error(w, "Action binding not found", http.StatusNotFound)
        return
    }
 
    // Safe access now guaranteed
    if entry.Binding.Action.AllowKill {
        // ... execution logic ...
    }
}

Similar checks were added to RestartAction, GetActionBinding, and ValidateArgumentType. Additionally, the StartAction logic was hardened to return connect.CodeNotFound immediately if an action binding cannot be resolved, preventing the creation of the orphan log entry in the first place.

Exploitation requires a two-step sequence of HTTP requests. No special tools are required; standard HTTP clients like curl or Postman are sufficient. The attacker does not need valid credentials or a valid actionId.

Step 1: Priming the State The attacker sends a GET request to StartActionByGet with an arbitrary, invalid actionId. The server responds with a valid JSON object containing an executionTrackingId, despite the action not existing. Internally, this creates the dangerous "orphan" log entry.

# Request
GET /api/v1/StartActionByGet?actionId=DOES_NOT_EXIST HTTP/1.1
Host: target-olivetin:1337
 
# Response
HTTP/1.1 200 OK
{"executionTrackingId": "29f9-corrupt-entry-id", ...}

Step 2: Triggering the Crash Using the executionTrackingId obtained in Step 1, the attacker sends a POST request to KillAction. The server attempts to process the kill request against the orphan entry, hits the nil pointer dereference, and panics.

# Request
POST /api/v1/KillAction HTTP/1.1
Host: target-olivetin:1337
Content-Type: application/json
 
{
  "executionTrackingId": "29f9-corrupt-entry-id"
}
 
# Result
# Server connection drops immediately due to process crash.

The primary impact of this vulnerability is Denial of Service (DoS). A successful exploit results in the immediate termination of the OliveTin service. Since OliveTin is often used to manage system operations or restart other services, its unavailability can disrupt administrative workflows and automation pipelines.

CVSS v3.1 Vector Analysis:

• Attack Vector (AV): Network. The API is typically exposed over the network.
• Attack Complexity (AC): Low. The exploit sequence is trivial and deterministic.
• Privileges Required (PR): None. The affected endpoints do not enforce authentication for this specific code path.
• Confidentiality (C): None. No data is leaked.
• Integrity (I): None. No data is modified (other than the process crashing).
• Availability (A): High. The service becomes completely inaccessible.

There is no potential for Remote Code Execution (RCE) or data exfiltration directly via this vulnerability; the impact is strictly limited to service availability.

The vulnerability is addressed in OliveTin version 3000.11.1. Users are advised to upgrade immediately to this version or later. The patch introduces necessary nil pointer checks and improves input validation during action initiation.

Mitigation Strategies: If an immediate upgrade is not feasible, administrators can mitigate the risk by restricting network access to the OliveTin interface. Use a reverse proxy (like Nginx or Apache) or a firewall to allow access only from trusted IP addresses. Additionally, a Web Application Firewall (WAF) can be configured to block requests to StartActionByGet where the actionId parameter does not match a known allowlist of valid action IDs.

Verification: After patching, the vulnerability can be verified as fixed by attempting the exploitation steps. The server should return a 404 Not Found or similar error code during the second step instead of terminating the connection.