Hacker News new | past | comments | ask | show | jobs | submit login

No matter how horribly you miscalculate the length of a buffer in rust, you will not access arbitrary process memory (without unsafe). Yes, you can overflow a bound in rust. No, you can't overflow a bound into arbitrary program memory.

Heartbleed was not just re-using a buffer, it was also blindly copying program memory into that buffer because C allows such memory access.

You're simplifying the problem and wording it in a way where the difference is masked, but as I already explained clearly, it's different. Feel free to tell me how the rust code could access the linking program's process memory without using unsafe and without explicitly taking ownership of data from it, and I'll eat my words.




Does rust zero the allocated memory? If IIRC, that was the crux of heartbleed(I wrote my own exploit based of the description).. It created a too large not-zeroed buffer based on the size supplied and not the actual size sent. So you could send 16bytes and specify 16k(or whatever it was) and you'd get back a bunch of extra crap from the not-zeroed memory. Previously used and now freed memory, not just any old memory.

In ANY case, if you build it(unsafe) they will come. People WILL be writing code using unsafe.


  > People WILL be writing code using unsafe.
Yes, and that's not in any way controversial. If it wasn't useful to be able to drop down and do anything that C can do, it wouldn't be in the language. Our job as a community is to foster a culture where `unsafe` blocks are viewed with scrutiny and distrust unless proven otherwise. Our job as library implementors is to determine which use cases cause people to reach for `unsafe` and encapsulate those patterns in well-vetted safe interfaces. Servo already has a bot that inspects each PR in the queue and raises an alarm if any code within an `unsafe` block has been modified, flagging it for very close review. This is not a feature that we take lightly, it is a necessary tool to be used with care.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: