6 ms·

This is quite clever, but fundamentally it's only possible because of a buffer overflow. If the JBIG decoder had been written in Rust (just to cite one example

This is quite clever, but fundamentally it's only possible because of a buffer overflow. If the JBIG decoder had been written in Rust (just to cite one example of a language safer than C), this would have been impossible. Use dumb languages, pwn valuable prizes.

mtoner23 5y ago
lmfao of course theres a "use rust" comment on hacker news
enlyth 5y ago
Rust, our saviour, the lord, Jesus and God itself, as is proven in every HN comment thread Edit: instant flagged for commenting anything non-positive about the Rust evangelism cult
pornel 5y ago
This case is easy. No need to rewrite: deleted code is even safer than Rust. Apart from Rust, Wuffs is also a good candidate for codecs: https://github.com/google/wuffs/blob/main/doc/wuffs-the-language.md https://github.com/google/wuffs/blob/main/doc/wuffs-the-lang... Too bad that Swift isn't that good for low-level codecs, so a Swift rewrite of Messages couldn't remove C dependencies.
- azakai 5y ago
  If the code can't be deleted then an alternative to rewriting is to sandbox it like Firefox recently started to do with wasm. That would have kept any exploit in the sandbox - let them have fun in there with that 70,000 step program where it can't touch anything... Sandboxing using wasm has around 10% overhead, so a full rewrite might end up running faster. But recompiling the code takes less time and effort and will not introduce new bugs, so it's a useful option too.
- pjmlp 5y ago
  The sandbox mentioned on the article as the mitigation done by Apple, makes use of Swift. https://googleprojectzero.blogspot.com/2021/01/a-look-at-imessage-in-ios-14.html https://googleprojectzero.blogspot.com/2021/01/a-look-at-ime...
kccqzy 5y ago
Why are you so certain? The core of the exploit is an integer overflow issue: an attacker causes a 32-bit integer to overflow by repeated addition. Rust in release mode does not check for overflow on addition. Only debug mode Rust does that.
- pjmlp 5y ago
  That was step one, it would then core dump on step two when trying to go over bounds. Naturally this could eventually be used in another way. There are no invicible fortesses, but some have enough defenses in place to keep almost everyone away or die trying, except the very resourceful ones.
optymizer 5y ago
As much as I'd like to agree with you, the real reason this is happening is because humans wrote the code and humans make mistakes. And even if you rewrite all of the software in Rust, it'll still have exploitable bugs. Does it matter if it's a buffer overflow or a rusty pan, if the end result is someone reading your device's memory?
- pjmlp 5y ago
  In a language with proper bounds checking, regardless of which one, the result of this attempt would have been a core dump. Sure there are other ways to then take advantage from killing a critical process, but it would be one attack vector less.
  - optymizer 5y ago
    You're assuming that no additional attack vector is being introduced due to features unique to Rust. In my opinion, unknown issues are worse than known issues.
- dreamcompiler 5y ago
  Since the first Fortran compiler one of the basic tenets of computer programming has been that the computer itself should help the human programmer express his/her ideas and help the human avoid basic accounting mistakes. C doesn't do the latter. Blaming the human programmer for stupid accounting mistakes is misplaced. The human's mistake was in choosing a bad language.
qalmakka 5y ago
Even if this was properly written C++ this wouldn't have worked, i.e. if the authors had used a std::vector instead of a hodgepodge of new and malloc. Even if you had overflowed the integer and used it to reserve some capacity in a vector, calling `push_back` would have reallocated the vector instead. Containers and move/by-value semantics in C++ inherently avoid a lot of stuff, it's sad seeing so many C++ developers do not actually know the language and instead stick with a "C with classes" that doesn't provide any extra security compared with C.

mtoner23 5y ago

lmfao of course theres a "use rust" comment on hacker news

enlyth 5y ago

Rust, our saviour, the lord, Jesus and God itself, as is proven in every HN comment thread Edit: instant flagged for commenting anything non-positive about the Rust evangelism cult

pornel 5y ago

This case is easy. No need to rewrite: deleted code is even safer than Rust. Apart from Rust, Wuffs is also a good candidate for codecs: https://github.com/google/wuffs/blob/main/doc/wuffs-the-language.md https://github.com/google/wuffs/blob/main/doc/wuffs-the-lang... Too bad that Swift isn't that good for low-level codecs, so a Swift rewrite of Messages couldn't remove C dependencies.

azakai 5y ago
If the code can't be deleted then an alternative to rewriting is to sandbox it like Firefox recently started to do with wasm. That would have kept any exploit in the sandbox - let them have fun in there with that 70,000 step program where it can't touch anything... Sandboxing using wasm has around 10% overhead, so a full rewrite might end up running faster. But recompiling the code takes less time and effort and will not introduce new bugs, so it's a useful option too.
pjmlp 5y ago
The sandbox mentioned on the article as the mitigation done by Apple, makes use of Swift. https://googleprojectzero.blogspot.com/2021/01/a-look-at-imessage-in-ios-14.html https://googleprojectzero.blogspot.com/2021/01/a-look-at-ime...

kccqzy 5y ago

Why are you so certain? The core of the exploit is an integer overflow issue: an attacker causes a 32-bit integer to overflow by repeated addition. Rust in release mode does not check for overflow on addition. Only debug mode Rust does that.

pjmlp 5y ago
That was step one, it would then core dump on step two when trying to go over bounds. Naturally this could eventually be used in another way. There are no invicible fortesses, but some have enough defenses in place to keep almost everyone away or die trying, except the very resourceful ones.

optymizer 5y ago

As much as I'd like to agree with you, the real reason this is happening is because humans wrote the code and humans make mistakes. And even if you rewrite all of the software in Rust, it'll still have exploitable bugs. Does it matter if it's a buffer overflow or a rusty pan, if the end result is someone reading your device's memory?

pjmlp 5y ago
In a language with proper bounds checking, regardless of which one, the result of this attempt would have been a core dump. Sure there are other ways to then take advantage from killing a critical process, but it would be one attack vector less.
- optymizer 5y ago
  You're assuming that no additional attack vector is being introduced due to features unique to Rust. In my opinion, unknown issues are worse than known issues.
dreamcompiler 5y ago
Since the first Fortran compiler one of the basic tenets of computer programming has been that the computer itself should help the human programmer express his/her ideas and help the human avoid basic accounting mistakes. C doesn't do the latter. Blaming the human programmer for stupid accounting mistakes is misplaced. The human's mistake was in choosing a bad language.

qalmakka 5y ago

Even if this was properly written C++ this wouldn't have worked, i.e. if the authors had used a std::vector instead of a hodgepodge of new and malloc. Even if you had overflowed the integer and used it to reserve some capacity in a vector, calling `push_back` would have reallocated the vector instead. Containers and move/by-value semantics in C++ inherently avoid a lot of stuff, it's sad seeing so many C++ developers do not actually know the language and instead stick with a "C with classes" that doesn't provide any extra security compared with C.