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

71–80 of 140 posts

Re: Heartbleed in Rust

#71

Post by masklinn »

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…

> 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 primitives/building blocks aren't doing so in Python in the first place, and doing so in Python would mean it's not easily accessible for {anyone not using Python}.

Re: Heartbleed in Rust

#72

Post by kibwen »

pacala wrote: post #58

If I'm reading the blog code correctly, the error is trusting user input: // Rust let len = buffer[0] as usize; // C size_t len = buffer[0]; I'm no Rust hacker, but can I expect the Rust type system to be able to encode some form of tainting? Making the leaky sequence illegal: let len = buffer[0] as usize; // ERROR ERROR ERROR using unscrubbed user input ERROR ERROR ERROR buffer[0 .. len] How exactly to encode tainti…

You can absolutely express tainting via the type system. I have seen this done before in Rust code in order to express functions that can only accept strings that have been properly sanitized, along with a function that takes an unsanitized string and returns a sanitized one. This particular example was using phantom types, though you could obviously also define wholly separate types for this sort of thing.

Re: Heartbleed in Rust

#73

Post by tptacek »

masklinn wrote: post #71
tptacek wrote: post #70

Earlier quoted context omitted.

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…

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

Re: Heartbleed in Rust

#74

Post by masklinn »

IshKebab wrote: post #35
ksherlock wrote: post #15

Earlier quoted context omitted.

Openssl uses their own memory allocator (since malloc is slow on big-endian x86 xenix or something) so they _do_ reuse memory without clearing it in between. Had they used the system malloc, it wouldn't have been vulnerable (on OpenBSD and probably elsewhere). Can rust prevent you from implementing your own (buggy) memory allocator?

Standard `malloc` doesn't zero memory either. The problem was not caused by their custom allocator. It was exacerbated by it because it allocated everything really close together.

Well it's not really that it allocated everything really close together in memory-space, but since it would try to reuse existing memory from the freelist before asking the OS for more memory, you were more or less certain to get memory openssl had previously used as scratch space to, say, store a private key for temporary operations.

Re: Heartbleed in Rust

#75

Post by masklinn »

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.

Yeah Rust isn't safer than an already memory-safe language (though it might be faster, then again it's also quite a bit more work wrt e.g. Go). but

> Don't write C/C++ in 2015.

That probably isn't going to stop, even ignoring performance ricers the bottom of the stack does need control, does need good performances, and more importantly does need to be usable from just about everywhere.

You can't really/easily use a scala library from MRI, or a CPython one from Go (it's already hard enough to use a CPython library from Pypy). If there's a C interface and little to no runtime assumption however you're good to go. Currently that means C or C++ (with a nice extern C ABI/API). If it could be something safer in the future, that would probably be a good idea.

Re: Heartbleed in Rust

#76

Post by SeanDav »

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.

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?

Re: Heartbleed in Rust

#77

Post by pcwalton »

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…

I think Rust is a security advance because it makes memory-safe programming practical in more domains than it used to be. The fact that Python has memory safety doesn't help (for example) browser engines, because it's too slow and requires too many dependencies. Rust didn't invent memory safety, of course, but it's bringing the security benefits of other languages to places they couldn't reach before, and I would argue that that itself advances security. To make an analogy, Rust is like the effort to add stronger ciphers to TLS as opposed to the effort to invent new ciphers; both are important, the latter because it creates stronger systems and the former because it makes those stronger systems more widely deployed.

Re: Heartbleed in Rust

#78

Post by hawkice »

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?

Almost all applications are "security applications", in the sense they are security sensitive, these days. If I pull data over the internet, my first person shooter now can't allow buffer overruns. Bad Things may happen in almost any environment.

Re: Heartbleed in Rust

#79

Post by kibwen »

zanny wrote: post #48
simias wrote: post #14

I mostly agree with the premise: logic errors are always going to be there, at least until the compiler is an IA strong enough to catch them for us (and by then we probably won't need coders anyway...). There's no silver bullet, bad coders are always going to produce. And I also don't like it when people claim that bug X or vulnerability Y wouldn't have happened if they had been technology Z, they're just begging for…

Having not done much Rust due to the volatility, I still have to give it credit here for a few more reasons: * I assume old_io is going away. That is why it is old, after all. Is this still possible in the new_io? If they made this not doable anymore that means they fixed the bug. * The compiler spat out a warning. Maybe it should have been "you dumb fuck why are you doing raw buffer reads and writes" but at least it…

The fundamental underlying problem is that a buffer containing sensitive data is being reused for a separate purpose without being scrubbed of the sensitive data. In the particular instance of heartbleed, this faulty behavior was due to the underlying memory allocator rather than any property of the programming language.

It is true that idiomatic Rust tends to avoid working with raw buffers, but for low-level tasks this is sometimes unavoidable. Rust also especially doesn't encourage reusing buffers, but if you've already taken the step of specifying an unsafe memory allocator then Rust can't help you. So yes, Rust gives you a lot of tools to avoid this situation but it can't outright prevent it, as a few people on the internet appeared to be suggesting last year.

Re: Heartbleed in Rust

#80

Post by jerf »

eddyb wrote: post #36
alecco wrote: post #30

Earlier quoted context omitted.

Is this logic error or just misuse of memory? (The buffer array)

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.

That said, this is a fair point. I have shot myself in the foot in a fairly equivalent manner in another memory-safe language (doesn't really matter which) because I was trying to reuse buffers as an optimization. Oops. I did it to myself, and at least I understood enough about what was going on that I didn't spend days wondering at the heisenbugs, but still, oops. It can happen.

But at least you have to work at it a bit.

Post reply on HN