17 ms·

Would Rust have prevented Heartbleed? Another look

257 points by wasd 12y ago

wglb 12y ago
I disagree about Ted being wrong. A key phrase in Ted's article is Hopefully the simulacrum retains the essence of the problem. What Tedbleed, as your article calls it, demonstrates is a bug similar to Heartbleed: reuse of a buffer in a memory-safe language is susceptible to leakage of secrets. While I might answer the question are Rust’s memory safety features being oversold by uninformed zealots?, no I don't think so, but I would suggest that thinking that memory safety ends all security issues is a not good plan. The key is Unless you venture into the (explicitly demarcated) unsafe portion of Rust, you will not see memory exposure vulnerabilities like Heartbleed: the language does not prevent this. Perhaps your post will stimulate Ted to go further with his example and write an erroneous complete TLS stack in Rust, showing how it too can do Heartbleed. Perhaps you agree that this can be done. Among the scariest mass vulnerabilities relating to total information disclosure, the Padding Oracle Attack, the BEAST attack, the compression flaw CRIME, none have to do with memory safety of languages. Rust there would not have helped one whit. Memory safety is just one issue in writing secure code. Edit: typo
- saidajigumi 12y ago
  To my knowledge, no one in the Rust or greater memory-safe programming language community would claim: Using <$LANG> prevents leakage of secrets! When put like that, it sounds like a straw-man argument. In my own words, the narrower and stronger claim being made is that the specific and important avenue by which Heartbleed leaked secrets is not possible without unsafe code in Rust. So if you're going to claim that Ted "isn't wrong", but on terms that no one was originally arguing... I don't even know what to say.
  - wglb 12y ago
    So if you're going to claim that Ted "isn't wrong", but on terms that no one was originally arguing... Perhaps I am taking a more general implication of this than "Rust would not have exactly reproduced the Heartbleed problem". I infer the overall meaning of Ted's argument, and the general discussion that "Memory safe languages do not prevent information leakage". To me that is what the argument is about.
    - danudey 12y ago
      Nothing 'prevents' information leakage other than writing perfect code 100% of the time. If the argument is that you can write a program in Rust that tells someone something they shouldn't know… is that… what's even the argument here? Is that even a question? But in that case, comparing against Heartbleed is pointless. Why not ask about SQL injection attacks? Or directory traversal attacks? Or OS privilege escalation attacks? Or listening on a port that isn't correctly firewalled? Rust won't prevent any of those either, because none of them have anything to do with the language being used. Arguing that it's possible to write code that does the wrong thing is so pointless that I can't understand why this article was written other than as some kind of half-assed hatchet job.
  - lmm 12y ago
    I would claim that using Scala (and presumably Haskell) gives you the tools to make it impossible to leak secrets, if you want to. You could use a path-dependent container type to ensure that content was associated with a particular connection and never passed off to a different connection; if you tried to do something like reusing a buffer, it would be a compile failure. There would be costs to this - both in runtime performance (presumably you wanted to reuse buffers for a reason) and in program complexity. And of course it's possible to make an error in your type definitions (though you have to make two errors to be exploitable - one in the types and one in the values - and the types are shorter and much easier to audit than the full program code). But it absolutely is possible, and I think that pretty soon we'll reach the point where it becomes worthwhile for security-critical code.
    - steveklabnik 12y ago
      Yeah but even Haskell (and I'm assuming Scala has something similar) has unsafePerformIO...
      - codygman 12y ago
        But there is a compiler flag -XSafe which could guarantee none of your code uses it, meaning GP's answer could be yes.
        steveklabnik 12y ago
        We have that switch in Rust as well.
      - olavk 12y ago
        As far as I understand, unsafePerformIO is not unsafe in relation to memory safety issues. It is just unsafe in that it circumvents the IO monad, which means order of execution is not guaranteed.
        steveklabnik 12y ago
        It's a different kind of unsafe, but my point is that it violates the normal guarantees of the language.
  - deleted 12y ago
    [deleted]
  - tedunangst 12y ago
    > specific and important avenue by which Heartbleed leaked secrets is not possible without unsafe code in Rust. Alright. Please clarify. What is the specific and important avenue by which Heartbleed leaked secrets?
    - TheDong 12y ago
      By allowing an attacker to read arbitrary memory of the process that linked against the library In rust, if I write code where I store my secrets in two variables which I pass into my ssl constructor, but retain single ownership of (such that the ssl library may not retain references to them after the constructor exits), there is no way for those exact memory addresses to be read and returned via that library, excepting unsafe. If you say "ah, but the constructor could take a copy and leak that", then that's a different class of vulnerability. It could, but then it would be leaking its memory, not mine.
      - tedunangst 12y ago
        Are we now redefining plaintext passwords and cookies as "not secret"? OpenSSL stored them in the same variable as heartbeat payloads.
        TheDong 12y ago
        less secret than tls keys, yes. However, that completely does not relate to your question. I'm not saying that they both aren't security vulns, they both are. You asked how heartbleed leaked secrets (implicitly how it was different from the rust code), and I told you how it differs. Where the secrets are stored is different. One is user-supplied secrets only, the other is arbitrary secrets within the process, user-supplied or otherwise. Yes this is different. Your response here is simply moving the goalposts.
        tedunangst 12y ago
        To move the goalposts back to position, I'll answer my own question. The specific and important avenue by which Heartbleed leaked secrets was reusing secret containing buffers and miscalculating the initialized length.
  - MichaelGG 12y ago
    My original comment said that even with a custom allocator, Rust would refuse to compile code that could lead to Heartbleed. This was technically not accurate. (I thought HB was just out of bounds+uninitialized behavior.) I think the real key is that in C, this leak can happen with just malloc+forgetting a memset, no explicit buffer reuse required. Whereas in Rust, you'd need to explicitly reuse the buffer.
    - tedunangst 12y ago
      The not compiling part was really what piqued my interest. :)
      - MichaelGG 12y ago
        To be fair, the equivalent of malloc(x) plus a read of x+n bytes wouldn't compile, even with a custom allocator.
        camgunz 12y ago
        I know next to nothing about rust, but can't you do pretty much whatever you want when you implement a custom allocator? Including allocate a giant buffer ahead of time and reuse stuff with no safety whatsoever?
        MichaelGG 12y ago
        I'm not sure custom allocators exist. But assuming they did, sure you can. But in that case you're explicitly opting into unsafe code to use uninitialized memory. And, even if you did have such an allocator, you still can't read past the end of the allocation. So if you ask for a 16 byte buffer and attempt to read 17, it'll fail.
