Hacker News Reader

Comment by ajross | Hacker News Reader

It'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.

View on HN

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)

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

TBH this would have happened if they used the same approach in any language, and wouldn't have happened if they used a different approach in C.

They wrote their own allocator. That's the problem. If they didn't use their own allocator valgrind or sanitisers would have caught this.

If they used this approach in any other language, like Java or C#, heartbleed would still have happened.

No, they used a language where the preferred way to share memory is raw pointers. That is the problem.

Every language has a preferred way to deal with things. In C, it's raw pointers, which are very error prone. Other languages have something better. For example, if you were to implement custom allocator in C#, would you return raw pointer? Or maybe base array + offset pair? Of course not, you'd choose a Span or Memory, and those are not prone to buffer overruns.

I love that in a subthread I started about the limits of memory safety in security analysis, everyone gets stuck on Yet Another Rust Proxy Fight over whether the custom allocator the library wrote represents a problem with the design or the implementation language.

I repeat the claim: This isn't where you should be spending your tokens and it's not the hole through which the apocalypse will arrive. People fighting over Rust will be the first to fall when the auth-exploiting robots arrive.

Edit to address the specific example: OpenSSL would never have been written in .NET in the first place, being very performance/hardware sensitive (there's a bunch of platform assembly in TLS implementations) and by its nature designed to be needed by all/almost-all software on a system. The argument everyone would reach for here would be Rust. But in Rust, the same logic that led to the custom allocator would probably produce an unsafe-based equivalent (which is true for almost all heavily optimized rust, sort of a dirty secret).

> No, they used a language where the preferred way to share memory is raw pointers. That is the problem.

That's irrelevant - had they used the same approach in C#, heartbleed would still have happened. The language here makes no difference because the error is in the approach they chose which bypassed any ability for tooling or language features (such as found in C# and similar) to prevent reuse of deallocated memory.

The language makes all the difference because defaults matter. As someone said once, you can write C in any language. You can even do a heartbleed in python - just create one big buffer, do your own allocator, and pass (buffer, index) everywhere instead of proper object.

But would anyone do this? No. If you are writing pool-based packet processor in Python, you'd deal in buffers (safe from overread), in C# you'd return Span/Memory (safe from overread) and only in C you'd return overread-prone raw pointer.

Not that you can blame programmers in this case - C simply lacks the facilities for safe memory access, such as bounded pointers or spans. And you can't really blame it on custom allocator - malloc() would have had the same problem.

> only in C you'd return overread-prone raw pointer.

If that was all they did, tooling like valgrind and sanitisers would have caught it.

Heartbleed was an issue because they used their own allocator. If they didn't use their own allocator, the error (over-running an array/reusing deallocated memory) would have been caught by the tooling.

Heartbleed was a buffer overread. Sounds like a memory safety bug... is it not?

It was.

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

Well, yeah. But client vulnerabilities are likewise annoying to get working, being vastly more amenable to defense in depth techniques like sandboxing and firewalls and permissions strategies, yada yada. Which is why there are no client holes in the author's list of "break the world" problems. The most impactful attacks against clients are targetted zero-days. Which are bad! But not as bad as e.g. Log4Shell[1].

[1] My favorite example in this kind of argument just because it's so obviously understood and non-technical. All the pedantry in the world wouldn't have fixed that, it was the combination of a bunch of correctly implemented and useful features.

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.

Huh? Heartbleed is literaly memory safety (buffer over read)

Reply on news.ycombinator.com