4 ms·

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

by 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.

by xavxav 5y ago

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.