The following presentation at this year's DEF CON was brought to our attention on the SQLx Discord:

SQL Injection isn't Dead: Smuggling Queries at the Protocol Level
http://web.archive.org/web/20240812130923/https://media.defcon.org/DEF%20CON%2032/DEF%20CON%2032%20presentations/DEF%20CON%2032%20-%20Paul%20Gerste%20-%20SQL%20Injection%20Isn't%20Dead%20Smuggling%20Queries%20at%20the%20Protocol%20Level.pdf
(Archive link for posterity.)

Essentially, encoding a value larger than 4GiB can cause the length prefix in the protocol to overflow, causing the server to interpret the rest of the string as binary protocol commands or other data.

It appears SQLx does perform truncating casts in a way that could be problematic, for example: https://github.com/launchbadge/sqlx/blob/6f2905695b9606b5f51b40ce10af63ac9e696bb8/sqlx-postgres/src/arguments.rs#L163

This code has existed essentially since the beginning, so it is reasonable to assume that all published versions <= 0.8.0 are affected.

Mitigation

As always, you should make sure your application is validating untrustworthy user input. Reject any input over 4 GiB, or any input that could encode to a string longer than 4 GiB. Dynamically built queries are also potentially problematic if it pushes the message size over this 4 GiB bound.

Encode::size_hint() can be used for sanity checks, but do not assume that the size returned is accurate. For example, the Json<T> and Text<T> adapters have no reasonable way to predict or estimate the final encoded size, so they just return size_of::<T>() instead.

For web application backends, consider adding some middleware that limits the size of request bodies by default.

Resolution

sqlx 0.8.1 has been released with the fix: https://github.com/launchbadge/sqlx/blob/main/CHANGELOG.md#081---2024-08-23

Postgres users are advised to upgrade ASAP as a possible exploit has been demonstrated: https://github.com/launchbadge/sqlx/issues/3440#issuecomment-2307956901

MySQL and SQLite do not appear to be exploitable, but upgrading is recommended nonetheless.

Diesel allows users to configure various options for PostgreSQL's COPY FROM and COPY TO statements. These configurations are partially provided as strings or characters.

Diesel did not check if any these user-provided options contain a quote character ', which can lead to the injection of additional options in the current COPY FROM/COPY TO statement.

This vulnerability affects any user of COPY FROM/COPY TO that passes user-provided input to any of the affected functions. It can result in modifications of options in the current statement, but it is not possible inject additional statements.

Mitigation

The preferred mitigation to the outlined problem is to update to Diesel version 2.3.8 or newer, which includes fixes for the problem.

Resolution

Diesel now correctly escapes any quotes contained in the provided arguments.

Diesel allows to register custom aggregate SQL functions for SQLite via the SqliteAggregate interface.

To store an instance of the custom aggregate processor Diesel relied on the sqlite3_aggregate_context function provided by sqlite. This function doesn't provide any guarantees about alignment of the returned allocation, which in turn can lead to problems if the type implementing requires a special alignment, e.g. via a custom #[align(x)] attribute on the type implementing this trait. This affects any user of SqliteAggregate that registers the custom aggregate function with an SQLite connection, while using a non-standard alignment on the type implementing this trait.

Mitigation

The preferred mitigation to the outlined problem is to update to a Diesel version 2.3.8 or newer, which includes fixes for the problem.

Resolution

Diesel now allocates the corresponding memory on Rust side to get a correctly aligned allocation.

A malicious or compromised server can send a row containing fewer fields than its row description declares columns. Reading one of the missing columns then panics with an out-of-bounds index, aborting the calling task. This affects even the otherwise non-panicking try_get, and both Row and SimpleQueryRow.

Applications that connect only to a trusted database are not exposed; the risk applies to clients that may connect to untrusted or user-supplied servers, or whose connection can be intercepted by a man-in-the-middle.

A malicious, compromised, or man-in-the-middle server can supply an arbitrarily large SCRAM-SHA-256 PBKDF2 iteration count during authentication. The client runs it inline with no upper bound, pinning a tokio worker thread for minutes per connection, possibly stalling the whole async runtime.

Applications that connect only to a trusted database are not exposed; the risk applies to clients that may connect to untrusted or user-supplied servers, or whose connection can be intercepted by a man-in-the-middle.

A malicious or compromised server can return a binary hstore value with an invalid internal length field, causing the client to panic while decoding it.

Applications that connect only to a trusted database are not exposed; the risk applies to clients that may connect to untrusted or user-supplied servers, or whose connection can be intercepted by a man-in-the-middle.