Hacker News Reader

Comment by tinalumfoil | Hacker News Reader

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

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.

View on HN

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.

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?

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.

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.

Yes. If you index out of bounds in a Rust program, it will raise a panic. This is infinitely better than causing memory unsafety and creating a remote code execution exploit, and the best you can possibly do.

If your bounds checks can make your programs as much as twice as slow, then I think it's worth considering that bounds checking is not a panacea for low-level code: https://coaxion.net/blog/2018/01/speeding-up-rgb-to-grayscal...

If the compiler can be sure that there is no bounds checking needed and can skip it. Rust provides facilities for this, C and C++ less so.

We have seen time and time again that humans aren't good enugh at that task, even in low-level code (and 2x is very buch an outlier).

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 is a series of security SEV:HIGH bugs in Chromium and Chromecast, for example. 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 mentions this.

> 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.

Sorry, you're right; Chromium and Safari do, not Firefox.

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.

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.

Yeah to be clear by "caught" I mean "crashed cleanly at runtime".

> 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.

Until someone exploits the logic of the borrow checker leaving all Rust compiled programs vulnerable...

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...

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.

> 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.

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.

Reply on news.ycombinator.com