5 ms·

An allocator like that would require unsafe code to write and could not expose a safe interface unless it couldn't be used to read uninitialized memory. `Vec:

• lmm 12y ago
  You could write a custom "allocator" that created a pool of zeroed buffers initially, gave out buffers from that pool and accepted buffers back into that pool, and just didn't zero them in between. That would be perfectly "safe" as far as the language was concerned, and would allow you to reproduce the problem.
  • Jweb_Guru 12y ago
    I'd be interested to see an actual implementation of such an allocator in Rust that exposed a safe interface. You could do it in the specific case of chunks of predefined sizes, and maybe even for all byte arrays, but to allow arbitrary types in the allocator I do not think you could expose a safe interface without requiring initialization. Again: I'm quite confident you could reproduce this specific vulnerability. You would just have to go out of your way to do it and the benefits of managing a free list yourself aren't really there (jemalloc is quite good at large allocations).
  • eddyb 12y ago
    You would have to go out of your way to do so and handing out buffers that allow reading them without initialization would be a huge warning sign IMO. If you want performance, you don't have to worry about zeroing anything, just call `.clear()` on a `Vec`. Nobody is saying you can't reproduce Heartbleed's effect in Rust, you just have to actually design for it, be it maliciously or out of misunderstanding of the language or a library construct. The real question is how much harder Rust makes that which is often frustratingly trivial to sneak into C code.
    • mikeash 12y ago
      You would have to go out of your way to write your own custom allocator instead of just calling malloc and free, but that's what the OpenSSL folks did.
    • grey-area 12y ago
      You would have to go out of your way to do so and handing out buffers that allow reading them without initialization would be a huge warning sign IMO. So was doing that in the original C code, but no-one noticed.
      • eridius 12y ago
        In C, it's impossible to hand out buffers that have to be initialized before they're read. You have to go out of your way to initialize them first. In Rust, it's the other way around. You cannot hand out arbitrarily-sized buffers that allow for reading uninitialized memory without going out of your way to do so. Both languages can allow for writing bad code, but in C it's trivially easy to get the bad code by accident, and in Rust, you pretty much have to do it by design.
        • Sanddancer 12y ago
          There are mallocs that indeed do initialize memory before they're read. jemalloc, used in FreeBSD doesn't do it by default, but it's easy to set an option in /etc/malloc.conf so it does so, and ottomalloc in OpenBSD zeroes malloced memory because it uses mmap much more heavily. So yes, it is more than possible to have pre-initialized buffers in C, it's just that certain OSes use terrible memory allocation algorithms, with no way of even tuning them to be safe by default.
  • Dylan16807 12y ago
    You could reproduce this, but it wouldn't be heartbleed if it wasn't pouring out key info.