- weland 12y ago
  It's extremely important to remember this in context: Heartbleed occurred on OpenBSD because OpenSSL had its own wrapper over malloc(). Instead of actually free()-ing those areas when calling openssl_free(), OpenSSL would leave them untouched and reuse them. If that had not been the case, and free() had in fact been called, reading past the actual payload boundaries would have yielded no useful results, because the malloc() in OpenBSD's libc would have cleared it (as opposed to openssl_malloc(), which was reusing previously un-free()-d zones). In other words: idiomatic C and a sane malloc() implementation could have actually prevented Hearbleed. It makes sense to assume that un-idiomatic Rust and reusing memory without clearing it would trigger the same bug.
  - _yosefk 12y ago
    By "sane malloc" do you mean one that gives you "cleared"/zeroed memory? I think it's a rarity and I think programs kinda assume that malloc takes, I dunno, 300-1000 cycles at worst when allocating many megabytes - whereas zeroing such buffers takes much more. Or did I misunderstand your point about "malloc sanity"?
    - Sanddancer 12y ago
      OpenBSD's malloc function is based on mmap, which will give you cleared pages.
      - _yosefk 12y ago
        You mean it always relinquishes pages to the OS upon free and never reuses a page? So every malloc is a memset(0) inside the kernel?
        weland 12y ago
        Technically yes (although, by default, no), but it's more efficient than that would imply. By default, I think only small chunks are overwritten, so OpenSSL's meagre 64 KB of Heartbleed payload would have been filled with useless junk, whereas multi-megabyte mallocs() in e.g. a RDBMS would have been unaffected. There are some other protection mechanism included, too; there's a more in-depth presentation here: http://www.openbsd.org/papers/eurobsdcon2009/otto-malloc.pdf http://www.openbsd.org/papers/eurobsdcon2009/otto-malloc.pdf
- Trufa 12y ago
  I don't get your point, what are you trying to say? > What Tedbleed, as your article calls it, demonstrates is a bug similar to Heartbleed Similar but very different in the severity. > but I would suggest that thinking that memory safety ends all security issues is a not good plan. Nobody said that. > The key is Unless you venture into the (explicitly demarcated) unsafe portion of Rust, you will not see memory exposure vulnerabilities like Heartbleed: the language does not prevent this. Sure, if you want to break it, you'll probably can, but you'll have all kinds of warnings before and the few lines where you actually do that, can be proofread the most times. There's nothing preventing you from writing common bugs the generate vulnerability either, but that's simply not possible. > Perhaps your post will stimulate Ted to go further with his example and write an erroneous complete TLS stack in Rust, showing how it too can do Heartbleed. Perhaps you agree that this can be done. Well, Rust may have a memory leak at some point in the future, no software is perfect, but that is one language, that will be review constantly, that is mainly memory safe, the other is one language that is not memory safe where thousands of developers are constantly writing code, inserting lots of heartbleed/memory kind of bugs. > Among the scariest mass vulnerabilities relating to total information disclosure, the Padding Oracle Attack, the BEAST attack, the compression flaw CRIME, none have to do with memory safety of languages. Rust there would not have helped one whit. That's not the point of the article, ted tries to say that hearbleed would be possible, author contradicts this as it shows how the vulnerability would be of different severity.
  - tedunangst 12y ago
    The fixation on private keys puzzles me. While they were extractable in some cases, it was difficult. Stealing passwords and cookies was trivial however. And how does one use a stolen key? You have to intercept the traffic first. I can abuse a stolen password from anywhere in the world by using it to log in. Then I can read all your (email, etc.) and don't even need the private key. To differentiate these as "very different in severity" is I think quite misleading.
    - e12e 12y ago
      > The fixation on private keys puzzles me. Really? The private key in asymmetric cryptography should never/is assumed to never be known to anyone other than the key-holder. Session keys are understood to be shared, and so are by definition not secure (equivalently, I can log my part of the "conversation" with a server, even if over TLS with PFS). So session keys, session cookies, transmitted data -- is always known by more than one party, a secret key should never be known by more than one party. It is true that most TLS server deployments don't enforce this -- they don't do the asymmetric operations in a trusted computing module, smart card etc -- but they should. They shouldn't store the key in ram, but they currently do. If you get the secret key, you can do many more things than merely intercept traffic. You can impersonate and fake traffic (fake evidence). In addition to all this, being able to read arbitrary memory controlled by the same process is also worse than being able to read stuff that is already being transmitted. This isn't strictly a Rust/other language issue (I imagine, but do not know, that one eg could sanely (if foolishly) share buffers across thread pools, and so potentially leak information across clients -- this would probably be a design error wrt. trust boundaries etc ... but no-one is arguing that any language can prevent design errors). As mentioned in other comments, privilege separation (a la openssh etc) is a great way to help leverage the os/kernel in order to enforce assumptions about the security primitives used. But that's a little beside the point.
gaius 12y ago
The code that led to the Heartbleed vulnerability was checked in in December 2011. The first pre-Alpha release of Rust was in January 2012 (source: Wikipaedia for both). Would technology from the future have prevented it, is the actual question, and the answer should be obvious...
- saidajigumi 12y ago
  This rant is disingenuous both to the author's post and the ongoing conversation about the benefits and limitations of memory safe languages. To put it more generously, one might write: Could this specific technology from the future have prevented Heartbleed?
  - zzzcpan 12y ago
    I think he has a point. Do we really need this specific technology from the future to prevent Heartbleed? No, because we have ASan and other things like that.
    - wyldfire 12y ago
      ASan is wicked awesome, to be sure. But despite its existence, it's not IMO widely-used, or at least as-widely-used-as-I'd-like.
    - danudey 12y ago
      We also have 'not using a custom malloc() wrapper that doesn't actually free memory as a wrapper around free()' to prevent Heartbleed, but instead of this technology being from the future, it's actually from decades ago.
    - lmm 12y ago
      ASan is a runtime detector; it only works if you have a test case that covers the buggy thing, like in this case sending a malformed heartbeat request. OpenSSL pretty clearly didn't have a test case for that - if they did, they'd've caught the problem, with or without ASan. It's like the difference between a type system and unit testing.
exabrial 12y ago
Ok, maybe, and definitely cool. But Java was supposed to prevent memory leaks but it's still possible :)
- vitno 12y ago
  I mean, memory leaks are possible in Rust assuming the person explicitly uses unsafe code. However, most code does not use these unsafe blocks... and it should not be possible. Rust has a sound type system that uses linear affine typing. While their implementation is not "proven correct", in practice if the Rust compiler is working properly, leaks will not happen.
  - Ygg2 12y ago
    I think it's possible to leak even in safe code if you misuse RC/ARC and the family. EDIT: Box don't leak.
    - kibwen 12y ago
      `Box` won't leak, but `Rc` is just simple reference counting and can leak if you don't use weak pointers to break cycles.
  - mercurial 12y ago
    What's keeping you from having a cache and forgetting to expunge it? It's fair to say that you have to work a lot harder in Rust to get a memory leak, while it requires no effort in C/C++, though.
