4 ms·

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

by p-e-w 4y ago

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.

schemescape 4y ago
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?
- p-e-w 4y ago
  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.
- fps-hero 4y ago
  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.
- chc4 4y ago
  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.
PathOfEclipse 4y ago
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-grayscale-conversion-in-rust-by-a-factor-of-2-2-and-various-other-multimedia-related-processing-loops/#no-more-bounds https://coaxion.net/blog/2018/01/speeding-up-rgb-to-grayscal...
- danhor 4y ago
  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).
  - deleted 4y ago
    [deleted]

by p-e-w 4y ago

schemescape 4y ago

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?

p-e-w 4y ago
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.
fps-hero 4y ago
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.
chc4 4y ago
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.

PathOfEclipse 4y ago

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-grayscale-conversion-in-rust-by-a-factor-of-2-2-and-various-other-multimedia-related-processing-loops/#no-more-bounds https://coaxion.net/blog/2018/01/speeding-up-rgb-to-grayscal...

danhor 4y ago
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).
- deleted 4y ago
  [deleted]