5 ms·

Sqlite is tested so thoroughly I doubt Rust's borrow checker (which is essentially just another test) would benefit it: https://www.sqlite.org/testing.html http

Sqlite is tested so thoroughly I doubt Rust's borrow checker (which is essentially just another test) would benefit it: https://www.sqlite.org/testing.html https://www.sqlite.org/testing.html Sqlite also has never had a severe CVE, from the parent's link: > All historical vulnerabilities reported against SQLite require at least one of these preconditions: > The attacker can submit and run arbitrary SQL statements. > The attacker can submit a maliciously crafted database file to the application that the application will then open and query. The OP's vulnerability requires passing an insanely long string to a C api, which isn't something you'd expect to be secure.

_flux 4y ago
> Sqlite is tested so thoroughly I doubt Rust's borrow checker (which is essentially just another test) would benefit it You may as well be correct about not helping here, but borrow checker provides proofs, not tests; a test can only prove the presence of a bug, while a proof can prove the lack of a certain kind of bug.
- Ultimatt 4y ago
  Until someone exploits the logic of the borrow checker leaving all Rust compiled programs vulnerable...
  - p-e-w 4y ago
    Sure. But that bug only needs to be fixed once, whereas bugs like the one described in the link need to be fixed again and again and again and again and...
  - oconnor663 4y ago
    You might be under the impression that the borrow checker is executing at runtime in a compiled program. But it's a purely compile-time thing, like a type checker.
counttheforks 4y ago
Isn't it? It might be naive, but I would not expect that: 1. Accepting user input on a webpage (e.g. a first_name field on a singup form) 2. Storing that user input in a database Would trigger a RCE if the string was escaped properly.
p-e-w 4y ago
It's not about the borrow checker in this case. The borrow checker deals with ownership, which mostly protects against thread safety issues, data races, and use-after-free. Here we are dealing with a memory safety problem of a type that cannot occur in Rust unless you use `unsafe` blocks. Rust doesn't allow unsafe memory access such as pointer arithmetic or out-of-bounds operations (those produce a runtime panic). C happily accepts those, and the effects may include buffer overflows leading to arbitrary code execution. This should never, ever be possible when writing a normal program. I love that Rust has named the keyword that enables such things "unsafe", because that's precisely what it is. That C has this behavior as a default is nothing short of madness, though of course C is an artifact of a time when such issues weren't understood as well as they are today.
- schemescape 4y ago
  So if SQLite was written in Rust, this would cause a runtime panic and thus would only be a denial of service CVE. Is that correct?
  - p-e-w 4y ago
    If the code were entirely analogous, that is correct, unless the Rust code used some kind of `unsafe` tricks in order to increase performance (this is fairly common in advanced Rust code). That being said, whether a runtime panic leads to DoS depends on the execution model. In web applications, threads are usually mapped to connections in some way, and a runtime panic only unwinds the thread it occurs in, so this wouldn't necessarily mean that other users experience service disruptions. More to the point, I'd expect modern application and/or library code to include default safety checks that prevent scenarios like absurdly large queries from happening in the first place, and provide recoverable errors if such pathological inputs are encountered.
  - fps-hero 4y ago
    The bug relies on undefined behaviour in the C language, but it’s exploitable is due to the way memory access operations are written in C. Equivalent Rust code would not be exploitable at a language level because that type of raw pointer array access isn’t possible with resorting to unsafe blocks. The undefined behaviour that caused the bug also doesn’t not exist in Rust.
chc4 4y ago
I have bad news for you: both Chromium and Firefox allow any page to submit arbitrary SQL statements by default, which has caused several actually-for-real exploits, most of them related to buffer overflows due to integer overflow or use after frees, both of which are mitigated in Rust. https://bugs.chromium.org/p/chromium/issues/detail?id=900910 https://bugs.chromium.org/p/chromium/issues/detail?id=900910 is a series of security SEV:HIGH bugs in Chromium and Chromecast, for example. https://bugs.chromium.org/p/chromium/issues/detail?id=1160602 https://bugs.chromium.org/p/chromium/issues/detail?id=116060... is a bug from December 2020 that is exclusively from sqlite. https://www.sqlite.org/cves.html https://www.sqlite.org/cves.html mentions this.
- jcranmer 4y ago
  > both Chromium and Firefox allow any page to submit arbitrary SQL statements by default How do you do this in Firefox? Firefox never implemented WebSQL.
  - chc4 4y ago
    Sorry, you're right; Chromium and Safari do, not Firefox.
oconnor663 4y ago
In this case Rust (or Go or Java or almost anything other than C/C++) would've caught this error with array/slice bounds checks. The borrow checker is usually more concerned with things like use-after-free, where other languages would lean on garbage collection.
- 0x457 4y ago
  Nah, in Rust out-of-bound index would be a panic, which is better than RCE. I don't think SQLite needs to be rewritten in any language, tho.
  - oconnor663 4y ago
    Yeah to be clear by "caught" I mean "crashed cleanly at runtime".
