4 ms·

The one part of the spec that gives me pause is the fact that dropped memory isn't cleared. That sort of behavior has been the cause of so many network exploits

The one part of the spec that gives me pause is the fact that dropped memory isn't cleared. That sort of behavior has been the cause of so many network exploits. Is it worth worrying about here?

JoshTriplett 9y ago
If you want memory cleared on drop, you could do that by setting the global allocator to one that clears memory on free, rather than changing individual data structures.
- mehrdadn 9y ago
  I suspect he doesn't want to pay the performance penalty on all containers, just for a particular container.
  - sitkack 9y ago
    As noted elsewhere in this thread, one can implement a Drop trait the clears memory on deallocation. https://github.com/cesarb/clear_on_drop https://github.com/cesarb/clear_on_drop
cwzwarich 9y ago
If your language (and program in Rust's case, since Rust has unsafe code) is memory safe, then the contents of deallocated memory shouldn't be internally observable. Technically speaking, you could add an API to Rust that returns an Option of a buffer by virtual address, and this would be completely safe. If you're truly concerned about the implications of preserving the contents of existing memory, you need to do it at a lower level in the allocator anyways. In the case that a pushing elements on a Vec causes the Vec's buffer to be reallocated, the allocator is free to either extent the existing allocation of the buffer or make a new allocation. If the allocator chooses the latter, then clearing the memory upon drop doesn't clear the old copy.
- mehrdadn 9y ago
  > then the contents of deallocated memory shouldn't be internally observable. Only as long as you can assume control flow integrity. As soon as the control-flow gets diverted then an attacker can read the memory. That's the root of the security concern to begin with.
  - koverstreet 9y ago
    Huh? If memory safety isn't broken, no matter what the attacker does the memory is only going to be accessible through the container that allocated it. Parent's point still stands.
    - mehrdadn 9y ago
      > If memory safety isn't broken You're missing the facts that (a) your unsafe code won't be safe, and (b) your program will generally invoke external code that can be also buggy and hence not memory-safe.
      - koverstreet 9y ago
        Half the point of Rust is to drive the amount of unsafe code as close to zero as possible so we don't have to worry about crap like that. Based on the code I've seen, I think you're simply protecting your experiences and fears from C++. You are of course free to use an allocator that zeroes on dealloc in your own code.
        Yoric 9y ago
        To be fair, Rust code can link to (entirely unsafe) C/C++ code or even JIT-compiled code, in which case you also want some runtime guarantees to mitigate exploits in case they happen. In such a case, I believe a clearing allocator (or a set of custom allocators) sounds like the way to go. There may be a performance penalty, but you will be certain that all instances are covered, not just Vec<_>. Alternatively, a typed allocator (I wanted to link to a paper on the topic, but I can't find it) can, for a very small price, perform reasonably good mitigation on such exploits.
TheDong 9y ago
> That sort of behavior has been the cause of so many network exploits No, the thing that caused those issues was not that memory wasn't zeroed, but that the language was memory unsafe and the dirty memory was accessible again later due to a buffer overrun or other pointer messup. Rust tackled the problem of memory unsafety thoroughly, so there's no reason to worry about it. You don't hear people complain about Java or python not zeroing out memory as much since those languages, like rust, are memory safe. There are places where you do need memory to be zeroed (cryptographic operations where secrets should not live in memory longer than needed for fear or local attackers), but network attackers / because there might be buffer-overruns is not one.
- viraptor 9y ago
  That's not exactly true. I've dealt multiple times with situations in python where I wanted a guarantee that the stored value is cleared. As in actually overwritten, because it was used for temporarily holding certificate keys. This is doable, but usually via a native extensions. The problem being avoided here is not that python will fail. It's that openssl will get heartbleed and start leaking "freed" python contents from the same process. This very much applies to network attackers as well.

The one part of the spec that gives me pause is the fact that dropped memory isn't cleared. That sort of behavior has been the cause of so many network exploits. Is it worth worrying about here?

JoshTriplett 9y ago

If you want memory cleared on drop, you could do that by setting the global allocator to one that clears memory on free, rather than changing individual data structures.

mehrdadn 9y ago
I suspect he doesn't want to pay the performance penalty on all containers, just for a particular container.
- sitkack 9y ago
  As noted elsewhere in this thread, one can implement a Drop trait the clears memory on deallocation. https://github.com/cesarb/clear_on_drop https://github.com/cesarb/clear_on_drop

cwzwarich 9y ago

If your language (and program in Rust's case, since Rust has unsafe code) is memory safe, then the contents of deallocated memory shouldn't be internally observable. Technically speaking, you could add an API to Rust that returns an Option of a buffer by virtual address, and this would be completely safe. If you're truly concerned about the implications of preserving the contents of existing memory, you need to do it at a lower level in the allocator anyways. In the case that a pushing elements on a Vec causes the Vec's buffer to be reallocated, the allocator is free to either extent the existing allocation of the buffer or make a new allocation. If the allocator chooses the latter, then clearing the memory upon drop doesn't clear the old copy.

mehrdadn 9y ago
> then the contents of deallocated memory shouldn't be internally observable. Only as long as you can assume control flow integrity. As soon as the control-flow gets diverted then an attacker can read the memory. That's the root of the security concern to begin with.
- koverstreet 9y ago
  Huh? If memory safety isn't broken, no matter what the attacker does the memory is only going to be accessible through the container that allocated it. Parent's point still stands.
  - mehrdadn 9y ago
    > If memory safety isn't broken You're missing the facts that (a) your unsafe code won't be safe, and (b) your program will generally invoke external code that can be also buggy and hence not memory-safe.
    - koverstreet 9y ago
      Half the point of Rust is to drive the amount of unsafe code as close to zero as possible so we don't have to worry about crap like that. Based on the code I've seen, I think you're simply protecting your experiences and fears from C++. You are of course free to use an allocator that zeroes on dealloc in your own code.
      - Yoric 9y ago
        To be fair, Rust code can link to (entirely unsafe) C/C++ code or even JIT-compiled code, in which case you also want some runtime guarantees to mitigate exploits in case they happen. In such a case, I believe a clearing allocator (or a set of custom allocators) sounds like the way to go. There may be a performance penalty, but you will be certain that all instances are covered, not just Vec<_>. Alternatively, a typed allocator (I wanted to link to a paper on the topic, but I can't find it) can, for a very small price, perform reasonably good mitigation on such exploits.

TheDong 9y ago

> That sort of behavior has been the cause of so many network exploits No, the thing that caused those issues was not that memory wasn't zeroed, but that the language was memory unsafe and the dirty memory was accessible again later due to a buffer overrun or other pointer messup. Rust tackled the problem of memory unsafety thoroughly, so there's no reason to worry about it. You don't hear people complain about Java or python not zeroing out memory as much since those languages, like rust, are memory safe. There are places where you do need memory to be zeroed (cryptographic operations where secrets should not live in memory longer than needed for fear or local attackers), but network attackers / because there might be buffer-overruns is not one.

viraptor 9y ago
That's not exactly true. I've dealt multiple times with situations in python where I wanted a guarantee that the stored value is cleared. As in actually overwritten, because it was used for temporarily holding certificate keys. This is doable, but usually via a native extensions. The problem being avoided here is not that python will fail. It's that openssl will get heartbleed and start leaking "freed" python contents from the same process. This very much applies to network attackers as well.