Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Heartbleed in Rust

tedunangst.com

Post reply on HN
Print view View original

61–70 of 140 posts

Re: Heartbleed in Rust

#61

Post by MichaelGG »

mikeash wrote: post #49
eddyb wrote: post #36

Earlier quoted context omitted.

The latter. It's trivial to reuse buffers in Rust while avoiding this issue, for example `Vec` has a `clear` method that sets the length to 0 while keeping the allocation. But AFAICT, in C it didn't even have the same buffer by design , it was reading uninitialized memory from whatever `malloc` gave it back - which is equivalent to allocating a new buffer in Rust.

It was actually using a custom allocator, not the system malloc, which exacerbated the problem. System malloc could still have this problem, but for example OpenBSD has mitigations for this sort of data leakage in their malloc implementation, which OpenSSL then bypassed by using their own allocator. This is a problem for any "this would never happen in Better Language X" claim regarding Heartbleed. If you decide you…

And in fact, I've written that exact thing in a C# network stack, about 7 years ago. No bug, as I did properly check the size of the data, but totally possible to have messed up. It's not even hard code to write, just a simple object pool to return byte arrays. Which is natural, as in .NET, high performance often ends up as an exercise in removing every heap allocation possible.

Re: Heartbleed in Rust

#62

Post by Torgo »

Here 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 to be a part of. Thank you.

Re: Heartbleed in Rust

#63

Post by pcwalton »

mikeash wrote: post #49
eddyb wrote: post #36

Earlier quoted context omitted.

The latter. It's trivial to reuse buffers in Rust while avoiding this issue, for example `Vec` has a `clear` method that sets the length to 0 while keeping the allocation. But AFAICT, in C it didn't even have the same buffer by design , it was reading uninitialized memory from whatever `malloc` gave it back - which is equivalent to allocating a new buffer in Rust.

It was actually using a custom allocator, not the system malloc, which exacerbated the problem. System malloc could still have this problem, but for example OpenBSD has mitigations for this sort of data leakage in their malloc implementation, which OpenSSL then bypassed by using their own allocator. This is a problem for any "this would never happen in Better Language X" claim regarding Heartbleed. If you decide you…

