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

81–90 of 140 posts

Re: Heartbleed in Rust

#81

Post by tptacek »

SeanDav wrote: post #76
tptacek wrote: post #73

Earlier quoted context omitted.

Yes! I'm struggling to articulate the sentiment that boils down to "if you're already deploying Python or Scala or Ruby, Rust is unlikely to drastically improve your security, and rewrites are sure to harm security at least somewhat". If you're currently shipping C/C++, Rust seems like a great bet. Don't write C/C++ in 2015.

Wow, strong statement! I am not going to weigh on this other to ask for clarification - do you mean not use C/C++ at all, or only in the context of security applications?

Don't use C/C++ at all.

Re: Heartbleed in Rust

#82

Post by eridius »

grey-area wrote: post #55
eddyb wrote: post #43

Earlier quoted context omitted.

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

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.

In C, it's impossible to hand out buffers that have to be initialized before they're read. You have to go out of your way to initialize them first.

In Rust, it's the other way around. You cannot hand out arbitrarily-sized buffers that allow for reading uninitialized memory without going out of your way to do so.

Both languages can allow for writing bad code, but in C it's trivially easy to get the bad code by accident, and in Rust, you pretty much have to do it by design.

Re: Heartbleed in Rust

#83

Post by legulere »

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…

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: Actually heartbleed is a buffer over-read vulnerability that would have been prevented by rust's out of bounds checking. Of course you could allocate one huge buffer that contains sensitive data and is also used as an output buffer but this seems terribly unlikely to me.

Re: Heartbleed in Rust

#84

Post by fsloth »

tptacek wrote: post #73
masklinn wrote: post #71

Earlier quoted context omitted.

> But that's perhaps a performance and logistical advance, not a security advance. Isn't it both, depending where you come from? And isn't decreasing the performance/security tradeoff a security advance when developers in the domain do not want to compromise on performance? > But developers shouldn't be swapping their Python code for Rust if security is their primary objective. OTOH developers building up security pr…

Yes! I'm struggling to articulate the sentiment that boils down to "if you're already deploying Python or Scala or Ruby, Rust is unlikely to drastically improve your security, and rewrites are sure to harm security at least somewhat". If you're currently shipping C/C++, Rust seems like a great bet. Don't write C/C++ in 2015.

"Don't write C/C++ in 2015"

That's quite bold.

Re: Heartbleed in Rust

#85

Post by mcguire »

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.

Right. There's an infinite number of vulnerabilities; fixing any finite number of them still leaves you with almost all vulnerabilities outstanding. But still, fixing them is good.

Re: Heartbleed in Rust

#86

Post by tptacek »

fsloth wrote: post #84
tptacek wrote: post #73

Earlier quoted context omitted.

Yes! I'm struggling to articulate the sentiment that boils down to "if you're already deploying Python or Scala or Ruby, Rust is unlikely to drastically improve your security, and rewrites are sure to harm security at least somewhat". If you're currently shipping C/C++, Rust seems like a great bet. Don't write C/C++ in 2015.

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

Re: Heartbleed in Rust

#87

Post by mcguire »

tptacek wrote: post #70
pcwalton wrote: post #65

Earlier quoted context omitted.

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

Security is never a primary objective. If it were, blah, blah, powered off, locked room, blah.

Security might be the most important objective secondary to getting things done, but because it can't be primary, there will always be security considerations for the engineer. Nothing is perfectly safe.

Re: Heartbleed in Rust

#88

Post by geofft »

I'm very confused at the argument here. The C code looks remarkably close to idiomatic. Not "good," mind you, but "idiomatic". The Rust code looks significantly more contrived to my eyes. I'm reading the blog post as arguing that they're equally contrived.

It's true that you can do terrible things in any language, but the test of a language is how easy it makes it to do the right thing in the common case (plus how possible it makes it to do the thing you want in the uncommon case, without these goals compromising the other).

Is there a reason that reusing the buffer makes sense in Rust? (Zero allocation?)

Also, is it not true that Rust lends itself well, probably better than C, to abstractions like bounds-checked substrings within a single buffer? BoringSSL has been doing this in C, and this definitely would have stopped Heartbleed:

https://boringssl.googlesource.com/boringssl/+/master/includ...

Re: Heartbleed in Rust

#89

Post by camgunz »

pcwalton wrote: post #63
mikeash wrote: post #49

Earlier quoted context omitted.

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…

I mostly agree, but "use somebody else's" doesn't really help if you're writing a crypto library in the first place.

Re: Heartbleed in Rust

#90

Post by camgunz »

IshKebab wrote: post #33
masklinn wrote: post #17

Earlier quoted context omitted.

> No true blogger would wilfully misunderstand a buffer overrun vulnerability in order to score some cheap pageviews. You may want to read up on Ted, and realise that when he writes > if we don’t actually understand what vulnerabilities like Heartbleed are he's probably talking about you. > Basically, he's explicitly re-using a buffer, no buffer was overrun. Which is essentially what happened in heartbleed. Heartblee…

What he's done is actually very different to heartbleed. The heartbleed flaw was made much worse by the custom allocator used, but that wasn't the source of the flaw. The source was the fact that dynamically allocated memory in C is not bounds checked. That isn't true in Rust, and he had to basically implement a deliberately unsafe memory allocator to show this flaw. His argument that you can't say "no rust programme…

He addresses this though, with the "no true C programmer would have written this code" argument. Was it a bad idea for OpenSSL to use a custom allocator. Yeah. Did they do it anyway? Yeah. Would it be a bad idea to write a custom allocator in Rust? Yeah. Could you do it anyway? Yup.
Post reply on HN