- jsight 12y ago
  Depending upon your definition of "memory leak" it may be impossible to prevent them at the language level. Java's claim was much narrower than that.
- alephnil 12y ago
  There is a whole class of memory leaks that is possible in C but not in Java. You can leak memory by forgetting to deallocate it. This class is not possible in typical Java code, because the garbage collector collects it. Then you have memory leaks that happens because the application has data structures that grow unbounded. The latter one is not really preventable by automatic means, because the memory is still referenced from elsewhere in the application, and a garbage collector can't know that this memory won't be accessed again. It does help that the most common source of memory leaks is eliminated however. That many Java applications are memory hogs is more a result of typical Java programming style than anything else.
Someone1234 12y ago
I have a question: How do Rust and Go compare in terms of security? Or are they both very similar in terms of mitigating certain classic C vulnerability classes.
- nothrabannosir 12y ago
  Zero experience with Rust beyond watching tutorials and talks, please please correct me if Im wrong. Rust has one killer feature that Go does not have: the typesystem has semantics for memory sharing. You can declare how a pointer can be used: is it accessed concurrently, is it local to me, &c. This helps the typesystem detect race conditions where two threads access a block of memory in an unsafe way. Go does not have this. In Go, you "share memory by communicating", instead of "communicating by sharing memory." But if you do want to share memory, you are back to using locks and your own conventions and mechanics to prevent concurrent access. The language doesn't help you. So it's a different programming paradigm. And if you use Go like you would use Rust (memory sharing), then Go is less safe. (...right?) EDIT: This sounds one-sided, but I'm only talking about sharing memory, here. If you don't do that, and stick to communicating, then Go can blow you away. I don't know how Rust deals with coroutines, but Go has super light threads (goroutines) that make concurrent behavior pure joy. All your threads can so easily talk to eachother, and wait for eachother, and it's all so light and native and good! E.g. you have a handler for a POST, but you only want to close the connection when another thread has finished doing something. And you don't want to tie up an entire OS thread, because it could take a while and that's just too expensive. In go: super easy, just do a blocking channel read. In another language? Wow, where would I start... (How does rust do that?)
  - slimsag 12y ago
    Using a plain-old mutex in Go isn't encouraged. As you said, the memory model is _share by communicating_. Sometimes, yes, using a mutex makes more sense -- and that does introduce the possibility of a data race. If you follow effective Go code -- I imagine the code is on average about just as safe as Rust code is. It is partially comparable to using `unsafe` blocks in Rust -- don't do it, unless you know what you're doing. Stick with channels.
munin 12y ago
Ted's original point about Heartbleed not being a violation of memory safety is bogus, because there is a configuration of OpenSSL (achievable with flags passed to ./config) where extended-sized Payload values cause the OpenSSL server to segfault with an out of bounds read. It takes a special kind of bravery to look at that kind of crash and say that it is not the result of a violation of memory safety.
- tedunangst 12y ago
  I'll be the last person to claim there aren't memory safety violations in OpenSSL.
  - munin 12y ago
    Yes, but you specifically said that Heartbleed wasn't a memory safety violation, when in fact OpenSSL-vulnerable-to-Heartbleed can segfault on over-read. So what is it?
    - MichaelGG 12y ago
      But Heartbleed still existed even without out-of-bound reads, right? That's the critical distinction I got wrong and why Ted made his rather fine point. In Ted post, IIRC, he's clear that Rust will unlikely have such needed up code written. But that if people like me boast how Rust would have flat-out refused to compile such code, then we don't know the details and probably aren't in a position to be spouting off on security. A one or two word edit of my original comment would have avoided this whole discussion while retaining the essence that Rust would, in practice, almost certainly eliminate these bugs.
    - tedunangst 12y ago
      I did?
SomeCallMeTim 12y ago
As soon as we have a full port of OpenSSL in Rust, this will be interesting. Talk is cheap; who's going to step up and do the hard work? I do believe that the right developers, using the right practices, could make a more-secure OpenSSL. But it would be expensive in terms of developer time. Maybe a group with the right experience could crowdfund it?
- steveklabnik 12y ago
  There's a #rust-tls channel where people who are interested in this congregate, but I'm not sure of their progress.
- agentultra 12y ago
  Another interesting tack is happening in Mirage with a TLS stack written in OCaml. https://tls.openmirage.org/ https://tls.openmirage.org/
steveklabnik 12y ago
Hi. Rust core here. I like to say that of course Rust prevented Heartbleed, because we don't currently support wrapping malloc ;). That's of course a bit glib. While it's true that Rust gives you a lot of assistance with writing safe code, given that unsafe exists, and that we, as a systems language, need to give you underlying access to the machine, Rust will allow you to do all kinds of stupid things if you vouch to the compiler that you're going to handle the safety aspect. This means that ultimately, you can do any kind of stupid thing in Rust that you can do in any other language. An example: a common problem in C code is buffer overflows, which happens when some code thinks that an array has more elements in it than it does. Because C's arrays don't have a length as part of the type, it can be error prone to keep track of the length of the array. Rust's arrays, vectors, and slices all have a length as a part of the type, and so it's more difficult to have this data be out of sync. But Rust will let you be stupid if you want to: fn bad_stuff(v: Vec<i32>) -> i32 { unsafe { *(v.get_unchecked(v.len() + 1)) } } fn main() { let vec = vec![1, 2, 3]; let val = bad_stuff(vec); println!("{}", val); } The `bad_stuff` function here uses `get_unchecked()`, which skips the array bounds check, to grab some memory past the length of the end of the vector. Rust will happily compile this code, your `unsafe` block tells the compiler to trust that you're using `get_unchecked()` in a safe way, even though it can't verify it. Now, there's a decent discussion that can be had on this topic: 'usual' Rust code will of course be significantly safer than 'usual' C code, since you have the compiler's assistance. Unfortunately, security is often about the edge cases. While it's true that not wrapping malloc would have prevented Heartbleed from happening, and most C projects don't wrap malloc... it did happen. Once Rust starts getting used in the wild, we'll see Rust with security problems, I'm sure of it. That doesn't mean that Rust has no value, just that we need to be realistic about the tradeoffs that any of our technologies make. Rust is not a panacea, even if it does cure some of your aches and pains.
- jonesetc 12y ago
  > That's of course a bit glib. I think you mean it's a bit glibc.
- Rickasaurus 12y ago
  What about adding safer checked buffer types as part of the standard library? A fixed buffer for things of "up to this size" where it remembers how big the current thing is. Seems like it would be a pretty easy problem to fix if you're not playing fast and loose.
