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

131–140 of 140 posts

Re: Heartbleed in Rust

#131

Post by kzrdude »

pcwalton wrote: post #77
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…

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

I hope that Rust will be more memory safe than Python in practice. Python just doesn't have that "culture", and third party modules often have memory safety bugs.

Re: Heartbleed in Rust

#132

Post by Sanddancer »

eridius wrote: post #82
grey-area wrote: post #55

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

There are mallocs that indeed do initialize memory before they're read. jemalloc, used in FreeBSD doesn't do it by default, but it's easy to set an option in /etc/malloc.conf so it does so, and ottomalloc in OpenBSD zeroes malloced memory because it uses mmap much more heavily. So yes, it is more than possible to have pre-initialized buffers in C, it's just that certain OSes use terrible memory allocation algorithms, with no way of even tuning them to be safe by default.

Re: Heartbleed in Rust

#133

Post by SamReidHughes »

heinrich5991 wrote: post #119
baq wrote: post #110

Earlier quoted context omitted.

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.

The difference is that in Rust not the whole source code but rather only the `unsafe` blocks and what they touch need to be verified for memory-safety.

And often that involves verifying code outside of the blocks that are literally marked unsafe. It's all of the code sitting behind some safe abstraction boundary that needs to be verified.

Re: Heartbleed in Rust

#134

Post by ertdfgcb »

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…

> I've no excuse other than commenting when I shouldn't

You totally should've made that comment, look what came from it. You learned something new, and so did a bunch of other people.

Re: Heartbleed in Rust

#135

Post by TheDong »

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.

I strongly disagree.

I think that switching from Python or Ruby to Rust will generally give a drastic security improvement.

The difference between having a complete type system and not is night and day. If you look at bugs in Ruby, it's frequently because of dynamic typing.

Having strong and strict typing is a wonderful way to catch logic errors at compile-time, and every logic error is a potential security flaw.

Re: Heartbleed in Rust

#136

Post by [deleted] »

tptacek wrote: post #81
SeanDav wrote: post #76

Earlier quoted context omitted.

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.

[deleted]

Re: Heartbleed in Rust

#137

Post by leovonl »

I fail to see the point of this whole discussion.

The code reflects exactly what the program is doing, and there's no undefined behaviour anywhere. There's no way to access anything outside the very delimited scope of "buffer" memory area, like stack variables or any other part of the program.

What's the point of using a high-level language for re-defining basic low-level operations on buffers and recreating everything using those low-level constructs without the proper boundary checks?

Of course, you can simply define a huge "unsafe" block and program everything inside it, but what's the point? That you have a language powerful enough to shoot yourself?

Compare that to C or C++: the unsafe block is always on. Any code block can have unsafe properties anywhere. Not only that, but you have ZERO guarantees on memory safety and other general operations. Summarizing, high-level and low-level totally mixed and no way to isolate them.

Sorry, but if you can't see how Rust avoids a "Heartbleed" or any other kind of similar issue, you have no understanding of programming or no experience debugging anything.

And yes: security != safety, but please note you are the one mixing both concepts.

Re: Heartbleed in Rust

#138

Post by AnthonyMouse »

MichaelGG wrote: post #118
AnthonyMouse wrote: post #114

Earlier quoted context omitted.

Aren't we just talking about Heartbleed again? If you're forwarding packets the attacker could send you one with a forged length field. Even if all you're doing is receiving packets and writing them to a file, what happens when you use the attacker-controlled reverse DNS of the packet's IP address as the file name?

Heartbleed isn't a memory safety issue though, which is what kicked this off. You're right in your original reply to me that if you want to go reuse buffers with leftover data, you can do that in any language. If you want to create a byte array in Java, fill it with private key material, then reuse the same byte array for an output buffer... what can stop that? But more to my point: in C, I could end up executing arb…

> Heartbleed isn't a memory safety issue though, which is what kicked this off.

It kind of is. It's just not of the type that "memory safe" languages fix for you, which is basically the point. If you define the scope of the problem in terms of what the proposed solution fixes then it tautologically fixes the entire problem, but it's still very important for people to understand that that doesn't mean it fixes every problem in that class.

> in C, I could end up executing arbitrary code by misparsing a network packet. In Rust, the worst I'll do is parse it wrong send invalid data onwards.

This is essentially what I'm talking about. It's still possible to execute arbitrary code in Rust, it's just not as easy. An obvious example is if your parsing bug is in the code that validates attacker-provided input before doing something sensitive with it. Or allows the attacker to flip a bit which is equivalent to remote code execution, like giving the attacker's account admin rights.

And even if "the worst" you do is parse it wrong and send invalid data, that's Heartbleed. The "invalid" data could be secrets.

The question you have to ask is, for all those memory corruption bugs in C, what does "memory safe" turn them into? They're still bugs, they're just not the same bugs. For example, a common way you get RCE in C is an integer overflow that leads to a heap overflow when the overflowed integer is used to allocate a buffer. But take away the heap overflow and the integer overflow is still there. Exploiting an integer overflow is highly context-dependent, but it's commonly possible regardless of whether it leads to a heap overflow. Being able to truncate the amount of Bitcoin being debited from the attacker's account or convert "username=rootxxxx" into "username=root" is arguably better than straight RCE, but not by very much.

Re: Heartbleed in Rust

#139

Post by peri »

steveklabnik wrote: post #67
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.

I'm incredibly slow to check this thread, but I wanted to make sure I mentioned that this made me feel better about the rust community also. Keep doing great work :)

Re: Heartbleed in Rust

#140

Post by steveklabnik »

peri wrote: post #139
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.

I'm incredibly slow to check this thread, but I wanted to make sure I mentioned that this made me feel better about the rust community also. Keep doing great work :)

Awesome :)
Post reply on HN