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

101–110 of 140 posts

Re: Heartbleed in Rust

#101

Post by Torgo »

twic wrote: post #93
steveklabnik wrote: post #67

Earlier 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?

I was thinking HN-affiliated, but it applies to the Rust community as well I think. I have seen very positive things on their IRC. Also would like to say that I am loving everything Ted Unangst-related, the OpenBSD community has an (often undeserved imo) bad rap and he is a great ambassador for that community as well, in addition to his amazing technical prowess. With all the talk about toxic communities lately I just want people to recognize positive examples that exist that could be used as guides without being preachy about it. Again sorry for OT, disengaging.

Re: Heartbleed in Rust

#102

Post by akerl_ »

MichaelGG wrote: post #96
akerl_ wrote: post #92

Earlier quoted context omitted.

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.

Oh yes, using buffers without zeroing them is a terrible idea, and sharing those buffers among different types of things is a terrible idea.

I was specifically commenting on the fact that what the parent comment described as "terribly unlikely" is in fact what happened.

Re: Heartbleed in Rust

#103

Post by hackuser »

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…

OT: How many times have you read a responsible admission like the parent in an Internet forum (or anywhere)? I wish more people had the guts to respond this way to mistakes instead of resorting to humanity's natural self-preservation (i.e., defensiveness). We all screw up; very few have the courage to admit it.

It also is important because it eliminates FUD around the issue: Now it won't be one of those false rumors that follows something around forever, hopefully.

Thank you!

EDIT: Slight edit.

Re: Heartbleed in Rust

#104

Post by qguv »

Shouldn't that analogy read:

code no true C programmer would write : heartbleed :: code no true rust programmer would write : (exercise for the reader)

Re: Heartbleed in Rust

#105

Post by plinkplonk »

tptacek wrote: post #100
felixgallo wrote: post #98

Earlier quoted context omitted.

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.

(Just trying for clarity, not arguing against or opposing your point)

In an earlier comment you used as an example of an unforced error "we wrote our custom database engine that only ever runs serverside in C".

Are you saying (with this comment) that for such use cases, developers should use Java/Python/Go/Lua (vs C/C++)?

Re: Heartbleed in Rust

#106

Post by legulere »

akerl_ wrote: post #92
legulere wrote: post #83

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

There was no buffer reuse like in the linked rust demonstration, but it was data from previous allocations.

Re: Heartbleed in Rust

#107

Post by MichaelGG »

AnthonyMouse wrote: post #94
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…

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

But Rust does solve all memory safety issues, doesn't it? In the same way, say, F# does. Except I can use it without worrying about deployment or runtime costs.

One scenario I am using Rust for is a packet capture parsing and forwarding daemon. With C, my biggest failure mode is "people can run code on your server by sending a packet across your network". With Rust, my biggest failure is "my code might be buggy so results could be useless". In fact, even if I try, I'm having a hard time coming up with code I could write that'd expose a security issue.

That's pretty close to magic pixie dust. Yes, it's a restricted scenario, but I doubt it's an uncommon one. A bunch of vulnerable utilities are basically just reading and writing data from/to files. If they weren't using a memory-unsafe language, they simply wouldn't be in a position to open security holes.

Am I overlooking something here?

Re: Heartbleed in Rust

#108

Post by Dylan16807 »

lmm wrote: post #38
eddyb wrote: post #32

Earlier quoted context omitted.

An allocator like that would require unsafe code to write and could not expose a safe interface unless it couldn't be used to read uninitialized memory. `Vec::with_capacity` would still not let you read the data even if you had a custom allocator.

You could write a custom "allocator" that created a pool of zeroed buffers initially, gave out buffers from that pool and accepted buffers back into that pool, and just didn't zero them in between. That would be perfectly "safe" as far as the language was concerned, and would allow you to reproduce the problem.

You could reproduce this, but it wouldn't be heartbleed if it wasn't pouring out key info.

Re: Heartbleed in Rust

#109

Post by MichaelGG »

tptacek wrote: post #69
pcwalton wrote: post #66

Earlier quoted context omitted.

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.

What are the other, common, RCEs? Command and SQL injection, upload and execute, etc. -- all those would apply to any language, right?

Eval()/dynamic loading and little custom languages (like perhaps some "business rules" type systems) probably aren't as common in C/C++ eh?

Same for overzealous serialization systems (like Ruby's YAML issues, and I think .NET's binary serialization)?

What other kinds of things lead to RCE that don't or rarely occur in C/C++?

Re: Heartbleed in Rust

#110

Post by baq »

MichaelGG wrote: post #107
AnthonyMouse wrote: post #94

Earlier quoted context omitted.

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

But Rust does solve all memory safety issues, doesn't it? In the same way, say, F# does. Except I can use it without worrying about deployment or runtime costs. One scenario I am using Rust for is a packet capture parsing and forwarding daemon. With C, my biggest failure mode is "people can run code on your server by sending a packet across your network". With Rust, my biggest failure is "my code might be buggy so re…

Rust can't solve all memory safety issues. Rust tries very hard to guarantee that safe code (i.e. not unsafe{}) will be memory safe and free of some race conditions. The hard part is making this possible - turns out you need unsafe in the core to be able to write safe implementations of those features in the general case. Attack surface is greatly lessened, but it's still there.
Post reply on HN