T05 · Unauthorized Access and Privilege Escalation
Warning
- Location
- scripts/proposal-service.sh:4
- Finding
- Database Operations Use Docker Access and the PostgreSQL Superuser<![CDATA[ ## Vulnerability Details **File Location**: `scripts/proposal-service.sh`, lines 4-6, 20, and 50 **Vulnerability Type**: T05: Unauthorized Access and Privilege Escalation **Risk Level**: Medium ### Vulnerable Code ```sh DB_CONTAINER="supabase-db" DB_USER="postgres" DB_NAME="postgres" ``` ```sh docker exec -i "$DB_CONTAINER" psql -U "$DB_USER" -d "$DB_NAME" -At -F $'\t' <<'SQL' ``` ```sh docker exec -i "$DB_CONTAINER" psql -U "$DB_USER" -d "$DB_NAME" <<SQL ``` ### Technical Analysis The script enters the database container through `docker exec` and runs both workflows as the PostgreSQL `postgres` superuser. The documented task only requires: - Reading `public.openclaw_trigger_rules` - Reading `public.openclaw_missions` - Reading and inserting records in `public.openclaw_proposals` The PostgreSQL superuser is not constrained to those operations. It can generally bypass database permission checks, manage roles, access unrelated schemas and tables, alter database objects, and perform destructive administrative actions. Access to the Docker daemon or an equivalent `docker exec` capability also represents a powerful container-control boundary. The current SQL statements do not misuse these privileges, and the script does not accept user-controlled SQL. Nevertheless, the execution model violates least privilege and increases the consequences of script modification, invocation-environment compromise, or unauthorized use of the same execution channel. ### Attack Path 1. An attacker gains the ability to modify `scripts/proposal-service.sh`, influence its execution environment, or execute equivalent commands under the account authorized to run this Skill. 2. The attacker reuses access to the `supabase-db` container through `docker exec`. 3. The attacker connects to the `postgres` database as the hardcoded `postgres` superuser. 4. Instead of executing only the intended proposal queries, the attacker submits arbitrary administrative SQL. 5. The attacke ...[truncated 952 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Create a dedicated PostgreSQL login role for this service rather than using `postgres`. 2. Grant only the minimum required privileges: - `CONNECT` on the required database - `USAGE` on schema `public` - `SELECT` on `public.openclaw_trigger_rules` - `SELECT` on `public.openclaw_missions` - `SELECT` and `INSERT` on `public.openclaw_proposals` - Any narrowly required sequence privilege if proposal identifiers use a sequence 3. Explicitly revoke unnecessary schema, table, role-management, DDL, and administrative privileges from the service role. 4. Prefer a narrowly scoped database connection over `docker exec`, so running the Skill does not require access to the Docker control plane. 5. Store database credentials in a protected secret mechanism rather than embedding privileged account details in the script. 6. Restrict script ownership and write permissions so the account invoking the Skill cannot modify the script. 7. Where feasible, encapsulate proposal creation in a security-reviewed stored procedure with explicit validation and grant the service role only permission to execute that procedure. 8. Add database constraints or a suitable unique index to enforce duplicate-prevention invariants atomically, rather than relying solely on a procedural existence check. ]]>