MichaelGG 12y ago
Ted's post was a reaction to my overconfident assertion that even with a custom allocator, Rust would prohibit code from compiling that could lead to Heartbleed-like conditions. Furthermore, he was pointing out that random dorks like me talking great about Rust don't seem to actually know what was going on. I was under the impression that Heartbleed was purely out-of-bounds access, and it's not quite just that. (Still, I find it highly unlikely any memory safe language would end up with a real world program reusing the same buffers for SSL keys and user buffers, but it's possible.) Had I been a bit more careful in my claim then there'd have been no question. Ted was technically accurate (the best kind), but a lot of the resulting discussion was of the form "bad coders can always write security holes, therefore a language isn't the fix, so C's OK". Even when major products, like everything MS ships, have critical CVEs almost exclusively due to memory safety, not arbitrary bad logic. Further tptacek likes to point out that memory safety is just one class of sec bugs, and that there's frillions of other bugs in other classes. My suspicion is that this is more of a bias towards app-level stuff (ie command injection in a billion web apps), not systems. I suppose if you get pwnd it doesn't matter how, but a world free of all those MS memsafety RCEs seems like a qualitatively different one. But hey, I'm just some arbitrary weakling, and I find it hard to challenge people that are both smarter and drastically more experienced than I.
- krenoten 12y ago
  Writing widely-deployed infrastructure (web browsers, networking stacks, device drivers, openssl libraries) in C will be less and less justifiable over time. Rust is far from optimized right now. Rust is probably not going to be a language that you will script in. But it is a language that will possibly give Mozilla the world's most secure web browser by a significant margin if they succeed in writing the most bug prone components in Rust. It takes more thought to write Rust programs. If you want to write safer widely-deployed infrastructure, you should learn about it. It may not be your best option right now, but its ideals are those that we absolutely need to strive for. Acting macho about C and the ability to write it safely does not lead to fewer RCE's in the world. It leads to more, because newcomers may see such people who can do so as examples to be emulated, far before they are capable. Note that there are no familiar critics who say that Rust will not prevent some bugs. Note that there are no familiar proponents who claim that Rust will prevent all bugs. It is an implementation that strives to make progress in an area that we can all agree with - the safety of our programs with minimal performance degradation.
copsarebastards 12y ago
I don't see any value in arguing over whether a hypothetical program written in Rust would have had one specific bug. What is more important is whether using a language like Rust will prevent some severe security holes, and the answer is quite obviously that it will. Sure, it's possible to create bugs in any language, but it's much harder to prevent bugs in C than in most languages.
EugeneOZ 12y ago
Can real projects like Servo brag "0 unsafe code"? If not, then this safety is not so practical as it sounds in theory.
- roblabla 12y ago
  if you keep unsafe code contained enough that it is only used in cases where there is no other choice, it's still practical. A simple pointer arithmetic loop over a string in C could lead to very nasty bugs if said string isn't null-terminated (for whatever reason), in rust you wouldn't think of using unsafe code to do that. How much unsafe code does Servo use ? It seems most of the unsafe code blocks I see have a "TODO" block with some explanation of why it's unsafe, and with the express intent of removing the unsafe block eventually.
  - EugeneOZ 12y ago
    today it's "contained enough", tomorrow it's "huge as hell". Code grows, complexity increases. Servo use C++ libraries, so it's far from safe code. Try to use Servo - you will see failures in first minute, I've tried.
    - bjwbell 12y ago
      Failures don't mean unsafe. If you could exploit those failures that would mean unsafe. Try it on servo! Me & other servo contributors would welcome it.
      - EugeneOZ 12y ago
        Don't be so aggressive. If I criticize code, it doesn't mean I criticize people. I tried to say that language injections (such as C++ libs) make Rust apps more fragile. If my assumption is wrong, and all these failures because of Rust code - I apologize.
        bjwbell 12y ago
        I don't know with regards to the failures you saw. For the issues I see & fix most are in rust code. I didn't mean to sound aggressive, we really would welcome reports of safety issues. It's hard to know if servo /really/ is safer without the hundreds of people trying to exploit it that chrome & firefox have. Servo should be safer & I believe it's safer but I don't /know/ it's safer.
moomin 12y ago
Remember: Heartbleed was a consequence of the OpenSSL implementors avoiding using glibc for allocations. A "fair" comparison is with unsafe rust code, which of course can have the problem.
- MichaelGG 12y ago
  Was it? I thought that only exacerbated the issue. malloc is free to return previously used memory, is it not? Various systems might provide some last-chance efforts against this kinda thing, but the bug would still exist and be exploitable in some configurations, right?
  - moomin 12y ago
    Free by the standard, yes. In the average stdlib, not any more. In particular, Linux web servers would be safe, which would have rendered Heartbleed more of a "edge case platforms" kind of bug.
ElectricFeel 12y ago
Heartbleed = 100,000 brokenhearted nerds
jguegant 12y ago
A side question to HN: For the security topic, most of the power of Rust come from a strong typing, safety checks (boundaries), ownership checks... Well, a lot of checks at compile time. As far as I know of Rust by glancing at the doc frequently, C++11/14 also contains these "safe tools": ownership can be dealt with smart pointers (unique, shared), value semantics, move semantics (rvalues) and the rest. Boundaries checks with the correct containers (std::vector, std::array...). Mutability with "const". Atomicity with std::atomic... Type safety by using explicit conversions, templates instead of macros, variadic args... Heck, all the drama from C++ seems to come from a misusage or some legacy parts from another age (up to C). In order to avoid people to shot themselves in their feets, why couldn't we just introduce a strict compilation mode a la JavaScript to let say Clang: # pragma strict # pragma unsafe # pragma safe Nowadays, good C++11 compilers can even deal with such a things like constexpr. This seems a reachable goal. What are the true drawbacks of a fully modern C++ code compared to a Rust? Is there any true feature that can't be done in C++ due to a deep problem of conception? Don't le me wrong, I do not seek to diminished the amazing work of Mozilla. I am not talking neither about the other cool features from functional languages, switch cases... that Rust has and C++ don't.
- gilgoomesh 12y ago
  You're mistaken if you think that anything in C++11/14 makes it memory-safe like Rust guarantees. C++11/14 lets you assign a std::unique_ptr to another variable then re-use the original variable, causing a null dereference. You can also have a reference to the same std::unique_ptr from two different threads causing a race-condition on the underlying pointer. There is no bounds checking on std::vector by default. You can bounds check a std::vector (using "at" or various configuration/compiler settings which change the semantics of the standard library) but by default, it is not checked. Fundamentally, the issue is that C++ lets you have null pointers and references (yes, references can be null). It lets you use before initializing. It lets you run out of bounds. It lets you access the same variable from multiple threads without any safety. Yes, idiomatically, none of these should be an issue but it's not possible to be a perfect programmer. Rust forces idiomatic memory management and eliminates all these issues. If you make a memory safety mistake, the compiler will force you to fix it.