I would argue that the whole Rust ecosystem pretty strongly discourages you from writing broken low-level infrastructure code. The idea behind unsafe code blocks, the generics system, and Cargo is to encourage you to use off-the-shelf tools instead of rolling your own, often broken, solutions. The C ecosystem, by contrast, tends to encourage rolling your own solutions because managing dependencies in a cross-platform manner is such a pain (and the language doesn't help due to the lack of generics and so forth). I suspect that any free-list library in Cargo that didn't zero out buffers would be fixed pretty quickly (and, as eddyb rightly points out downthread, it would be pretty hard to write a free list system that works with multiple types that doesn't require initialization before use--Rust in general abhors uninitialized memory).

There are parallels between the philosophy of crypto libraries like NaCl and Keyczar and the Rust philosophy. Don't write your own low-level infrastructure code. Use somebody else's.

Re: Heartbleed in Rust

#64

Post by steveklabnik »

MichaelGG wrote: post #60
steveklabnik wrote: post #21

Earlier quoted context omitted.

I value it very highly, otherwise, I wouldn't work on Rust. :) I'm just very careful to not suggest that memory safety is the end-all, be-all of errors. The Rust compiler will help you out, but it's certainly not perfect.

Even if it was perfect, nothing can help you if you choose to specifically choose to share data. It was my fault for having only skimmed the original Heartbleed explanation and just made the assumption it was a memory safety issue. Sorry for making Rust look bad, especially right when y'all are working so hard on 1.0.

It's all good. :) We all make mistakes.

Further, I would frankly people understand that you _can_ have security bugs in Rust code, rather than think that if it compiles, there's no need to do security auditing. This post is almost a PSA of sorts. :)

Re: Heartbleed in Rust

#65

Post by pcwalton »

MichaelGG wrote: post #47

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. 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…

Others at Mozilla and I have done similar studies with our Gecko critical security bugs. The number of them that Rust would have prevented are staggering.

I've always been careful not to claim that Servo will have no security flaws. It will, and some of them will be critical. But nobody denies that sandboxing is a powerful defense because Pinkie Pie found some sandbox escapes in the Pwnium contest. Likewise, let's not understate the benefits of memory safety: our studies have shown that the vast majority of critical security bugs in Gecko layout and graphics code are simple memory safety vulnerabilities like buffer overruns or use-after-free.

Re: Heartbleed in Rust

#66

Post by pcwalton »

tptacek wrote: post #51
jp_rider wrote: post #16

Earlier quoted context omitted.

I feel like you're undervaluing memory safety. Memory safety prevents most (all?) exploits that lead to remote code execution. There can still be high level vulnerabilities, but guaranteed memory safety is a huge improvement. Rust's type system can be used to prevent high level attacks too. For instance, if an sql library is set up properly, it can prevent sql injection by requiring inputs be properly sanitized.

Memory safety prevents 3 vulnerabilities that lead to remote code executions, not "most" or "all" of them. They're 3 very common and important vulnerabilities, though.

Based on incidence in Gecko, it is indeed most of them. It depends on your project, of course.

Re: Heartbleed in Rust

#67

Post by steveklabnik »

Torgo wrote: post #62

Here 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.

Re: Heartbleed in Rust

#68

Post by nickik »

MichaelGG wrote: post #57
nickik wrote: post #28

Some people wrote a completly new TLS Stack in Ocaml to combat this problem: http://openmirage.org/blog/introducing-ocaml-tls Here a Video about Mirage OS and this TLS Stack from the 31C3. Trustworthy secure modular operating system engineering - http://media.ccc.de/browse/congress/2014/31c3_-_6443_-_en_-_... There goal is to reduce the trusted computing base to a minimal. Rust could deliver some of the same benefits…

That page makes the same mistake I did, which caused Ted to write the article in the first place. There's no memory safety issue at play, at least not in the way memory safety is usually referred to. As the TFA shows, the problem is explicitly reusing the same buffer. I don't think there's a general way to prevent this kind of code. I guess more than just me assumed Heartbleed was a typical blindly allocate and read,…

True, I still wanted to get the information outthere.

Also I think, if you watch the Q&A at the end of the talk, they clame that the way you write and abstract code is diffrent and leads to saver code as well.

I dont want to clame that it is true, just pointing it out.

Re: Heartbleed in Rust

#69

Post by tptacek »

pcwalton wrote: post #66
tptacek wrote: post #51

Earlier quoted context omitted.

Memory safety prevents 3 vulnerabilities that lead to remote code executions, not "most" or "all" of them. They're 3 very common and important vulnerabilities, though.

Based on incidence in Gecko, it is indeed most of them. It depends on your project, of course.

It's a bit tautological to suggest that fixing the most common RCE flaws in C/C++ programs by replacing the language is the same as fixing all of the most common RCE flaws. The clear point here is that memory corruption is an affliction of C/C++ programs, but that other languages have other RCE-breeding flaws.

Re: Heartbleed in Rust

#70

Post by tptacek »

pcwalton wrote: post #65
MichaelGG wrote: post #47

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. 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…

Others at Mozilla and I have done similar studies with our Gecko critical security bugs. The number of them that Rust would have prevented are staggering. I've always been careful not to claim that Servo will have no security flaws. It will, and some of them will be critical. But nobody denies that sandboxing is a powerful defense because Pinkie Pie found some sandbox escapes in the Pwnium contest. Likewise, let's no…

Of course. But subtextually: had you replaced C++ with Python, you'd have had the same outcome. Obviously, a significant advancement in Rust is that it's feasible to replace performant C++ programs with Rust, and not feasible to do that with Python. But that's perhaps a performance and logistical advance, not a security advance.

I get that the combination of [memory-safe, non-garbage-collected, performant, natively-compiled] has security implications for systems programming. But developers shouldn't be swapping their Python code for Rust if security is their primary objective.

Post reply on HN