Hacker News Reader

Comment by quietbritishjim | Hacker News Reader

> memory safety is only one aspect of writing safe, secure software

A good example of this is the SQLite documentation page "Why Is SQLite Coded In C". Among other things, it describes those memory safety issues as "the easy problems" compared to "the rather more difficult problem of computing a correct answer to an SQL statement".

Not all of our programs are like SQLite, of course (and not all of us mere mortals are like its developers). But I would certainly say that just because you've eliminated memory safety bugs doesn't mean you've eliminated all bugs. Depending on the program, you might not even have eliminated most bugs.

[1] https://www.sqlite.org/whyc.html

View on HN

Despite being an 'easy problem' it has led to code execution on android/ios:

https://research.checkpoint.com/2019/select-code_execution-f...

> We established that simply querying a database may not be as safe as you expect. Using our innovative techniques of Query Hijacking and Query Oriented Programming, we proved that memory corruption issues in SQLite can now be reliably exploited. As our permissions hierarchies become more segmented than ever, it is clear that we must rethink the boundaries of trusted/untrusted SQL input. To demonstrate these concepts, we achieved remote code execution on a password stealer backend running PHP7 and gained persistency with higher privileges on iOS. We believe that these are just a couple of use cases in the endless landscape of SQLite.

technically that's exactly the 'hard' problem, since QOP and QH are 'dealing with database problems' and not low-level problems like memory safety.

QOP/QH are not the point, they're ways to reach the existing memory corruption. Without the memory safety issue you can reach QOP/QH are not useful.

IIRC, QOP/QH though requires the somewhat unfortunate way that tables are laid out and initialized in SQLite, so it was my impression that QOP/QH are the highest order problem that needs to be patched; after all there are other types of vulns that aren't memory safety problems that are reachable with QOP/QH.

I found this part about Rust at the end particularly interesting:

> All that said, it is possible that SQLite might one day be recoded in Rust. Recoding SQLite in Go is unlikely since Go hates assert(). But Rust is a possibility. Some preconditions that must occur before SQLite is recoded in Rust include:

> Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring.

> A. Rust needs to demonstrate that it can be used to create general-purpose libraries that are callable from all other programming languages.

> B. Rust needs to demonstrate that it can produce object code that works on obscure embedded devices, including devices that lack an operating system.

> C. Rust needs to pick up the necessary tooling that enables one to do 100% branch coverage testing of the compiled binaries.

> D. Rust needs a mechanism to recover gracefully from OOM errors.

> E. Rust needs to demonstrate that it can do the kinds of work that C does in SQLite without a significant speed penalty.

There's always a new treasure to be found in the SQLite documentation. Thanks for the link.

Reply on news.ycombinator.com