choffee 12y ago
Can you use a Rust library easily from all the current C code?
- steveklabnik 12y ago
  As long as you declare the functions to use a C ABI, yes.

257 points by wasd 12y ago

wglb 12y ago

I disagree about Ted being wrong. A key phrase in Ted's article is Hopefully the simulacrum retains the essence of the problem. What Tedbleed, as your article calls it, demonstrates is a bug similar to Heartbleed: reuse of a buffer in a memory-safe language is susceptible to leakage of secrets. While I might answer the question are Rust’s memory safety features being oversold by uninformed zealots?, no I don't think so, but I would suggest that thinking that memory safety ends all security issues is a not good plan. The key is Unless you venture into the (explicitly demarcated) unsafe portion of Rust, you will not see memory exposure vulnerabilities like Heartbleed: the language does not prevent this. Perhaps your post will stimulate Ted to go further with his example and write an erroneous complete TLS stack in Rust, showing how it too can do Heartbleed. Perhaps you agree that this can be done. Among the scariest mass vulnerabilities relating to total information disclosure, the Padding Oracle Attack, the BEAST attack, the compression flaw CRIME, none have to do with memory safety of languages. Rust there would not have helped one whit. Memory safety is just one issue in writing secure code. Edit: typo

saidajigumi 12y ago
To my knowledge, no one in the Rust or greater memory-safe programming language community would claim: Using <$LANG> prevents leakage of secrets! When put like that, it sounds like a straw-man argument. In my own words, the narrower and stronger claim being made is that the specific and important avenue by which Heartbleed leaked secrets is not possible without unsafe code in Rust. So if you're going to claim that Ted "isn't wrong", but on terms that no one was originally arguing... I don't even know what to say.
- wglb 12y ago
  So if you're going to claim that Ted "isn't wrong", but on terms that no one was originally arguing... Perhaps I am taking a more general implication of this than "Rust would not have exactly reproduced the Heartbleed problem". I infer the overall meaning of Ted's argument, and the general discussion that "Memory safe languages do not prevent information leakage". To me that is what the argument is about.
  - danudey 12y ago
    Nothing 'prevents' information leakage other than writing perfect code 100% of the time. If the argument is that you can write a program in Rust that tells someone something they shouldn't know… is that… what's even the argument here? Is that even a question? But in that case, comparing against Heartbleed is pointless. Why not ask about SQL injection attacks? Or directory traversal attacks? Or OS privilege escalation attacks? Or listening on a port that isn't correctly firewalled? Rust won't prevent any of those either, because none of them have anything to do with the language being used. Arguing that it's possible to write code that does the wrong thing is so pointless that I can't understand why this article was written other than as some kind of half-assed hatchet job.
- lmm 12y ago
  I would claim that using Scala (and presumably Haskell) gives you the tools to make it impossible to leak secrets, if you want to. You could use a path-dependent container type to ensure that content was associated with a particular connection and never passed off to a different connection; if you tried to do something like reusing a buffer, it would be a compile failure. There would be costs to this - both in runtime performance (presumably you wanted to reuse buffers for a reason) and in program complexity. And of course it's possible to make an error in your type definitions (though you have to make two errors to be exploitable - one in the types and one in the values - and the types are shorter and much easier to audit than the full program code). But it absolutely is possible, and I think that pretty soon we'll reach the point where it becomes worthwhile for security-critical code.
  - steveklabnik 12y ago
    Yeah but even Haskell (and I'm assuming Scala has something similar) has unsafePerformIO...
    - codygman 12y ago
      But there is a compiler flag -XSafe which could guarantee none of your code uses it, meaning GP's answer could be yes.
      - steveklabnik 12y ago
        We have that switch in Rust as well.
    - olavk 12y ago
      As far as I understand, unsafePerformIO is not unsafe in relation to memory safety issues. It is just unsafe in that it circumvents the IO monad, which means order of execution is not guaranteed.
      - steveklabnik 12y ago
        It's a different kind of unsafe, but my point is that it violates the normal guarantees of the language.
- deleted 12y ago
  [deleted]
- tedunangst 12y ago
  > specific and important avenue by which Heartbleed leaked secrets is not possible without unsafe code in Rust. Alright. Please clarify. What is the specific and important avenue by which Heartbleed leaked secrets?
  - TheDong 12y ago
    By allowing an attacker to read arbitrary memory of the process that linked against the library In rust, if I write code where I store my secrets in two variables which I pass into my ssl constructor, but retain single ownership of (such that the ssl library may not retain references to them after the constructor exits), there is no way for those exact memory addresses to be read and returned via that library, excepting unsafe. If you say "ah, but the constructor could take a copy and leak that", then that's a different class of vulnerability. It could, but then it would be leaking its memory, not mine.
    - tedunangst 12y ago
      Are we now redefining plaintext passwords and cookies as "not secret"? OpenSSL stored them in the same variable as heartbeat payloads.
      - TheDong 12y ago
        less secret than tls keys, yes. However, that completely does not relate to your question. I'm not saying that they both aren't security vulns, they both are. You asked how heartbleed leaked secrets (implicitly how it was different from the rust code), and I told you how it differs. Where the secrets are stored is different. One is user-supplied secrets only, the other is arbitrary secrets within the process, user-supplied or otherwise. Yes this is different. Your response here is simply moving the goalposts.
        tedunangst 12y ago
        To move the goalposts back to position, I'll answer my own question. The specific and important avenue by which Heartbleed leaked secrets was reusing secret containing buffers and miscalculating the initialized length.
- MichaelGG 12y ago
  My original comment said that even with a custom allocator, Rust would refuse to compile code that could lead to Heartbleed. This was technically not accurate. (I thought HB was just out of bounds+uninitialized behavior.) I think the real key is that in C, this leak can happen with just malloc+forgetting a memset, no explicit buffer reuse required. Whereas in Rust, you'd need to explicitly reuse the buffer.
  - tedunangst 12y ago
    The not compiling part was really what piqued my interest. :)
    - MichaelGG 12y ago
      To be fair, the equivalent of malloc(x) plus a read of x+n bytes wouldn't compile, even with a custom allocator.
      - camgunz 12y ago
        I know next to nothing about rust, but can't you do pretty much whatever you want when you implement a custom allocator? Including allocate a giant buffer ahead of time and reuse stuff with no safety whatsoever?
        MichaelGG 12y ago
        I'm not sure custom allocators exist. But assuming they did, sure you can. But in that case you're explicitly opting into unsafe code to use uninitialized memory. And, even if you did have such an allocator, you still can't read past the end of the allocation. So if you ask for a 16 byte buffer and attempt to read 17, it'll fail.