IshKebab 4y ago
> The OP's vulnerability requires passing an insanely long string to a C api, which isn't something you'd expect to be secure. Yes it is! Rust would help here - not the borrow checker, but the bounds checking.

_flux 4y ago

> Sqlite is tested so thoroughly I doubt Rust's borrow checker (which is essentially just another test) would benefit it You may as well be correct about not helping here, but borrow checker provides proofs, not tests; a test can only prove the presence of a bug, while a proof can prove the lack of a certain kind of bug.

Ultimatt 4y ago
Until someone exploits the logic of the borrow checker leaving all Rust compiled programs vulnerable...
- p-e-w 4y ago
  Sure. But that bug only needs to be fixed once, whereas bugs like the one described in the link need to be fixed again and again and again and again and...
- oconnor663 4y ago
  You might be under the impression that the borrow checker is executing at runtime in a compiled program. But it's a purely compile-time thing, like a type checker.

counttheforks 4y ago

Isn't it? It might be naive, but I would not expect that: 1. Accepting user input on a webpage (e.g. a first_name field on a singup form) 2. Storing that user input in a database Would trigger a RCE if the string was escaped properly.

p-e-w 4y ago

It's not about the borrow checker in this case. The borrow checker deals with ownership, which mostly protects against thread safety issues, data races, and use-after-free. Here we are dealing with a memory safety problem of a type that cannot occur in Rust unless you use `unsafe` blocks. Rust doesn't allow unsafe memory access such as pointer arithmetic or out-of-bounds operations (those produce a runtime panic). C happily accepts those, and the effects may include buffer overflows leading to arbitrary code execution. This should never, ever be possible when writing a normal program. I love that Rust has named the keyword that enables such things "unsafe", because that's precisely what it is. That C has this behavior as a default is nothing short of madness, though of course C is an artifact of a time when such issues weren't understood as well as they are today.

schemescape 4y ago
So if SQLite was written in Rust, this would cause a runtime panic and thus would only be a denial of service CVE. Is that correct?
- p-e-w 4y ago
  If the code were entirely analogous, that is correct, unless the Rust code used some kind of `unsafe` tricks in order to increase performance (this is fairly common in advanced Rust code). That being said, whether a runtime panic leads to DoS depends on the execution model. In web applications, threads are usually mapped to connections in some way, and a runtime panic only unwinds the thread it occurs in, so this wouldn't necessarily mean that other users experience service disruptions. More to the point, I'd expect modern application and/or library code to include default safety checks that prevent scenarios like absurdly large queries from happening in the first place, and provide recoverable errors if such pathological inputs are encountered.
- fps-hero 4y ago
  The bug relies on undefined behaviour in the C language, but it’s exploitable is due to the way memory access operations are written in C. Equivalent Rust code would not be exploitable at a language level because that type of raw pointer array access isn’t possible with resorting to unsafe blocks. The undefined behaviour that caused the bug also doesn’t not exist in Rust.

chc4 4y ago

I have bad news for you: both Chromium and Firefox allow any page to submit arbitrary SQL statements by default, which has caused several actually-for-real exploits, most of them related to buffer overflows due to integer overflow or use after frees, both of which are mitigated in Rust. https://bugs.chromium.org/p/chromium/issues/detail?id=900910 https://bugs.chromium.org/p/chromium/issues/detail?id=900910 is a series of security SEV:HIGH bugs in Chromium and Chromecast, for example. https://bugs.chromium.org/p/chromium/issues/detail?id=1160602 https://bugs.chromium.org/p/chromium/issues/detail?id=116060... is a bug from December 2020 that is exclusively from sqlite. https://www.sqlite.org/cves.html https://www.sqlite.org/cves.html mentions this.

jcranmer 4y ago
> both Chromium and Firefox allow any page to submit arbitrary SQL statements by default How do you do this in Firefox? Firefox never implemented WebSQL.
- chc4 4y ago
  Sorry, you're right; Chromium and Safari do, not Firefox.

oconnor663 4y ago

In this case Rust (or Go or Java or almost anything other than C/C++) would've caught this error with array/slice bounds checks. The borrow checker is usually more concerned with things like use-after-free, where other languages would lean on garbage collection.

0x457 4y ago
Nah, in Rust out-of-bound index would be a panic, which is better than RCE. I don't think SQLite needs to be rewritten in any language, tho.
- oconnor663 4y ago
  Yeah to be clear by "caught" I mean "crashed cleanly at runtime".

IshKebab 4y ago

> The OP's vulnerability requires passing an insanely long string to a C api, which isn't something you'd expect to be secure. Yes it is! Rust would help here - not the borrow checker, but the bounds checking.