5 ms·

It's bugs like this one that lead me to believe that yes, "rewrite everything in Rust" is in fact the solution. I have the greatest respect for the quality of

by p-e-w 4y ago

It's bugs like this one that lead me to believe that yes, "rewrite everything in Rust" is in fact the solution. I have the greatest respect for the quality of the SQLite codebase, which is one of the best-tested open source projects in existence, but at the end of the day, if formatting a string can lead to arbitrary code execution, it's time to question the foundations you're building on. As long as C and C++ are considered acceptable languages for writing mission critical software, these vulnerabilities will never go away. We have incredible static analysis tools and hyper-advanced fuzzers driven by genetic algorithms, and yet this continues to happen despite every precaution imaginable being taken. It's time to fix the problem at its root. Languages that are memory unsafe by default need to be phased out sooner rather than later.

chmaynard 4y ago
Just curious, what language was used to write the Rust compiler?
- _flux 4y ago
  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++.
  - xxpor 4y ago
    Rust is written in Rust today, but it was bootstrapped in OCaml.
- nequo 4y ago
  Originally OCaml, and now Rust: https://github.com/rust-lang/rust https://github.com/rust-lang/rust
- jraph 4y ago
  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++)
- deleted 4y ago
  [deleted]
tinalumfoil 4y ago
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.
deleted 4y ago
[deleted]
ghoward 4y ago
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 https://news.ycombinator.com/item?id=33331841
- zimpenfish 4y ago
  > 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.
  - ghoward 4y ago
    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.
jeffbee 4y ago
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.
- pjmlp 4y ago
  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.
astrobe_ 4y ago
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.
- p-e-w 4y ago
  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.
  - pclmulqdq 4y ago
    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.
    - jjnoakes 4y ago
      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).
      - pittmajp 4y ago
        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.
pornel 4y ago
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.
pjmlp 4y ago
We don't need "rewrite everything in Rust", rather "rewrite everything in safe languages".
0x000xca0xfe 4y ago
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?)
- steveklabnik 4y ago
  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.
jmull 4y ago
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.

by p-e-w 4y ago

chmaynard 4y ago

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

_flux 4y ago
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++.
- xxpor 4y ago
  Rust is written in Rust today, but it was bootstrapped in OCaml.
nequo 4y ago
Originally OCaml, and now Rust: https://github.com/rust-lang/rust https://github.com/rust-lang/rust
jraph 4y ago
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++)
deleted 4y ago
[deleted]

tinalumfoil 4y ago

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.

deleted 4y ago

[deleted]

ghoward 4y ago

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 https://news.ycombinator.com/item?id=33331841

zimpenfish 4y ago
> 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.
- ghoward 4y ago
  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.

jeffbee 4y ago

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.

pjmlp 4y ago
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.

astrobe_ 4y ago

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.

p-e-w 4y ago
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.
- pclmulqdq 4y ago
  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.
  - jjnoakes 4y ago
    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).
    - pittmajp 4y ago
      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.

pornel 4y ago

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.

pjmlp 4y ago

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

0x000xca0xfe 4y ago

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

steveklabnik 4y ago
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.

jmull 4y ago

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.