weland 12y ago
It's extremely important to remember this in context: Heartbleed occurred on OpenBSD because OpenSSL had its own wrapper over malloc(). Instead of actually free()-ing those areas when calling openssl_free(), OpenSSL would leave them untouched and reuse them. If that had not been the case, and free() had in fact been called, reading past the actual payload boundaries would have yielded no useful results, because the malloc() in OpenBSD's libc would have cleared it (as opposed to openssl_malloc(), which was reusing previously un-free()-d zones). In other words: idiomatic C and a sane malloc() implementation could have actually prevented Hearbleed. It makes sense to assume that un-idiomatic Rust and reusing memory without clearing it would trigger the same bug.
- _yosefk 12y ago
  By "sane malloc" do you mean one that gives you "cleared"/zeroed memory? I think it's a rarity and I think programs kinda assume that malloc takes, I dunno, 300-1000 cycles at worst when allocating many megabytes - whereas zeroing such buffers takes much more. Or did I misunderstand your point about "malloc sanity"?
  - Sanddancer 12y ago
    OpenBSD's malloc function is based on mmap, which will give you cleared pages.
    - _yosefk 12y ago
      You mean it always relinquishes pages to the OS upon free and never reuses a page? So every malloc is a memset(0) inside the kernel?
      - weland 12y ago
        Technically yes (although, by default, no), but it's more efficient than that would imply. By default, I think only small chunks are overwritten, so OpenSSL's meagre 64 KB of Heartbleed payload would have been filled with useless junk, whereas multi-megabyte mallocs() in e.g. a RDBMS would have been unaffected. There are some other protection mechanism included, too; there's a more in-depth presentation here: http://www.openbsd.org/papers/eurobsdcon2009/otto-malloc.pdf http://www.openbsd.org/papers/eurobsdcon2009/otto-malloc.pdf
Trufa 12y ago
I don't get your point, what are you trying to say? > What Tedbleed, as your article calls it, demonstrates is a bug similar to Heartbleed Similar but very different in the severity. > but I would suggest that thinking that memory safety ends all security issues is a not good plan. Nobody said that. > The key is Unless you venture into the (explicitly demarcated) unsafe portion of Rust, you will not see memory exposure vulnerabilities like Heartbleed: the language does not prevent this. Sure, if you want to break it, you'll probably can, but you'll have all kinds of warnings before and the few lines where you actually do that, can be proofread the most times. There's nothing preventing you from writing common bugs the generate vulnerability either, but that's simply not possible. > Perhaps your post will stimulate Ted to go further with his example and write an erroneous complete TLS stack in Rust, showing how it too can do Heartbleed. Perhaps you agree that this can be done. Well, Rust may have a memory leak at some point in the future, no software is perfect, but that is one language, that will be review constantly, that is mainly memory safe, the other is one language that is not memory safe where thousands of developers are constantly writing code, inserting lots of heartbleed/memory kind of bugs. > Among the scariest mass vulnerabilities relating to total information disclosure, the Padding Oracle Attack, the BEAST attack, the compression flaw CRIME, none have to do with memory safety of languages. Rust there would not have helped one whit. That's not the point of the article, ted tries to say that hearbleed would be possible, author contradicts this as it shows how the vulnerability would be of different severity.
- tedunangst 12y ago
  The fixation on private keys puzzles me. While they were extractable in some cases, it was difficult. Stealing passwords and cookies was trivial however. And how does one use a stolen key? You have to intercept the traffic first. I can abuse a stolen password from anywhere in the world by using it to log in. Then I can read all your (email, etc.) and don't even need the private key. To differentiate these as "very different in severity" is I think quite misleading.
  - e12e 12y ago
    > The fixation on private keys puzzles me. Really? The private key in asymmetric cryptography should never/is assumed to never be known to anyone other than the key-holder. Session keys are understood to be shared, and so are by definition not secure (equivalently, I can log my part of the "conversation" with a server, even if over TLS with PFS). So session keys, session cookies, transmitted data -- is always known by more than one party, a secret key should never be known by more than one party. It is true that most TLS server deployments don't enforce this -- they don't do the asymmetric operations in a trusted computing module, smart card etc -- but they should. They shouldn't store the key in ram, but they currently do. If you get the secret key, you can do many more things than merely intercept traffic. You can impersonate and fake traffic (fake evidence). In addition to all this, being able to read arbitrary memory controlled by the same process is also worse than being able to read stuff that is already being transmitted. This isn't strictly a Rust/other language issue (I imagine, but do not know, that one eg could sanely (if foolishly) share buffers across thread pools, and so potentially leak information across clients -- this would probably be a design error wrt. trust boundaries etc ... but no-one is arguing that any language can prevent design errors). As mentioned in other comments, privilege separation (a la openssh etc) is a great way to help leverage the os/kernel in order to enforce assumptions about the security primitives used. But that's a little beside the point.

gaius 12y ago

The code that led to the Heartbleed vulnerability was checked in in December 2011. The first pre-Alpha release of Rust was in January 2012 (source: Wikipaedia for both). Would technology from the future have prevented it, is the actual question, and the answer should be obvious...

saidajigumi 12y ago
This rant is disingenuous both to the author's post and the ongoing conversation about the benefits and limitations of memory safe languages. To put it more generously, one might write: Could this specific technology from the future have prevented Heartbleed?
- zzzcpan 12y ago
  I think he has a point. Do we really need this specific technology from the future to prevent Heartbleed? No, because we have ASan and other things like that.
  - wyldfire 12y ago
    ASan is wicked awesome, to be sure. But despite its existence, it's not IMO widely-used, or at least as-widely-used-as-I'd-like.
  - danudey 12y ago
    We also have 'not using a custom malloc() wrapper that doesn't actually free memory as a wrapper around free()' to prevent Heartbleed, but instead of this technology being from the future, it's actually from decades ago.
  - lmm 12y ago
    ASan is a runtime detector; it only works if you have a test case that covers the buggy thing, like in this case sending a malformed heartbeat request. OpenSSL pretty clearly didn't have a test case for that - if they did, they'd've caught the problem, with or without ASan. It's like the difference between a type system and unit testing.

exabrial 12y ago

Ok, maybe, and definitely cool. But Java was supposed to prevent memory leaks but it's still possible :)

vitno 12y ago
I mean, memory leaks are possible in Rust assuming the person explicitly uses unsafe code. However, most code does not use these unsafe blocks... and it should not be possible. Rust has a sound type system that uses linear affine typing. While their implementation is not "proven correct", in practice if the Rust compiler is working properly, leaks will not happen.
- Ygg2 12y ago
  I think it's possible to leak even in safe code if you misuse RC/ARC and the family. EDIT: Box don't leak.
  - kibwen 12y ago
    `Box` won't leak, but `Rc` is just simple reference counting and can leak if you don't use weak pointers to break cycles.
- mercurial 12y ago
  What's keeping you from having a cache and forgetting to expunge it? It's fair to say that you have to work a lot harder in Rust to get a memory leak, while it requires no effort in C/C++, though.
