4 ms·
It's extremely important to remember this in context: Heartbleed occurred on OpenBSD because OpenSSL had its own wrapper over malloc(). Instead of actually free
by weland 12y ago
It's extremely important to remember this in context: Heartbleed occurred on OpenBSD because OpenSSL had its own wrapper over malloc(). Instead of actually free()-ing those areas when calling openssl_free(), OpenSSL would leave them untouched and reuse them. If that had not been the case, and free() had in fact been called, reading past the actual payload boundaries would have yielded no useful results, because the malloc() in OpenBSD's libc would have cleared it (as opposed to openssl_malloc(), which was reusing previously un-free()-d zones).
In other words: idiomatic C and a sane malloc() implementation could have actually prevented Hearbleed.
It makes sense to assume that un-idiomatic Rust and reusing memory without clearing it would trigger the same bug.
- _yosefk 12y agoBy "sane malloc" do you mean one that gives you "cleared"/zeroed memory? I think it's a rarity and I think programs kinda assume that malloc takes, I dunno, 300-1000 cycles at worst when allocating many megabytes - whereas zeroing such buffers takes much more. Or did I misunderstand your point about "malloc sanity"?
- Sanddancer 12y agoOpenBSD's malloc function is based on mmap, which will give you cleared pages.
- _yosefk 12y agoYou mean it always relinquishes pages to the OS upon free and never reuses a page? So every malloc is a memset(0) inside the kernel?
- weland 12y agoTechnically yes (although, by default, no), but it's more efficient than that would imply. By default, I think only small chunks are overwritten, so OpenSSL's meagre 64 KB of Heartbleed payload would have been filled with useless junk, whereas multi-megabyte mallocs() in e.g. a RDBMS would have been unaffected. There are some other protection mechanism included, too; there's a more in-depth presentation here: http://www.openbsd.org/papers/eurobsdcon2009/otto-malloc.pdf http://www.openbsd.org/papers/eurobsdcon2009/otto-malloc.pdf
- amelius 12y agoThese areas could be cleared in a separate thread, of course.
- weland 12y agoThe section responsible for Hearbleed was never allocating more than 64 kilobytes, which can probably be cleared in 1000 cycles on most modern architectures. As someone else pointed out, OpenBSD's malloc() implementation could have supplied a cleared memory area with no discernible performance impact (in fact, I think LibreSSL already does).
- danudey 12y agoMarking your code as unsafe lets you do a bunch of, well, unsafe things. So yeah, if you wanted to you could probably reproduce heartbleed in OpenSSL.
- weland 12y agoIf you follow the same faulty line of reasoning about performance and portability that led the OpenSSL team to introduce their incorrect wrapper over native malloc(), you will find that you'll reproduce Heartbleed using entirely safe code.