20 ms·

"unsafe implementation language" is a pretty moot point. Looking at all the trivial exploits against web applications which are basically never written in memo

"unsafe implementation language" is a pretty moot point. Looking at all the trivial exploits against web applications which are basically never written in memory-unsafe languages (Ruby, Python, PHP, ...) shows that it doesn't really matter much. While having the same implementation in a memory unsafe language would be slightly less safe, it's very unlikely that a heap corruption could be exploited remotely.

pjmlp 7y ago
Morris Worm. About 70% of CVE reported exploits are due to memory corruption. Living with the remaining 30% would already be a huge security improvement.
- Vogtinator 7y ago
  The Morris Worm happened back when security was not really a big concern. Memory corruption is much harder (and in most cases realistically not at all) to exploit beyond a DoS, and that's what you would get with "safe" languages such as Rust or Python as well. Heartbleed, Shellshock, Dirty COW etc. would all happen exactly the same way in different programming languages. Yes, there is clearly a benefit in using something which makes it much harder introducing memory safety issues, but it's not nearly as big as many here on HN think.
  - pjmlp 7y ago
    Yet we keep having those yearly 70%, go figure.
  - missblit 7y ago
    Didn't Heartbleed rely on reading uninitialized data? I'd assume memory safety includes preventing code from reading uninitialized data.
    - staticassertion 7y ago
      Yes, and correct.
  - staticassertion 7y ago
    Most recent (and the first public) Chrome ITW attack used memory corruption attack. One to exploit the renderer, another to exploit the underlying kernel to escape the sandbox. I believe the same is true (roughly) with the Coinbase attack that went after Firefox. In short, memory safety is not only responsible for the majority of reported vulns, but also the exploited ones, at least in the case of browsers. > Heartbleed, Shellshock, Dirty COW etc. would all happen exactly the same way in different programming languages. Heartbleed is impossible in a memory safe language, at the least. Same with cloudbleed for that matter. DirtyCow and shellshock, sure. It's a bit of a moot point though - human energy is finite, consider if we could spend energy on problems like DirtyCow and shellshock instead of memory safety issues that simply don't exist in many languages.
staticassertion 7y ago
> Security engineers in general, very much including Chrome Security Team, would like to advance the state of engineering to where memory safety issues are much more rare. Then, we could focus more attention on the application-semantic vulnerabilities. That would be a big improvement.

pjmlp 7y ago

Morris Worm. About 70% of CVE reported exploits are due to memory corruption. Living with the remaining 30% would already be a huge security improvement.

Vogtinator 7y ago
The Morris Worm happened back when security was not really a big concern. Memory corruption is much harder (and in most cases realistically not at all) to exploit beyond a DoS, and that's what you would get with "safe" languages such as Rust or Python as well. Heartbleed, Shellshock, Dirty COW etc. would all happen exactly the same way in different programming languages. Yes, there is clearly a benefit in using something which makes it much harder introducing memory safety issues, but it's not nearly as big as many here on HN think.
- pjmlp 7y ago
  Yet we keep having those yearly 70%, go figure.
- missblit 7y ago
  Didn't Heartbleed rely on reading uninitialized data? I'd assume memory safety includes preventing code from reading uninitialized data.
  - staticassertion 7y ago
    Yes, and correct.
- staticassertion 7y ago
  Most recent (and the first public) Chrome ITW attack used memory corruption attack. One to exploit the renderer, another to exploit the underlying kernel to escape the sandbox. I believe the same is true (roughly) with the Coinbase attack that went after Firefox. In short, memory safety is not only responsible for the majority of reported vulns, but also the exploited ones, at least in the case of browsers. > Heartbleed, Shellshock, Dirty COW etc. would all happen exactly the same way in different programming languages. Heartbleed is impossible in a memory safe language, at the least. Same with cloudbleed for that matter. DirtyCow and shellshock, sure. It's a bit of a moot point though - human energy is finite, consider if we could spend energy on problems like DirtyCow and shellshock instead of memory safety issues that simply don't exist in many languages.

staticassertion 7y ago

> Security engineers in general, very much including Chrome Security Team, would like to advance the state of engineering to where memory safety issues are much more rare. Then, we could focus more attention on the application-semantic vulnerabilities. That would be a big improvement.