jsight 12y ago
Depending upon your definition of "memory leak" it may be impossible to prevent them at the language level. Java's claim was much narrower than that.
alephnil 12y ago
There is a whole class of memory leaks that is possible in C but not in Java. You can leak memory by forgetting to deallocate it. This class is not possible in typical Java code, because the garbage collector collects it. Then you have memory leaks that happens because the application has data structures that grow unbounded. The latter one is not really preventable by automatic means, because the memory is still referenced from elsewhere in the application, and a garbage collector can't know that this memory won't be accessed again. It does help that the most common source of memory leaks is eliminated however. That many Java applications are memory hogs is more a result of typical Java programming style than anything else.

Someone1234 12y ago

I have a question: How do Rust and Go compare in terms of security? Or are they both very similar in terms of mitigating certain classic C vulnerability classes.

nothrabannosir 12y ago
Zero experience with Rust beyond watching tutorials and talks, please please correct me if Im wrong. Rust has one killer feature that Go does not have: the typesystem has semantics for memory sharing. You can declare how a pointer can be used: is it accessed concurrently, is it local to me, &c. This helps the typesystem detect race conditions where two threads access a block of memory in an unsafe way. Go does not have this. In Go, you "share memory by communicating", instead of "communicating by sharing memory." But if you do want to share memory, you are back to using locks and your own conventions and mechanics to prevent concurrent access. The language doesn't help you. So it's a different programming paradigm. And if you use Go like you would use Rust (memory sharing), then Go is less safe. (...right?) EDIT: This sounds one-sided, but I'm only talking about sharing memory, here. If you don't do that, and stick to communicating, then Go can blow you away. I don't know how Rust deals with coroutines, but Go has super light threads (goroutines) that make concurrent behavior pure joy. All your threads can so easily talk to eachother, and wait for eachother, and it's all so light and native and good! E.g. you have a handler for a POST, but you only want to close the connection when another thread has finished doing something. And you don't want to tie up an entire OS thread, because it could take a while and that's just too expensive. In go: super easy, just do a blocking channel read. In another language? Wow, where would I start... (How does rust do that?)
- slimsag 12y ago
  Using a plain-old mutex in Go isn't encouraged. As you said, the memory model is _share by communicating_. Sometimes, yes, using a mutex makes more sense -- and that does introduce the possibility of a data race. If you follow effective Go code -- I imagine the code is on average about just as safe as Rust code is. It is partially comparable to using `unsafe` blocks in Rust -- don't do it, unless you know what you're doing. Stick with channels.

munin 12y ago

Ted's original point about Heartbleed not being a violation of memory safety is bogus, because there is a configuration of OpenSSL (achievable with flags passed to ./config) where extended-sized Payload values cause the OpenSSL server to segfault with an out of bounds read. It takes a special kind of bravery to look at that kind of crash and say that it is not the result of a violation of memory safety.

tedunangst 12y ago
I'll be the last person to claim there aren't memory safety violations in OpenSSL.
- munin 12y ago
  Yes, but you specifically said that Heartbleed wasn't a memory safety violation, when in fact OpenSSL-vulnerable-to-Heartbleed can segfault on over-read. So what is it?
  - MichaelGG 12y ago
    But Heartbleed still existed even without out-of-bound reads, right? That's the critical distinction I got wrong and why Ted made his rather fine point. In Ted post, IIRC, he's clear that Rust will unlikely have such needed up code written. But that if people like me boast how Rust would have flat-out refused to compile such code, then we don't know the details and probably aren't in a position to be spouting off on security. A one or two word edit of my original comment would have avoided this whole discussion while retaining the essence that Rust would, in practice, almost certainly eliminate these bugs.
  - tedunangst 12y ago
    I did?

SomeCallMeTim 12y ago

As soon as we have a full port of OpenSSL in Rust, this will be interesting. Talk is cheap; who's going to step up and do the hard work? I do believe that the right developers, using the right practices, could make a more-secure OpenSSL. But it would be expensive in terms of developer time. Maybe a group with the right experience could crowdfund it?

steveklabnik 12y ago
There's a #rust-tls channel where people who are interested in this congregate, but I'm not sure of their progress.
agentultra 12y ago
Another interesting tack is happening in Mirage with a TLS stack written in OCaml. https://tls.openmirage.org/ https://tls.openmirage.org/

steveklabnik 12y ago

Hi. Rust core here. I like to say that of course Rust prevented Heartbleed, because we don't currently support wrapping malloc ;). That's of course a bit glib. While it's true that Rust gives you a lot of assistance with writing safe code, given that unsafe exists, and that we, as a systems language, need to give you underlying access to the machine, Rust will allow you to do all kinds of stupid things if you vouch to the compiler that you're going to handle the safety aspect. This means that ultimately, you can do any kind of stupid thing in Rust that you can do in any other language. An example: a common problem in C code is buffer overflows, which happens when some code thinks that an array has more elements in it than it does. Because C's arrays don't have a length as part of the type, it can be error prone to keep track of the length of the array. Rust's arrays, vectors, and slices all have a length as a part of the type, and so it's more difficult to have this data be out of sync. But Rust will let you be stupid if you want to: fn bad_stuff(v: Vec<i32>) -> i32 { unsafe { *(v.get_unchecked(v.len() + 1)) } } fn main() { let vec = vec![1, 2, 3]; let val = bad_stuff(vec); println!("{}", val); } The `bad_stuff` function here uses `get_unchecked()`, which skips the array bounds check, to grab some memory past the length of the end of the vector. Rust will happily compile this code, your `unsafe` block tells the compiler to trust that you're using `get_unchecked()` in a safe way, even though it can't verify it. Now, there's a decent discussion that can be had on this topic: 'usual' Rust code will of course be significantly safer than 'usual' C code, since you have the compiler's assistance. Unfortunately, security is often about the edge cases. While it's true that not wrapping malloc would have prevented Heartbleed from happening, and most C projects don't wrap malloc... it did happen. Once Rust starts getting used in the wild, we'll see Rust with security problems, I'm sure of it. That doesn't mean that Rust has no value, just that we need to be realistic about the tradeoffs that any of our technologies make. Rust is not a panacea, even if it does cure some of your aches and pains.

jonesetc 12y ago
> That's of course a bit glib. I think you mean it's a bit glibc.
Rickasaurus 12y ago
What about adding safer checked buffer types as part of the standard library? A fixed buffer for things of "up to this size" where it remembers how big the current thing is. Seems like it would be a pretty easy problem to fix if you're not playing fast and loose.

MichaelGG 12y ago

