Curio's Confessional: Leaking Database Credentials via Verbose HTTP Errors

Curio is the heavy lifter of the Filecoin ecosystem. It's the machinery that helps storage providers seal sectors, prove storage, and ultimately earn FIL. It is a complex distributed system that relies heavily on a central nervous system: the database (typically YugabyteDB or PostgreSQL). This database holds the state of every deal, every sector, and the financial tracking for the operation.

Now, imagine if that central nervous system decided to print its access codes on a billboard every time it had a hiccup. That is essentially what happened here. In the world of distributed systems, "observability" is a buzzword everyone loves. We want logs, we want metrics, we want to know why things failed. But there is a fine line between helpful debugging information and catastrophic oversharing.

This vulnerability is a classic case of "The Road to Hell is Paved with Good Intentions." The developers wanted to make sure that when the database connection failed, the user (or the log) knew exactly why. Unfortunately, the "why" included the "how"—specifically, the postgresql://user:password@host connection string.

The root cause here is a beautiful, tragic collaboration between two components: the Go pgx database driver and Curio's HTTP error handlers.

First, let's look at the pgx driver. When pgx fails to connect or encounters a fatal error, it generates an error object. To be helpful, the string representation of this error often includes the configuration that failed. If you initialize your connection using a DSN (Data Source Name) string like postgres://admin:SuperSecret@127.0.0.1:5432/db, the driver treats that string as a fundamental property of the connection context.

Second, we have the Curio HTTP handlers. In over 18 different locations—specifically in pdp/handlers.go and market/mk12—the code followed a pattern that every junior developer is taught to avoid in production: piping err.Error() directly to the HTTP response.

It looked something like this:

if err := db.DoSomething(); err != nil {
    // "Hey client, here is exactly what went wrong, including my secrets!"
    http.Error(w, err.Error(), http.StatusInternalServerError)
    return
}

When the database operation fails, err.Error() returns the pgx error, which contains the DSN, which contains the password. The server essentially vomits its own credentials back to the requester. It's the digital equivalent of a bank teller shouting the vault combination because the vault door is stuck.

Let's look at the fix in commit 551da78e to understand the severity. The patch reveals exactly how the credentials were being mishandled.

The Vulnerable Pattern (Before):

Originally, the connection string was built by blindly concatenating the password into the URL. This URL was then passed to the driver, making it part of the driver's error context.

// The "Before" logic (pseudocode based on patch analysis)
dsn := fmt.Sprintf("postgres://%s:%s@%s:%s/%s",
    user, password, host, port, dbName)
config, err := pgxpool.ParseConfig(dsn)

The Fix (After):

The remediation strategy was two-fold. First, stop putting the password in the URL string. Second, explicitly sanitize error messages before they leave the boundary.

// The "After" logic
// 1. Construct DSN *without* the password
dsn := fmt.Sprintf("postgres://%s@%s:%s/%s", user, host, port, dbName)
config, err := pgxpool.ParseConfig(dsn)
 
// 2. Inject password directly into the config struct
// This keeps it out of the DSN string representation
config.ConnConfig.Password = password

Furthermore, the developers introduced a new errFilter function. This function acts as a firewall for error strings, frantically scrubbing sensitive keywords before they hit the logs or the HTTP response:

func errFilter(err error) error {
    if err == nil { return nil }
    msg := err.Error()
    // Redact sensitive patterns
    msg = strings.ReplaceAll(msg, password, "********")
    // ... other redactions ...
    return errors.New(msg)
}

They essentially had to build a censorship layer for their own application because the driver was too honest.

Exploiting this does not require complex heap spraying or ROP chains. It requires network access (often authenticated, depending on the specific endpoint configuration) and the ability to annoy the database.

The Attack Chain:

1. Recon: Identify a Curio instance. This is typically port 1234 or similar on a Filecoin miner's infrastructure.
2. Access: Authenticate if necessary. The advisory notes that pdp handlers (ECDSA JWT auth) and market handlers are affected. In a multi-tenant or cluster environment, low-privilege access is often sufficient.
3. Trigger: Send a request designed to fail at the database layer. This could be a malformed query parameter, a request for a non-existent deal ID that forces a bad lookup, or even flooding the connection pool to force a timeout error.
4. Harvest: Read the HTTP 500 response body.

Example Response:

HTTP/1.1 500 Internal Server Error
Content-Type: text/plain
 
failed to connect to `host=10.0.0.5 user=curio password=CorrectHorseBatteryStaple dbname=yugabyte`: dial tcp 10.0.0.5:5433: connect: connection refused

Just like that, the attacker has the username, password, hostname, and database name. They can now connect directly to the YugabyteDB instance, bypassing Curio entirely. From there, they can modify balances, delete sectors, or ransom the storage cluster.

Why is this a "drop everything and patch" situation? Because the database is the source of truth for the Filecoin storage provider.

If an attacker gains direct SQL access via the leaked credentials:

• Financial Theft: They could potentially manipulate deal states or drain wallets if private keys are accessible (though usually keys are in a separate Lotus node, the market state is in Curio).
• Denial of Service: DROP DATABASE curio;. Game over. The storage provider loses track of where data is stored on disk, leading to slashing and loss of collateral.
• Data Integrity: Subtle modification of sector metadata could cause the miner to submit invalid proofs, leading to penalization by the network.

This is not just an information leak; it is a full compromise of the storage cluster's control plane. The CVSS score might say 7.5, but for a storage provider holding millions of dollars in collateral, the business impact is a solid 10.0.