4 ms·
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 expl
by 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 agoYet we keep having those yearly 70%, go figure.
- missblit 7y agoDidn't Heartbleed rely on reading uninitialized data? I'd assume memory safety includes preventing code from reading uninitialized data.
- staticassertion 7y agoYes, and correct.
- staticassertion 7y agoMost 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.