Ted's post was a reaction to my overconfident assertion that even with a custom allocator, Rust would prohibit code from compiling that could lead to Heartbleed-like conditions. Furthermore, he was pointing out that random dorks like me talking great about Rust don't seem to actually know what was going on. I was under the impression that Heartbleed was purely out-of-bounds access, and it's not quite just that. (Still, I find it highly unlikely any memory safe language would end up with a real world program reusing the same buffers for SSL keys and user buffers, but it's possible.) Had I been a bit more careful in my claim then there'd have been no question. Ted was technically accurate (the best kind), but a lot of the resulting discussion was of the form "bad coders can always write security holes, therefore a language isn't the fix, so C's OK". Even when major products, like everything MS ships, have critical CVEs almost exclusively due to memory safety, not arbitrary bad logic. Further tptacek likes to point out that memory safety is just one class of sec bugs, and that there's frillions of other bugs in other classes. My suspicion is that this is more of a bias towards app-level stuff (ie command injection in a billion web apps), not systems. I suppose if you get pwnd it doesn't matter how, but a world free of all those MS memsafety RCEs seems like a qualitatively different one. But hey, I'm just some arbitrary weakling, and I find it hard to challenge people that are both smarter and drastically more experienced than I.

krenoten 12y ago
Writing widely-deployed infrastructure (web browsers, networking stacks, device drivers, openssl libraries) in C will be less and less justifiable over time. Rust is far from optimized right now. Rust is probably not going to be a language that you will script in. But it is a language that will possibly give Mozilla the world's most secure web browser by a significant margin if they succeed in writing the most bug prone components in Rust. It takes more thought to write Rust programs. If you want to write safer widely-deployed infrastructure, you should learn about it. It may not be your best option right now, but its ideals are those that we absolutely need to strive for. Acting macho about C and the ability to write it safely does not lead to fewer RCE's in the world. It leads to more, because newcomers may see such people who can do so as examples to be emulated, far before they are capable. Note that there are no familiar critics who say that Rust will not prevent some bugs. Note that there are no familiar proponents who claim that Rust will prevent all bugs. It is an implementation that strives to make progress in an area that we can all agree with - the safety of our programs with minimal performance degradation.

copsarebastards 12y ago

I don't see any value in arguing over whether a hypothetical program written in Rust would have had one specific bug. What is more important is whether using a language like Rust will prevent some severe security holes, and the answer is quite obviously that it will. Sure, it's possible to create bugs in any language, but it's much harder to prevent bugs in C than in most languages.

EugeneOZ 12y ago

Can real projects like Servo brag "0 unsafe code"? If not, then this safety is not so practical as it sounds in theory.

roblabla 12y ago
if you keep unsafe code contained enough that it is only used in cases where there is no other choice, it's still practical. A simple pointer arithmetic loop over a string in C could lead to very nasty bugs if said string isn't null-terminated (for whatever reason), in rust you wouldn't think of using unsafe code to do that. How much unsafe code does Servo use ? It seems most of the unsafe code blocks I see have a "TODO" block with some explanation of why it's unsafe, and with the express intent of removing the unsafe block eventually.
- EugeneOZ 12y ago
  today it's "contained enough", tomorrow it's "huge as hell". Code grows, complexity increases. Servo use C++ libraries, so it's far from safe code. Try to use Servo - you will see failures in first minute, I've tried.
  - bjwbell 12y ago
    Failures don't mean unsafe. If you could exploit those failures that would mean unsafe. Try it on servo! Me & other servo contributors would welcome it.
    - EugeneOZ 12y ago
      Don't be so aggressive. If I criticize code, it doesn't mean I criticize people. I tried to say that language injections (such as C++ libs) make Rust apps more fragile. If my assumption is wrong, and all these failures because of Rust code - I apologize.
      - bjwbell 12y ago
        I don't know with regards to the failures you saw. For the issues I see & fix most are in rust code. I didn't mean to sound aggressive, we really would welcome reports of safety issues. It's hard to know if servo /really/ is safer without the hundreds of people trying to exploit it that chrome & firefox have. Servo should be safer & I believe it's safer but I don't /know/ it's safer.

moomin 12y ago

Remember: Heartbleed was a consequence of the OpenSSL implementors avoiding using glibc for allocations. A "fair" comparison is with unsafe rust code, which of course can have the problem.

MichaelGG 12y ago
Was it? I thought that only exacerbated the issue. malloc is free to return previously used memory, is it not? Various systems might provide some last-chance efforts against this kinda thing, but the bug would still exist and be exploitable in some configurations, right?
- moomin 12y ago
  Free by the standard, yes. In the average stdlib, not any more. In particular, Linux web servers would be safe, which would have rendered Heartbleed more of a "edge case platforms" kind of bug.

ElectricFeel 12y ago

Heartbleed = 100,000 brokenhearted nerds

jguegant 12y ago

A side question to HN: For the security topic, most of the power of Rust come from a strong typing, safety checks (boundaries), ownership checks... Well, a lot of checks at compile time. As far as I know of Rust by glancing at the doc frequently, C++11/14 also contains these "safe tools": ownership can be dealt with smart pointers (unique, shared), value semantics, move semantics (rvalues) and the rest. Boundaries checks with the correct containers (std::vector, std::array...). Mutability with "const". Atomicity with std::atomic... Type safety by using explicit conversions, templates instead of macros, variadic args... Heck, all the drama from C++ seems to come from a misusage or some legacy parts from another age (up to C). In order to avoid people to shot themselves in their feets, why couldn't we just introduce a strict compilation mode a la JavaScript to let say Clang: # pragma strict # pragma unsafe # pragma safe Nowadays, good C++11 compilers can even deal with such a things like constexpr. This seems a reachable goal. What are the true drawbacks of a fully modern C++ code compared to a Rust? Is there any true feature that can't be done in C++ due to a deep problem of conception? Don't le me wrong, I do not seek to diminished the amazing work of Mozilla. I am not talking neither about the other cool features from functional languages, switch cases... that Rust has and C++ don't.

gilgoomesh 12y ago
You're mistaken if you think that anything in C++11/14 makes it memory-safe like Rust guarantees. C++11/14 lets you assign a std::unique_ptr to another variable then re-use the original variable, causing a null dereference. You can also have a reference to the same std::unique_ptr from two different threads causing a race-condition on the underlying pointer. There is no bounds checking on std::vector by default. You can bounds check a std::vector (using "at" or various configuration/compiler settings which change the semantics of the standard library) but by default, it is not checked. Fundamentally, the issue is that C++ lets you have null pointers and references (yes, references can be null). It lets you use before initializing. It lets you run out of bounds. It lets you access the same variable from multiple threads without any safety. Yes, idiomatically, none of these should be an issue but it's not possible to be a perfect programmer. Rust forces idiomatic memory management and eliminates all these issues. If you make a memory safety mistake, the compiler will force you to fix it.

choffee 12y ago

Can you use a Rust library easily from all the current C code?

steveklabnik 12y ago
As long as you declare the functions to use a C ABI, yes.