Padding Oracle in Cockroachdb

Padding Oracle attacks exploit differences in error messages or timing when processing malformed ciphertext in block cipher modes like CBC. In CockroachDB, this vulnerability can surface through its SQL layer, particularly when applications use built-in cryptographic functions (e.g., pgcrypto) over its HTTP SQL API or native drivers. CockroachDB's PostgreSQL compatibility means it supports encrypt(data, key, 'aes-cbc/pkcs5') and decrypt(). If decryption errors (e.g., invalid padding vs. wrong key) are distinguishable in responses, an attacker can iteratively decrypt ciphertext without the key.

CockroachDB-Specific Attack Pattern:

• Vector: An attacker submits SQL queries via the HTTP API (/sql endpoint) or through a client application that passes user-controlled ciphertext to decrypt().
• Example Vulnerable Query:

  SELECT decrypt(decode('ciphertext_hex', 'hex'), 'secret_key', 'aes-cbc/pkcs5') FROM some_table;

  If CockroachDB returns ERROR: invalid padding for bad padding but ERROR: decryption failed for a wrong key, the attacker learns padding validity byte-by-byte.
• Error Message Differentiation: By default, CockroachDB's pgcrypto may expose distinct error strings for padding failures (e.g., "invalid data" for PKCS#5 issues) versus MAC or key errors. This is observable in HTTP responses when error_fields are included or in detailed error logs if misconfigured.

CockroachDB Code Paths at Risk:

• The decrypt function in pkg/sql/pgcodec/crypto.go (internal) unpads after decryption. If it returns pgpError with specific codes (e.g., ErrCryptoInvalidData for padding) versus ErrCryptoDecrypt for other failures, and these propagate to the client, the oracle exists.
• HTTP API responses: The /sql endpoint returns JSON with error fields that may contain these distinct messages when ?error_fields=true is used (a common debugging parameter).

Detecting a Padding Oracle in CockroachDB requires testing the decryption endpoint for error message discrepancies. Since middleBrick performs black-box scanning of API endpoints, it can probe the SQL HTTP API (http://your-cockroachdb:8080/sql) with crafted ciphertexts.

Manual Detection Steps:

1. Identify an endpoint that invokes decrypt() with user-supplied ciphertext (e.g., a GraphQL resolver or REST API that forwards SQL).
2. Send two requests:
   • Valid ciphertext (known good padding) → expect success or generic error.
   • Ciphertext with last byte altered to invalid padding → observe if error message differs (e.g., "invalid padding" vs. "decryption failed").
3. Use curl to test:

   curl -G 'http://localhost:8080/sql' \
     --data-urlencode 'q=SELECT decrypt(decode("a1b2c3", "hex"), "key", "aes-cbc/pkcs5")' \
     --data-urlencode 'error_fields=true'

   Compare responses for c40 (invalid padding) vs. c28 (other errors) PostgreSQL error codes.

Scanning with middleBrick:

middleBrick's Input Validation check automatically tests for padding oracles by submitting malformed ciphertext payloads to the target API. When scanning a CockroachDB HTTP SQL endpoint, it:

• Sends sequential probes with manipulated ciphertext blocks.
• Analyzes HTTP status codes, response bodies, and timing for distinguishable error patterns.
• Flags a finding if error messages reveal padding validity (e.g., specific error strings or differing PostgreSQL error codes).

To scan your CockroachDB HTTP API:

middlebrick scan http://your-cockroachdb:8080/sql

The report will include a prioritized finding under Input Validation with severity (likely High) and remediation guidance specific to CockroachDB.

Remediation focuses on eliminating error message differentiation and using modern encryption modes. CockroachDB provides native mechanisms to secure cryptographic operations.

1. Use AEAD Modes (e.g., AES-GCM)

AES-GCM provides authentication and does not rely on padding, nullifying padding oracles. Replace CBC with GCM in pgcrypto:

-- Vulnerable: CBC mode
SELECT decrypt(encrypt('data', 'key', 'aes-cbc/pkcs5'), 'key', 'aes-cbc/pkcs5');

-- Secure: GCM mode (authenticated, no padding)
SELECT decrypt(encrypt('data', 'key', 'aes-gcm'), 'key', 'aes-gcm');

Note: GCM requires an IV (init_vector) or uses a random one by default. Store the IV alongside the ciphertext (e.g., encrypt('data', 'key', 'aes-gcm', 'iv')).

2. Normalize Error Responses

Ensure all decryption errors return a generic message. In CockroachDB, you can wrap decryption in a plpgsql function that catches specific errors and re-raises a generic one:

CREATE OR REPLACE FUNCTION safe_decrypt(ciphertext BYTEA, key BYTEA)
RETURNS BYTEA AS $$
DECLARE
  result BYTEA;
BEGIN
  result := decrypt(ciphertext, key, 'aes-cbc/pkcs5');
  RETURN result;
EXCEPTION
  WHEN OTHERS THEN
    -- Raise a generic error without details
    RAISE EXCEPTION 'decryption failed' USING ERRCODE = 'C80000';
END;
$$ LANGUAGE plpgsql;

Then use safe_decrypt() in your queries. This prevents error string leakage.

3. Avoid User-Controlled Ciphertext in SQL

Never pass raw user input directly to decrypt(). Instead, use parameterized queries from application code (e.g., via pq or pgx drivers) so ciphertext is treated as binary data, not interpolated into SQL strings. Example in Go with pgx:

conn, _ := pgx.Connect(context.Background(), "postgresql://...")
_, err := conn.Exec(context.Background(),
  "SELECT decrypt($1, $2, 'aes-cbc/pkcs5')",
  ciphertextBytes, keyBytes)
// Errors from decrypt() will be generic if you use safe_decrypt()

4. Audit and Rotate

Review all SQL functions and application code calling decrypt(). Rotate keys if CBC was used, as past ciphertexts may be vulnerable.

Compliance Note: Padding Oracle violations map to OWASP API Top 10: A02:2021 – Cryptographic Failures and PCI-DSS Requirement 3.4 (rendering PAN unreadable). middleBrick's scoring reflects these frameworks.