Hacker News Reader

Comment by lelanthran | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com