From 183d013b38f00d69518b1b9d46d8c45ededa9955 Mon Sep 17 00:00:00 2001
From: Austin Bonander <austin.bonander@gmail.com>
Date: Thu, 15 Aug 2024 14:59:52 -0700
Subject: [PATCH] Advisory for sqlx <= 0.8.0

https://github.com/launchbadge/sqlx/issues/3440
---
 crates/sqlx/RUSTSEC-0000-0000.md | 56 ++++++++++++++++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 crates/sqlx/RUSTSEC-0000-0000.md

diff --git a/crates/sqlx/RUSTSEC-0000-0000.md b/crates/sqlx/RUSTSEC-0000-0000.md
new file mode 100644
index 000000000..14f9e8090
--- /dev/null
+++ b/crates/sqlx/RUSTSEC-0000-0000.md
@@ -0,0 +1,56 @@
+```toml
+[advisory]
+id = "RUSTSEC-0000-0000"
+package = "sqlx"
+date = "2024-08-15"
+url = "https://github.com/launchbadge/sqlx/issues/3440"
+
+categories = ["format-injection"]
+keywords = ["sql", "injection", "overflow", "truncation"]
+
+[versions]
+# Note: WIP as of 2024-08-15
+patched = [">= 0.8.1"]
+```
+
+# Binary Protocol Misinterpretation caused by Truncating or Overflowing Casts
+
+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()`](https://docs.rs/sqlx/latest/sqlx/trait.Encode.html#method.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
+
+Work has started on a branch to add `#[deny]` directives for the following Clippy lints:
+
+* [`cast_possible_truncation`](https://rust-lang.github.io/rust-clippy/master/#/cast_possible_truncation)
+* [`cast_possible_wrap`](https://rust-lang.github.io/rust-clippy/master/#/cast_possible_wrap)
+* [`cast_sign_loss`](https://rust-lang.github.io/rust-clippy/master/#/cast_sign_loss)
+
+and to manually audit the code that they flag.
+
+A fix is expected to be included in the `0.8.1` release (still WIP as of writing).