3 ms·

The flaw in the idea of "rewrite it in rust" is that, next to the memory issues, the biggest issues are logic bugs. Rewriting something from scratch isnt going

The flaw in the idea of "rewrite it in rust" is that, next to the memory issues, the biggest issues are logic bugs. Rewriting something from scratch isnt going to magically not have bugs, and the legacy system likely has many edge cases covered that a modern new implementation will have to learn about first.

Taywee 5y ago
An improvement is an improvement. A flaw of seatbelts is that some people still die when they wear them. That's not a valid argument to not wear seatbelts.
xavxav 5y ago
Right, but a memory unsafety but is what takes a harmless logic bug in an image parser with no filesystem access to an RCE and sandbox escape. Memory unsafety allows you to change the 'category' of the bug, you become free to do whatever whereas a logic bug forces to to work within the (flawed) logic of the original program.
- saagarjha 5y ago
  Not necessarily; see https://github.com/LinusHenze/Fugu14/blob/master/Writeup.pdf https://github.com/LinusHenze/Fugu14/blob/master/Writeup.pdf for example. It's a full chain that repeatedly escalates privileges without exploiting any memory safety bugs by tricking privileged subsystems into giving it more access than it should have, all the way up through and beyond kernel code execution.
  - jquery 5y ago
    That’s not a zero-click vulnerability though. I didn’t read the entire pdf but 2 of the first 4 steps involve active user participation and assistance (install exploit app 1 and exploit app 2). I think regardless, you’re right, we will still have logic bugs… but that example is also an “exception proves the rule” kind of thing.
    - saagarjha 5y ago
      It's not a zero click, that is correct. I presented it as an example of how every layers of Apple's stack, far beyond what is typically targeted by a zero-click exploit chain, can still have logic bugs that allow for privilege escalation. It's not just a memory corruption thing, although I will readily agree that trying to reduce the amount of unsafe code is a good place to start fixing these problems.
  - dcsommer 5y ago
    70% of high severity security bugs (including RCE) are due to memory unsafety. Not all, but most. It's been this way for~decades. https://news.ycombinator.com/item?id=19138602 https://news.ycombinator.com/item?id=19138602 https://www.zdnet.com/article/chrome-70-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/chrome-70-of-all-security-bugs...
  - Dagonfly 5y ago
    These Rust vs C comparison often get fixated on the, somewhat unique, memory safety advantage of Rust. But the proper comparison should be ANY modern language vs. C, cause those remove a heap of other C footguns as well. Most modern language have: - sane integers: no unsafe implicit cast, more ergonomic overflow/saturate/checked casts - sane strings: slices with length, standardized and safe UTF-8 operations - expressive typing preventing API misuse: monads like Optional/Result, mandatory exception handling, better typedefs, ADTs vs tagged unions And even without the full Rust ownership model, I'd expect the following to solve a majority of the memory safety problems: - array bounds checks (also string bounds checks) - typed alloc (alloc a specific type rather than N bytes) - non-null types by default - double-free, use-after-free analysis - thread-save std APIs In the write-up you linked, Section 2 is a missing error check => Result<T> would surface that. The macOS case contains a relative path vs string comparison => expressive typing of Path would disallow that. DriverKit exploit is a Non-NULL vs NULL API mistake. Kernel PAC is a legit ASM logic bug, but requires a confusion of kernel stack vs. user stack => might have been typed explicitly in another language.
fulafel 5y ago
It's important to have good foundations (memory safety) because then it becomes much more attractive to spend effort on the rest of the correctness and security. If you want to build a sturdy house, and see how to make the roof well, don't give up on it just because you'll need to do something else for good doors and windows.
GeekyBear 5y ago
>next to the memory issues, the biggest issues are logic bugs When you look at the percentage of security issues that derive from memory safety, it certainly makes memory safety a good place to start. >The Chromium project finds that around 70% of our serious security bugs are memory safety problems. https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet... >Around 70 percent of all the vulnerabilities in Microsoft products addressed through a security update each year are memory safety issues. https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se...

Taywee 5y ago

An improvement is an improvement. A flaw of seatbelts is that some people still die when they wear them. That's not a valid argument to not wear seatbelts.

xavxav 5y ago

Right, but a memory unsafety but is what takes a harmless logic bug in an image parser with no filesystem access to an RCE and sandbox escape. Memory unsafety allows you to change the 'category' of the bug, you become free to do whatever whereas a logic bug forces to to work within the (flawed) logic of the original program.

saagarjha 5y ago
Not necessarily; see https://github.com/LinusHenze/Fugu14/blob/master/Writeup.pdf https://github.com/LinusHenze/Fugu14/blob/master/Writeup.pdf for example. It's a full chain that repeatedly escalates privileges without exploiting any memory safety bugs by tricking privileged subsystems into giving it more access than it should have, all the way up through and beyond kernel code execution.
- jquery 5y ago
  That’s not a zero-click vulnerability though. I didn’t read the entire pdf but 2 of the first 4 steps involve active user participation and assistance (install exploit app 1 and exploit app 2). I think regardless, you’re right, we will still have logic bugs… but that example is also an “exception proves the rule” kind of thing.
  - saagarjha 5y ago
    It's not a zero click, that is correct. I presented it as an example of how every layers of Apple's stack, far beyond what is typically targeted by a zero-click exploit chain, can still have logic bugs that allow for privilege escalation. It's not just a memory corruption thing, although I will readily agree that trying to reduce the amount of unsafe code is a good place to start fixing these problems.
- dcsommer 5y ago
  70% of high severity security bugs (including RCE) are due to memory unsafety. Not all, but most. It's been this way for~decades. https://news.ycombinator.com/item?id=19138602 https://news.ycombinator.com/item?id=19138602 https://www.zdnet.com/article/chrome-70-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/chrome-70-of-all-security-bugs...
- Dagonfly 5y ago
  These Rust vs C comparison often get fixated on the, somewhat unique, memory safety advantage of Rust. But the proper comparison should be ANY modern language vs. C, cause those remove a heap of other C footguns as well. Most modern language have: - sane integers: no unsafe implicit cast, more ergonomic overflow/saturate/checked casts - sane strings: slices with length, standardized and safe UTF-8 operations - expressive typing preventing API misuse: monads like Optional/Result, mandatory exception handling, better typedefs, ADTs vs tagged unions And even without the full Rust ownership model, I'd expect the following to solve a majority of the memory safety problems: - array bounds checks (also string bounds checks) - typed alloc (alloc a specific type rather than N bytes) - non-null types by default - double-free, use-after-free analysis - thread-save std APIs In the write-up you linked, Section 2 is a missing error check => Result<T> would surface that. The macOS case contains a relative path vs string comparison => expressive typing of Path would disallow that. DriverKit exploit is a Non-NULL vs NULL API mistake. Kernel PAC is a legit ASM logic bug, but requires a confusion of kernel stack vs. user stack => might have been typed explicitly in another language.

fulafel 5y ago

It's important to have good foundations (memory safety) because then it becomes much more attractive to spend effort on the rest of the correctness and security. If you want to build a sturdy house, and see how to make the roof well, don't give up on it just because you'll need to do something else for good doors and windows.

GeekyBear 5y ago

>next to the memory issues, the biggest issues are logic bugs When you look at the percentage of security issues that derive from memory safety, it certainly makes memory safety a good place to start. >The Chromium project finds that around 70% of our serious security bugs are memory safety problems. https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet... >Around 70 percent of all the vulnerabilities in Microsoft products addressed through a security update each year are memory safety issues. https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se...