alt Hacker NewsIt's a digression, but FTA:
> When I think about "we're very fucked" CVE10s on the Internet, I think of the following vulnerabilities:
Which is IMHO a really good list. It's also, I think, important to note that every single one of the four items is not at all a memory safety bug. They're all logic, at various levels of an interpretation stack.
I think a lot of folks with their heads down in the security world might have expected the opposite. As is often the case in engineering, the smartest people end up obsessing over solving the less important parts of the problem.
Replies
Heartbleed was a buffer overread. Sounds like a memory safety bug... is it not?
The vast majority of web services are not written in memory unsafe languages so this is not surprising.
One of the exceptions (with regards to web facing attack surface in a memory unsafe language) is that people still use OpenSSL, which has a terrible history of memory unsafety, including the cited heartbleed.
Serverside memory corruption is annoying to get working. As a dominant metagame strategy for attackers, it's much more impactful on the clientside.
(I'm not cosigning the analysis in this blog post. I think "I haven't seen a PoC I could get working" is not the evidence this author seems to think it is.)
Huh? Heartbleed is literaly memory safety (buffer over read)
I think Heartbleed is close enough to memory safety to count. It was caused by memory allocator returning uninitialized memory and every memory safe language I know about does not allow this in best-practice code.
(And sure, there are escape hatches - like Python has "recv_into" that could be used to implement heartbleed if you are really inclined to - but this would not be a realistic python program. In python, even with buffer reuse, you'd be using memoryview or similar that can't have a heartbleed problem)