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

121–130 of 140 posts

Re: Heartbleed in Rust

#121

Post by bad_user »

masklinn wrote: post #75
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.

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

> You can't really/easily use a scala library from MRI

You can easily link Scala with Ruby by running both on the JVM. Assuming you really want MRI, on the client-side that implies running 2 processes with their own runtime at least, instead of just one process. There is a reason for why I've heard of Ruby developers choosing JRuby to deploy Ruby apps, because having only one GC for managing a long-running process is expensive enough, having more than one gets awful fast.

On the server-side on the other hand, you have the freedom of deploying your stuff on multiple servers, which is often the case so you can use a micro-services approach - in our current project the front-end is developed in Ruby / Javascript and the backend in Scala, linked through a web service API. The great thing about this, besides using the best tool for the job and so on, is that people can work on them in parallel.

IMHO, I think the reusability of C is overstated. I haven't used C libraries in any of the JVM apps I ever developed and this reduced the headaches I've had back in the days when I did stuff with CPython or Ruby MRI. And given a potent runtime, you can make both Python and Ruby run on top of it with reasonable performance (compared to their reference implementations).

Re: Heartbleed in Rust

#122

Post by [deleted] »

masklinn wrote: post #17
stevejones wrote: post #13

No true blogger would wilfully misunderstand a buffer overrun vulnerability in order to score some cheap pageviews. To put it simply, his examples are the equivalent of doing this: unsigned char data[4096]; #define X (*(int *)(&data[0])) #define Y (*(int *)(&data[4])) ... Basically, he's explicitly re-using a buffer, no buffer was overrun. In Rust you will not read something out of a buffer you didn't put there first…

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

[deleted]

Re: Heartbleed in Rust

#123

Post by tptacek »

MichaelGG wrote: post #109
tptacek wrote: post #69

Earlier quoted context omitted.

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…

You just hit a bunch of them.

The C/C++ RCE bugs are buffer overflow (heap, stack, heap/stack via integers, &c), UAF (and double free), and uninitialized variables. It looks like there's a whole menagerie of different C/C++ RCE flaws, but they really just boil down to bounds checking, memory lifecycle, and initialization.

Metacharacter bugs apply to all languages, but since Rust doesn't eliminate them --- virtually nothing does, with the possible exception of very rigorous type system programming in languages like Haskell --- the metacharacter bugs rebut the parent commenter's point.

Eval() is an RCE unique to high-level dynamic languages. Taxonomically, you'd put serialization bugs here too (even the trickiest, like the Ruby Yaml thing, boil down to exposing an eval-like feature), along with the class of bugs best illustrated by PHP's RFI ("inject a reference to and sometimes upload a malicious library, then have it evaluated").

Those are just two bug metaclasses, but they describe a zillion different RCE bugs, and most of them are bugs that are not routinely discovered in C/C++ code.

Re: Heartbleed in Rust

#124

Post by oscargrouch »

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.

If you are using C or C++, it probably means you cant use those you have pointed out.

People can port Python and Ruby stuff to Go for instance and have advantages doing it, because the logic was already suited for managed languages.

But for C and C++ stuff is unlikely.. and for Rust the other possible option.. its kind of a productivity killer compared to C (even with the headers nonsense).

Its always a matter of tradeoff, and its not a casuality that C are alive and kicking til this day.. the language really has its strenghts.. and while every new lang in town claim they are the next C killer, well, in real life is much harder to make such a claim, and its not just because of the "old code that has to be maintained".

I know you are a security focused person, but security and safety is not the only one reason we choose a language to start a new project.

So until a really strong contender shows up (i particularly dont think Rust is it, but im sure there is a golden niche for it), they will still be with us, til we brake the current computation paradigm and algol and lisp langs doesnt make sense

Re: Heartbleed in Rust

#125

Post by krick »

So, let's say I'm on drugs and I'm writing TLS implementation being not "real Rust programmer". What are "rules of the thumb" I should follow (let's assume I have that much self-control) to not end up with something like this?

Re: Heartbleed in Rust

#126

Post by RaleyField »

baq wrote: post #110
MichaelGG wrote: post #107

Earlier quoted context omitted.

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.

Other GC'd languages come with runtimes written in C/C++ and often these libraries are the source of vulnerabilities. Rust is no different, if you grep your source code and find no unsafe blocks then you are back to where you were in GC land.

Re: Heartbleed in Rust

#127

Post by MichaelGG »

tptacek wrote: post #123
MichaelGG wrote: post #109

Earlier quoted context omitted.

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…

You just hit a bunch of them. The C/C++ RCE bugs are buffer overflow (heap, stack, heap/stack via integers, &c), UAF (and double free), and uninitialized variables. It looks like there's a whole menagerie of different C/C++ RCE flaws, but they really just boil down to bounds checking, memory lifecycle, and initialization. Metacharacter bugs apply to all languages, but since Rust doesn't eliminate them --- virtually n…

If you remove custom software like Intranet apps and focus more on products that have near ubiquitous deployment (like common desktop programs, OSes, basic server-level code), how do you think the come out? What about by number of people impacted?

Re: Heartbleed in Rust

#128

Post by wtbob »

tptacek wrote: post #86
fsloth wrote: post #84

Earlier quoted context omitted.

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

You know, I don't know if even kernel developers need to write in C/C++. Sure, those are the languages in which most kernels seem to be written, but couldn't kernels be written in, say, Lisp or Forth and have almost as much performance and at least slightly more security?

Re: Heartbleed in Rust

#129

Post by Curmudgel »

wtbob wrote: post #128
tptacek wrote: post #86

Earlier quoted context omitted.

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

You know, I don't know if even kernel developers need to write in C/C++. Sure, those are the languages in which most kernels seem to be written, but couldn't kernels be written in, say, Lisp or Forth and have almost as much performance and at least slightly more security?

Sure, you could write a kernel in Lisp or Forth. But if you are a developer for a kernel that written in C/C++, you don't really have a choice.

Re: Heartbleed in Rust

#130

Post by Sanddancer »

krick wrote: post #125

So, let's say I'm on drugs and I'm writing TLS implementation being not "real Rust programmer". What are "rules of the thumb" I should follow (let's assume I have that much self-control) to not end up with something like this?

The biggest thing is to let the memory allocator do its job. Don't cache buffers, etc between uses to speed things up; once it's used, throw it in the dumpster and get a new chunk of memory. Your nifty performance hack will succeed in leaking vital information much faster than the stock memory allocator. Other things are if your allocator doesn't do it for you, zero out your memory before you use it, and if you really want to get fancy, zero it out when you're done using it. Also, test on more than one OS/Architecture. Your code may work beautifully on your Linux x86 box, but does it still work under OpenBSD? How about running on an ARM board? Good, portable code that doesn't rely on trickery is one of the best ways to ensure that your assumptions won't cause the next security disaster.
Post reply on HN