Hacker News Reader

Comment by _vvhw | Hacker News Reader

It's important to clarify that memory safety is only one aspect of writing safe, secure software.

To this list then I would also want to add and compare: OOM-safety under overload conditions, and fine-grained error handling safety, in particular because error handling tends to be one of the leading causes of faults in distributed systems [1].

To be fair, I was surprised that Rust did not have checked arithmetic on by default and that this needs to be turned on via compiler setting or linted against. The presence of integer overflow in a program can facilitate a whole range of exploits, even with memory safety.

[1] - https://www.eecg.utoronto.ca/~yuan/papers/failure_analysis_o...

View on HN

> 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

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

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.

> The presence of integer overflow in a program can facilitate a whole range of exploits, even with memory safety.

Do you have examples that do not involve array indexing? (which are uncommon in Rust because iterators exist and are faster).

Sure, almost anything that uses numbers, e.g. to control access or parse data structures or do "something important", here are two off the top of my head:

* Rate limits for an OTP, which could be trivially reset through overflow.

* Parsing zip files, where the hostile content is self-referencing, to sneak in cyclic references for a DoS, or to change file extension type for code execution after bypassing a content filter, or to change output destination (e.g. as part of a symbolic link or directory traversal) to overwrite system files.

Unchecked arithmetic for me is by far one of the scariest exploit vectors because it's so easy to do, and one of the first things a trained attacker would look for.

Programs in any language are always exploitable, in some way or another. Memory safety is no guarantee that a program is "safe" let alone correct.

Thanks for the examples.

Hey it's a pleasure!

> Rust did not have checked arithmetic on by default

Except it does, in debug mode, which is the default compilation mode. And you don't have to tweak compiler settings or linters to get checked arithmetic in release: you simply call the checked arithmetic functions, which give the added benefit of giving you complete freedom in how to handle overflow.

Wherever you 'learned' this misinformation from, please stop considering it a trustworthy source :(

Reply on news.ycombinator.com