7 ms·

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 l

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 examine every security advisory published by Microsoft over a year or two span, and that, from the descriptions, Rust would have prevented basically every serious (code exec) one. (Notable exceptions being failures in the sandboxed code loading, similar to the various Java in browser bugs.)

pcwalton 12y ago
Others at Mozilla and I have done similar studies with our Gecko critical security bugs. The number of them that Rust would have prevented are staggering. I've always been careful not to claim that Servo will have no security flaws. It will, and some of them will be critical. But nobody denies that sandboxing is a powerful defense because Pinkie Pie found some sandbox escapes in the Pwnium contest. Likewise, let's not understate the benefits of memory safety: our studies have shown that the vast majority of critical security bugs in Gecko layout and graphics code are simple memory safety vulnerabilities like buffer overruns or use-after-free.
- tptacek 12y ago
  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-compiled] has security implications for systems programming. But developers shouldn't be swapping their Python code for Rust if security is their primary objective.
  - masklinn 12y ago
    > But that's perhaps a performance and logistical advance, not a security advance. Isn't it both, depending where you come from? And isn't decreasing the performance/security tradeoff a security advance when developers in the domain do not want to compromise on performance? > But developers shouldn't be swapping their Python code for Rust if security is their primary objective. OTOH developers building up security primitives/building blocks aren't doing so in Python in the first place, and doing so in Python would mean it's not easily accessible for {anyone not using Python}.
    - tptacek 12y ago
      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.
      - masklinn 12y ago
        Yeah Rust isn't safer than an already memory-safe language (though it might be faster, then again it's also quite a bit more work wrt e.g. Go). but > Don't write C/C++ in 2015. That probably isn't going to stop, even ignoring performance ricers the bottom of the stack does need control, does need good performances, and more importantly does need to be usable from just about everywhere. You can't really/easily use a scala library from MRI, or a CPython one from Go (it's already hard enough to use a CPython library from Pypy). If there's a C interface and little to no runtime assumption however you're good to go. Currently that means C or C++ (with a nice extern C ABI/API). If it could be something safer in the future, that would probably be a good idea.
        bad_user 12y ago
        > 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).
legulere 12y ago
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: Actually heartbleed is a buffer over-read vulnerability that would have been prevented by rust's out of bounds checking. Of course you could allocate one huge buffer that contains sensitive data and is also used as an output buffer but this seems terribly unlikely to me.
- akerl_ 12y ago
  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.
  - MichaelGG 12y ago
    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.
    - akerl_ 12y ago
      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.
  - legulere 12y ago
    There was no buffer reuse like in the linked rust demonstration, but it was data from previous allocations.
AnthonyMouse 12y ago
> 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. People have been trying to make a language better than C++ for the things that C++ is good at for decades and this is the first time anything has the potential to succeed. That's why I argue for the other side. Because when something has obvious potential, people have the inclination to deify it. The statement "X will solve all security problems" is false for all X. You can write secure code in C (see also DJB). You can write insecure code in Rust. It's easier to write secure code in Rust, and that's very important, but it's just as important for everybody to realize that no compiler is made out of magic pixie dust that will make all my code perfect even if I'm an idiot.
- MichaelGG 12y ago
  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?
  - AnthonyMouse 12y ago
    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?
hackuser 12y ago
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.
ertdfgcb 12y ago
> 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.

pcwalton 12y ago

Others at Mozilla and I have done similar studies with our Gecko critical security bugs. The number of them that Rust would have prevented are staggering. I've always been careful not to claim that Servo will have no security flaws. It will, and some of them will be critical. But nobody denies that sandboxing is a powerful defense because Pinkie Pie found some sandbox escapes in the Pwnium contest. Likewise, let's not understate the benefits of memory safety: our studies have shown that the vast majority of critical security bugs in Gecko layout and graphics code are simple memory safety vulnerabilities like buffer overruns or use-after-free.

tptacek 12y ago
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-compiled] has security implications for systems programming. But developers shouldn't be swapping their Python code for Rust if security is their primary objective.
- masklinn 12y ago
  > But that's perhaps a performance and logistical advance, not a security advance. Isn't it both, depending where you come from? And isn't decreasing the performance/security tradeoff a security advance when developers in the domain do not want to compromise on performance? > But developers shouldn't be swapping their Python code for Rust if security is their primary objective. OTOH developers building up security primitives/building blocks aren't doing so in Python in the first place, and doing so in Python would mean it's not easily accessible for {anyone not using Python}.
  - tptacek 12y ago
    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.
    - masklinn 12y ago
      Yeah Rust isn't safer than an already memory-safe language (though it might be faster, then again it's also quite a bit more work wrt e.g. Go). but > Don't write C/C++ in 2015. That probably isn't going to stop, even ignoring performance ricers the bottom of the stack does need control, does need good performances, and more importantly does need to be usable from just about everywhere. You can't really/easily use a scala library from MRI, or a CPython one from Go (it's already hard enough to use a CPython library from Pypy). If there's a C interface and little to no runtime assumption however you're good to go. Currently that means C or C++ (with a nice extern C ABI/API). If it could be something safer in the future, that would probably be a good idea.
      - bad_user 12y ago
        > 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).

legulere 12y ago

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: Actually heartbleed is a buffer over-read vulnerability that would have been prevented by rust's out of bounds checking. Of course you could allocate one huge buffer that contains sensitive data and is also used as an output buffer but this seems terribly unlikely to me.

akerl_ 12y ago
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.
- MichaelGG 12y ago
  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.
  - akerl_ 12y ago
    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.
- legulere 12y ago
  There was no buffer reuse like in the linked rust demonstration, but it was data from previous allocations.

AnthonyMouse 12y ago

> 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. People have been trying to make a language better than C++ for the things that C++ is good at for decades and this is the first time anything has the potential to succeed. That's why I argue for the other side. Because when something has obvious potential, people have the inclination to deify it. The statement "X will solve all security problems" is false for all X. You can write secure code in C (see also DJB). You can write insecure code in Rust. It's easier to write secure code in Rust, and that's very important, but it's just as important for everybody to realize that no compiler is made out of magic pixie dust that will make all my code perfect even if I'm an idiot.

MichaelGG 12y ago
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?
- AnthonyMouse 12y ago
  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?

hackuser 12y ago

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.

ertdfgcb 12y ago

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