Type / memory safety != security. The Rust people also mistake "no segmentation faults" for "no crashes".
Heartbleed in Rust
91–100 of 140 posts
Re: Heartbleed in Rust
#92As the offending commentor, I apologize. Particularly to the Rust team for generating this negative publicity, and to the person I replied to, for asserting a lie. I misunderstood Heartbleed, exactly as Ted summarizes. I've no excuse other than commenting when I shouldn't. I am happy though to have my idiocy corrected as I'll comment better in the future. The rest of the original thread does point out that I did exam…
Edit: What I said earlier is actually wrong. The problem is that a too big uninitialized buffer could be allocated and thus memory from previous allocations could be read. This isn't possible in Rust because you can't read uninitialized data. Of course reusing buffers can be dangerous and lead to information leakage, but it's not what happened with heartbleed, and the possibilities to exploit are smaller. Old text: A…
Heartbleed occurred because the size of the buffer was based on the size provided by the malicious packet, the buffer was not zeroed, and then the user-provided data was written to the buffer. If user-provided-data size was less than what you said it was, the rest of the buffer contained whatever it had previously contained.
Re: Heartbleed in Rust
#93Here is what I noticed about this, sorry if it is considered too off-topic: There was an argument, about something specific and technical; It was refuted without singling out a specific person by name; without using humiliation or insults; using code to do so ("show me the code!"); and there was a polite acknowledgement and resolution. This is an example of an interaction in a community that I think anyone would want…
I'm glad you appreciate it. :) We're far from perfect, but we're trying to build a great community, not just great software.
Did Torgo mean the Rust community or the HN community?
Re: Heartbleed in Rust
#94As the offending commentor, I apologize. Particularly to the Rust team for generating this negative publicity, and to the person I replied to, for asserting a lie. I misunderstood Heartbleed, exactly as Ted summarizes. I've no excuse other than commenting when I shouldn't. I am happy though to have my idiocy corrected as I'll comment better in the future. The rest of the original thread does point out that I did exam…
> As the offending commentor, I apologize. Particularly to the Rust team for generating this negative publicity, and to the person I replied to, for asserting a lie.
Realistically you're on the right side here. I just like to argue because it makes people justify their positions, which helps me (and hopefully other people) understand them better.
Rust is one of the most promising languages I've seen in a long time. People have been trying to make a language better than C++ for the things that C++ is good at for decades and this is the first time anything has the potential to succeed.
That's why I argue for the other side. Because when something has obvious potential, people have the inclination to deify it. The statement "X will solve all security problems" is false for all X. You can write secure code in C (see also DJB). You can write insecure code in Rust. It's easier to write secure code in Rust, and that's very important, but it's just as important for everybody to realize that no compiler is made out of magic pixie dust that will make all my code perfect even if I'm an idiot.
Re: Heartbleed in Rust
#95As the offending commentor, I apologize. Particularly to the Rust team for generating this negative publicity, and to the person I replied to, for asserting a lie. I misunderstood Heartbleed, exactly as Ted summarizes. I've no excuse other than commenting when I shouldn't. I am happy though to have my idiocy corrected as I'll comment better in the future. The rest of the original thread does point out that I did exam…
Edit: What I said earlier is actually wrong. The problem is that a too big uninitialized buffer could be allocated and thus memory from previous allocations could be read. This isn't possible in Rust because you can't read uninitialized data. Of course reusing buffers can be dangerous and lead to information leakage, but it's not what happened with heartbleed, and the possibilities to exploit are smaller. Old text: A…
The article claims this is not true and the author has a good reputation. I've not looked at the OpenSSL code, but if the author has written an isomorphic example, then there no over read. Is the article incorrect?
Re: Heartbleed in Rust
#96Earlier quoted context omitted.
Edit: What I said earlier is actually wrong. The problem is that a too big uninitialized buffer could be allocated and thus memory from previous allocations could be read. This isn't possible in Rust because you can't read uninitialized data. Of course reusing buffers can be dangerous and lead to information leakage, but it's not what happened with heartbleed, and the possibilities to exploit are smaller. Old text: A…
Heartbleed occurred because the size of the buffer was based on the size provided by the malicious packet, the buffer was not zeroed, and then the user-provided data was written to the buffer. If user-provided-data size was less than what you said it was, the rest of the buffer contained whatever it had previously contained.
And since people were able to recover SSL keys, does this not mean that this buffer was used for... everything? Having a non zeroing allocator for an entire library seems rather ambitious. It's significantly worse then just having a buffer pool for, say, incoming packets or something.
Re: Heartbleed in Rust
#97Earlier quoted context omitted.
I'm glad you appreciate it. :) We're far from perfect, but we're trying to build a great community, not just great software.
Did Torgo mean the Rust community or the HN community?
Seems like he was replying to the post by Ted, which was in response to a comment on HN. So I don't think this is about the Rust community.
Re: Heartbleed in Rust
#98Earlier quoted context omitted.
"Don't write C/C++ in 2015" That's quite bold.
Some people have to write C/C++. Kernel developers, for instance. But most people who write C/C++ in 2015 don't really have to. For every low-level game programmer or RTOS embedded systems use case you'll cite, I'll cite an unforced error that occurs 5x as often, such as "we wrote our custom database engine that only ever runs serverside in C".
On the other hand, Rust is not ready -- either from a stability or library perspective -- in 2015, most likely. What are you recommending the C/C++ programmers go to?
Re: Heartbleed in Rust
#99Type / memory safety != security. The Rust people also mistake "no segmentation faults" for "no crashes".
> The Rust people also mistake "no segmentation faults"
> for "no crashes".
Re: Heartbleed in Rust
#100Earlier quoted context omitted.
Some people have to write C/C++. Kernel developers, for instance. But most people who write C/C++ in 2015 don't really have to. For every low-level game programmer or RTOS embedded systems use case you'll cite, I'll cite an unforced error that occurs 5x as often, such as "we wrote our custom database engine that only ever runs serverside in C".
On the other hand, Rust is not ready -- either from a stability or library perspective -- in 2015, most likely. What are you recommending the C/C++ programmers go to?
Java. Python. Golang. Lua.