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.

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

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

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.

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://www.sqlite.org/cves.html has a snippet about this, for example.

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

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

Just curious, what language was used to write the Rust compiler?

Fair point, but the Rust compiler is not there at runtime. It also only needs to be written once for all the Rust programs, so assuming Rust is safer, you restrict the unsafety to the compiler (and the unsafe constructions of Rust, which are clearly marked as unsafe if memory serves).

(the Rust compiler is written in Rust, but the LLVM backend it uses (and soon GCC, IIRC), is still written in C++)

Originally OCaml, and now Rust:

https://github.com/rust-lang/rust

Like C was used to write C and OCaml was used to write OCaml, Rust is written in Rust. Mostly, anyway, the GitHub repository seems to have also JavaScript, Python and Shell.

Though to actually get binaries out of it LLVM is used, which itself is written in C++.

Rust is written in Rust today, but it was bootstrapped in OCaml.

I said this before [1], but one severe CVE in 20 years is no reason to rewrite SQLite in a language that has no compiler for some of the platforms it is deployed on.

Sure, write new stuff in Rust, but SQLite needs to stay in C at this point.

[1]: https://news.ycombinator.com/item?id=33331841

> no reason to rewrite SQLite in [Rust]

I would like them to try, though, because I suspect, barring a Bellard Event, no-one will be able to get close to SQLite's functionality[1], reliability, etc., in a new Rust implementation within 5 years (possibly even 10 years.)

[1] including being able to load extensions, integrate into basically everything as library, etc.

If there's no way to get close to it in a certain amount of time by starting from scratch, chances are there's no chance to do it with a rewrite in the same amount of time.

And again, SQLite is used in places that Rust has no compiler for. This is a hard constraint that precludes using Rust.

Don't throw C and C++ in there together. C++ would clearly have prevented this particular CVE, if the author had used idiomatic C++ APIs.

Yeah but that is mostly the problem with C++, and I am a big C++ fanboy, too many people write C style code with C++ compilers, to the point that Bjarne keeps doing tireless keynotes about how to write idiomatic C++.

Just the other day I found a relatively recent C++ tutorial on YouTube using Turbo C++ for MS-DOS, imagine how idiomatic it looked like.

I wish people would abstain from that sort of insipid comments and offer instead suggestions about how to replace 40+ years of programming (that's just for C, BTW) and teralines of code in less than a century, and who's gonna pay for this. Because that's the crux.

The stakeholders are going to pay for it. It's not an accident that companies like Amazon and Microsoft are betting big on Rust. The cost of code quality management and vulnerability mitigation is already astronomical. If Rust can lessen that burden even a little (and it certainly can), the effort of rewriting core technologies quickly pays for itself.

And most of those "teralines" of code are legacy garbage. The core OS, a basic userland, a database and a webserver are 90% of the world's critical IT infrastructure. That doesn't take a century to rewrite.

For most of the world, though, that code is decades old, with decades of testing and battle-hardening.

You will lose all of that in a rewrite, which is why people don't do it.

I'm not arguing for or against, but:

> You will lose all of that in a rewrite

I don't think you lose everything in a rewrite in general - you still have all of the edge cases and business logic in the old code that you translate to the new code. It's not like you are implementing whatever it is from scratch.

Sure, there are opportunities for the translation to introduce regressions, but that's a vastly different argument (and I think a much more minor downside).

I’m not sure what you’d gain is worth the cost. What’s the cost in dollars and cents of SQLite cves over the past 20 years, and what would the cost be of rewriting that entire codebase?

At some point you have to come to terms with the fact that some bugs shouldn’t be fixed.

I think the cost savings is more than just the cves. You also get faster features and have to write fewer tests. You can use higher level abstractions with fewer rough edges. You may even be able to take advantage of the ecosystem more.

And you don't have to rewrite everything at once, you can do it at the function or file level bit by bit. Perhaps the parts that are changing the most are done first, or perhaps the parts with the most bugs.

I'm still not saying rewriting is always right or wrong, but I think it isn't as cut and dry as some make it sound.

> a database and a webserver

Well I have this native app fetish. I mean why pay for 4 G ram for each electron app?

No, there is more legacy code than you list there.

Hey, I have something for you. This is how my Skype looks today:

https://imgur.com/LudK5vL

Please keep those web apps.

As much as I love rewriting things in Rust, SQLite is of the least concern. With enough effort C can be made reasonably secure, and SQLite puts that effort. This particular bug wasn't a low-hanging fruit.

We don't need "rewrite everything in Rust", rather "rewrite everything in safe languages".

How would you embed SQLite into other programs if it were written in Rust? Isn't the lack of basically all dependencies the main advantage?

(I'm actually curious, how does dynamic linking work with Rust? Can you build a .so/.dll/.h pair and ship it everywhere like with C?)

You can create a dynamic library, to be linked to just like any C library, from Rust. Doing so was actually some of the first production uses of Rust ever.

everywhere depends on what you mean; rustc does have support for fewer platforms than gcc. But it's still quite a few.

Go for it?

The people who think this is the solution are the ones who will need to take up the work.

It's not like the people who don't think this is the solution will do it.

Get ready to work hard for 5, 10, 20 years... rewriting sqlite will be a monumental effort and take the laser focus of a strong development team for years, if not decades. It's fraught with risk. Think about it... how many years would it be before a stable version of sqlite based on rust was available with comparable performance and fewer bugs than the c-based version?

(Seems likely to me that it would never happen.)

I think you'd be better off creating a sqlite competitor, that could start off much smaller with a much smaller feature and much less stringent performance requirements that, nevertheless, has enough for many common cases. Of course, you'd still have to convince people to use it over sqlite. If your main selling point is "significantly fewer bugs than sqlite" I don't think it's going to be very easy to make that true, rust or not.