6 ms·

In Rust, you cannot ever read uninitialized memory (including allocated memory) without using unsafe code (as can be seen in the original code sample, the Rust

In Rust, you cannot ever read uninitialized memory (including allocated memory) without using unsafe code (as can be seen in the original code sample, the Rust buffer, unlike the C buffer, is initially zeroed out). So in safe Rust, what you are describing indeed could not happen. The unsafety would have to be explicit at the caller end: the unsafe within the allocator implementation isn't enough.

masklinn 12y ago
> So in safe Rust, what you are describing indeed could not happen. Read the last paragraph. OpenSSL has a buffer reuse system via a freelist (and the non-freelist code had bitrotted), it didn't release buffers to the system's allocator after use, buffers were initialised across calls. Otherwise while heartbleed would still have existed to a large extent, it would also have been mitigable by e.g. malloc.conf or shimming in a zeroing malloc.
- Jweb_Guru 12y ago
  I believe if it went through any of Rust's planned custom allocator system (i.e. worked through `box`) it would still not work, though. You could certainly rewrite exactly the same system from C, of course (though as I noted elsewhere, it seems less likely that OpenSSL would want to replace jemalloc than the often-slow system allocator), but I think it would be quite difficult to write a safe implementation that worked with Rust's borrow checker. The closest thing to a custom allocator that works in Rust right now is an arena with a free list, which requires you to explicitly initialize any newly allocated elements. As another commentor noted, you would really have to go quite far out of your way to reproduce the issue.
- eddyb 12y ago
  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::with_capacity` would still not let you read the data even if you had a custom allocator.
  - 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.

masklinn 12y ago

> So in safe Rust, what you are describing indeed could not happen. Read the last paragraph. OpenSSL has a buffer reuse system via a freelist (and the non-freelist code had bitrotted), it didn't release buffers to the system's allocator after use, buffers were initialised across calls. Otherwise while heartbleed would still have existed to a large extent, it would also have been mitigable by e.g. malloc.conf or shimming in a zeroing malloc.

Jweb_Guru 12y ago
I believe if it went through any of Rust's planned custom allocator system (i.e. worked through `box`) it would still not work, though. You could certainly rewrite exactly the same system from C, of course (though as I noted elsewhere, it seems less likely that OpenSSL would want to replace jemalloc than the often-slow system allocator), but I think it would be quite difficult to write a safe implementation that worked with Rust's borrow checker. The closest thing to a custom allocator that works in Rust right now is an arena with a free list, which requires you to explicitly initialize any newly allocated elements. As another commentor noted, you would really have to go quite far out of your way to reproduce the issue.
eddyb 12y ago
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::with_capacity` would still not let you read the data even if you had a custom allocator.
- 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.