7 ms·

This is why we need rust. Has Windows and edge and VMware used rust, these bugs wouldn't have happened. Rust is a game changer with it's borrow checker.

scott_karana 10y ago
I love Rust too, but while it likely would have prevented these three bugs, there are many other classes of bugs caused by poorly designed interfaces/abstractions/protocols, misunderstandings, "valid but wrong" logic mistakes, unanticipated interactions, etc. Let's not make magic bullet statements about technology. It's a good way to scare people away...
- newsat13 10y ago
  > while it likely would have prevented these three bugs Isn't that the point of the parent's comment?
  - simion314 10y ago
    I think the point is that Rust fanboy will repeat same thing for years "all security bugs would have been avoided if Rust was used" and when first security issue will be found in Servo or other Rust component(maybe the kernel some Rust devs work on) then Rust reputation will suffer, I see tons of article and blog posts m most of them made to slap the annoyng fanboys that repeated same thing. Btw if they would have used C# then those 3 bugs would not have happen, the thing is that for some work cases you have to do unsafe stuff so C# as Rust has a way to run unsafe code so bug would have happened especially in some low-level code like for a JIT.
    - eridius 10y ago
      OP is correct in saying Rust would have prevented these specific bugs, so I don't understand why you're trying to dismiss them as a "fanboy".
      - simion314 10y ago
        I am 99% sure that OP did not checked the code and made sure that Rust could have been used there without using unsafe, so maybe you could only say "maybe Rust and any other memory safe language would avoid that issue" but since is code related with VMs and JIT you may have use the unsafe things in those languages so maybe it was not avoidable.
        Ygg2 10y ago
        If the type of bug is use after free, double free, race condition or uninitiated memory - Rust would have dealt with it.
        simion314 10y ago
        And if the code was not part of an unsafe section of Rust code. I have nothing against advocating for your favorite software but if you do it wrong by "omitting" things it will backfire, as a Linux user I seen this thing happen, you get some fanboy convincing people to use Linux, usually Arch because that distro attracts fanboys then the new user finds the ugly parts that were not advertised and runs screaming.
        eridius 10y ago
        This is specious reasoning. You have to go out of your way to write unsafe broken code. The default in Rust is for memory safety. Yes, someone could theoretically be using an unsafe block and raw pointers to manipulate a memory buffer. But they probably aren't, because that's generally pretty stupid unless you're implementing a higher-level wrapper around the buffer, which very few people do because there's generally already a wrapper that does what you want (often provided by the stdlib). And even if you are, the unsafe code is contained in a very small area which makes it much easier to review for safety.
        simion314 10y ago
        I was talking about the low level code like in this case where you interact with the kernel, for calling kernel/OS functions you will have to pass pointers and buffers around,I am not sure if you can wrap the kernel functions without making things slower by adding indirection.
    - rapsey 10y ago
      > I think the point is that Rust fanboy will repeat same thing for years "all security bugs would have been avoided if Rust was used" Complete hyperbole. All anyone says is that Rust prevents a class of security issues related to memory access.
- problems 10y ago
  It likely would prevent the vast majority of bugs that are actively exploited in security breaches. Sure, bad logic bugs happen of course, but more often than not they result in bugs relating only to their own area and often somewhat limited in scope. They're also usually a fairly significant mistake that's often times easier to see - not necessarily all the time, but I'm probably more likely to catch a logic bug in a code review than I am a memory issue beyond a missing free. Memory bugs however are much nastier - even a minor mistake can result in a complete takeover of the system as manipulation of the instruction pointer basically means game over and there are many ways to get that with only a little memory manipulation - blow out the stack until you overwrite the return address, overwrite vtables on the heap, overwrite function pointers, etc. Even a minor off-by-one can result in total exploitation in some scenarios.
pka 10y ago
That is definitely why we need to stop using C. It's beyond ridiculous.
- sangnoir 10y ago
  Not as ridiculous as the costs of rewriting monstrous codebases that thousands of people worked on over many years. Let's not lose our sense of scale. Businesses love money more than they love C, if rewriting made economic sense, it wouldn't need to be lobbied.
  - pka 10y ago
    It doesn't make economic sense because VMWare and Microsoft don't have to pay out of pocket if a box in a datacenter is compromised and data is leaked because of bugs in their VMs and kernels that are only possible because of C. This is like hiring somebody to build a bridge, it falling due to incompetence killing hundreds of people and then having nobody suffer any consequences. "Eh, bridges fall, what can you do." Make people pay for buffer overflows and C is gone tomorrow.
    - jacquesm 10y ago
      Make people liable for software bugs and IT will be gone tomorrow.
      - pka 10y ago
        There will always be software bugs. What I'm trying to say is that people should be made liable for avoidable bugs due to incompetence or ill-placed personal preferences ("Real programmers write in C!11"). There are times when C is unavoidable, unfortunately, but when somebody chooses a technology regardless of better, safer alternatives, "just because", they should be made liable, absolutely.
        jacquesm 10y ago
        It's a matter of economics already. There are safer, better alternatives for almost everything we do. But economy dictates that we end up with a compromise. Rust would be just another compromise, slightly different stage, no huge difference and potentially a huge cost. Silver bullets in software development do not exist, rust is no exception to this and the irrational hyping of rust as being a silver bullet actually has the opposite effect. If rust is that much better at all aspects of software development (and not just in preventing one class of bugs) then it will find mainstream adoption. But you don't get that effect by ramming it down other people's throats, you get that effect by showing it in practice. And this is where rust - at least so far - is underwhelming. Also, and this is another point of irritation with me, the rust community makes it seem as if theirs is the only language that will avoid this kind of bug, which is far from true, there are other platforms / languages with far wider adoption that have these traits as well.
jlgaddis 10y ago
Statements like these always remind me of the FUSSP [0]. I'm not anything close to a developer (scripting to scratch my own itches is the extent of any "development" I do) so I can't claim to truly understand the issues other than generally, at a high-level. I've heard variations of this argument -- "Rust will save us!", if I may exaggerate slightly -- many, many times and it seems to be occurring more often lately. It makes me genuinely wonder, then, why isn't the first priority to immediately begin work to rewrite all of the existing "legacy" code in Rust? IIUC, Mozilla has been working on rewriting Firefox is Rust -- which is A Good Thing(TM), it seems -- but that's the only major piece of software I've heard about. If Rust truly is this panacea that it's often made out to be, why is code continuing to be written in anything other than Rust? [0]: https://www.rhyolite.com/anti-spam/you-might-be.html https://www.rhyolite.com/anti-spam/you-might-be.html
- staticassertion 10y ago
  There are many, many factors that need to be taken into account when asking "will this technology succeed" and only one of those factors is "is the technology good/ better than what exists now". Familiarity is a huge one that impacts adoption. There's many other factors discussed. In the book The Diffusion Of Innovation there are two great examples given. The first is a health official trying to convince a town of people to boil their water in order to avoid infection. They utterly failed to convince anyone to do so because the concept of 'germs' was totally unfamiliar to these people, and the need to boil water conflicted with their cultural conception of the issue. The other is dvorak - a keyboard layout that is, by some metric, objectively better than QWERTY. And yet adoption barely exists. The reasons rust is not being used to replace C everywhere are many - Rust is young, many people do not want to learn rust, many people do not care about software security, rust has an unfamiliar syntax/ concepts in it, rust has a younger ecosystem, etc. There is also the issue of liability in software. If I write an internet facing text-parser in C, and it's full of vulnerabilities, I am not liable. My negligence in technology choice (and I do consider it negligence) does not impact liability, unlike any other engineering discipline. So why change?
quickben 10y ago
Every few years there is something. The sandbox, the VMs, Rust, etc. Some things never change.
cesarb 10y ago
While Rust can reduce the chance of these kinds of bugs, it cannot completely prevent them. For instance, the browser Javascript VM will most likely use some form of JIT, which works by generating machine code at runtime, and then executing the generated code. Nothing in the Rust language can prevent a bug in the generated code from being exploitable. And even within pure Rust code, developers can and will do unsafe tricks to get the last few percent points of speed (for instance, storing flags in the least significant bit of pointers). While Rust requires these parts to be marked with "unsafe" (which allows reviewers to focus on them), it cannot prevent bugs caused by these pieces of code.
- staticassertion 10y ago
  This seems like a strawman. "Rust prevents these bugs", "Oh, but Rust doesn't prevent all bugs!".
jacquesm 10y ago
So, instead of making every thread about every security issue ever a lament for how much better the world would have been if everything was written in rust: Where is the rust based OS that is in wide deployment because of its superior performance and bug free nature? It should be a walk in the park to power to world dominance with such a huge difference from the established order. Having the world re-written in rust is roughly the same as having linux on the desktop everywhere. It so far hasn't happened and what the world will look like once it does is anybody's guess, some classes of bugs will disappear, quite possibly. Other classes of bugs may then become more dominant. If rust automatically meant 'bug free software' that would be one thing but there are many classes of bugs and quite a few of those classes will lead to security issues.
- Drdrdrq 10y ago
  >...same as having linux on the desktop everywhere. It so far hasn't happened and... It kind of has, though Linux contributed kernel, not UI. And "desktop" is mobile phone. It's not what everyone had in mind when we talked about Linux on desktop though. But to answer your point about Rust, the reason there is no such OS is that security in itself is not a prevailing factor when people choose OS. Which doesn't make gp's argument false, it just shows why his wishes about Rust in critical software will probably never be granted.
  - jacquesm 10y ago
    The linux on the desktop statements were aimed at displacing windows on the desktop in its traditional role in businesses and homes, something that hasn't really happened. What has happened is that a new class of devices was created that uses linux at the core, but that's not the desktop. (Happy 'linux on the desktop' user here since a very long time, roughly since it supported 'X' and my trusty SGI Indy got too slow to stay with the times). Anybody that wants rust to replace C (or any other language) would be better of coding than complaining.
    - Drdrdrq 10y ago
      I agree, I only wanted to point out the irony of "linux on desktop". It actually happened* (MS failed big time), but not the way it was meant. You had your own SGI Indy? I only had temporary access to one, but loved it at the time... EDIT: it happened at home (mobile), not so much in business.
sidlls 10y ago
Buffer overflows and uninitialized memory are not only possible in Rust (excuse me, "unsafe Rust", as if that were a different thing), if Rust gains any genuine traction and widespread use it is very likely they'll exist "in the wild" and as exploits waiting to be discovered. Rust isn't a panacea or cure-all, and its fans are doing more harm than good (for Rust) by their zealotry on this matter, in my view. And just to make it very clear: I do like Rust. It has some great features that I can envision having an excellent (and superior to C or C++) case for using in certain kinds of systems and application programming. But I'm not convinced these features are as much of a safeguard as some apparently are.
- staticassertion 10y ago
  > (excuse me, "unsafe Rust", as if that were a different thing) They are - there is a world of difference between the two. From a security perspective the ability to audit unsafety explicitly is massive. Right now we rely on intuition and fuzzing at large scale to try to cover massive parts of a codebase. With explicit unsafety you can limit your checks to a subset of modules, rather than the entire program. Massive, massive difference that can not be understated. > if Rust gains any genuine traction and widespread use it is very likely they'll exist "in the wild" and as exploits waiting to be discovered. Naturally. But this certainly isn't worse than where we are now - where languages make 0 effort to be safe, or have far too much historic baggage to do it meaningfully. Beyond that, rust's attitude towards security is pretty positive. Rust has been quick to adopt LLVM sanitizer support, fuzzer support for AFL and cargo-fuzz, and new mitigation techniques such as safestack. With rust's updates coming out quickly you get access to these in a matter of weeks/ months as opposed to years. Rust isn't a cure-all, no one should be calling it one. But your response is overly pessimistic.
  - sidlls 10y ago
    I mostly agree, but I think pessimism and skepticism are very much warranted in the area of security especially. Perhaps doubly so with new languages, and even more with new languages that purport to be safe(r).

scott_karana 10y ago

I love Rust too, but while it likely would have prevented these three bugs, there are many other classes of bugs caused by poorly designed interfaces/abstractions/protocols, misunderstandings, "valid but wrong" logic mistakes, unanticipated interactions, etc. Let's not make magic bullet statements about technology. It's a good way to scare people away...

newsat13 10y ago
> while it likely would have prevented these three bugs Isn't that the point of the parent's comment?
- simion314 10y ago
  I think the point is that Rust fanboy will repeat same thing for years "all security bugs would have been avoided if Rust was used" and when first security issue will be found in Servo or other Rust component(maybe the kernel some Rust devs work on) then Rust reputation will suffer, I see tons of article and blog posts m most of them made to slap the annoyng fanboys that repeated same thing. Btw if they would have used C# then those 3 bugs would not have happen, the thing is that for some work cases you have to do unsafe stuff so C# as Rust has a way to run unsafe code so bug would have happened especially in some low-level code like for a JIT.
  - eridius 10y ago
    OP is correct in saying Rust would have prevented these specific bugs, so I don't understand why you're trying to dismiss them as a "fanboy".
    - simion314 10y ago
      I am 99% sure that OP did not checked the code and made sure that Rust could have been used there without using unsafe, so maybe you could only say "maybe Rust and any other memory safe language would avoid that issue" but since is code related with VMs and JIT you may have use the unsafe things in those languages so maybe it was not avoidable.
      - Ygg2 10y ago
        If the type of bug is use after free, double free, race condition or uninitiated memory - Rust would have dealt with it.
        simion314 10y ago
        And if the code was not part of an unsafe section of Rust code. I have nothing against advocating for your favorite software but if you do it wrong by "omitting" things it will backfire, as a Linux user I seen this thing happen, you get some fanboy convincing people to use Linux, usually Arch because that distro attracts fanboys then the new user finds the ugly parts that were not advertised and runs screaming.
        eridius 10y ago
        This is specious reasoning. You have to go out of your way to write unsafe broken code. The default in Rust is for memory safety. Yes, someone could theoretically be using an unsafe block and raw pointers to manipulate a memory buffer. But they probably aren't, because that's generally pretty stupid unless you're implementing a higher-level wrapper around the buffer, which very few people do because there's generally already a wrapper that does what you want (often provided by the stdlib). And even if you are, the unsafe code is contained in a very small area which makes it much easier to review for safety.
        simion314 10y ago
        I was talking about the low level code like in this case where you interact with the kernel, for calling kernel/OS functions you will have to pass pointers and buffers around,I am not sure if you can wrap the kernel functions without making things slower by adding indirection.
  - rapsey 10y ago
    > I think the point is that Rust fanboy will repeat same thing for years "all security bugs would have been avoided if Rust was used" Complete hyperbole. All anyone says is that Rust prevents a class of security issues related to memory access.
problems 10y ago
It likely would prevent the vast majority of bugs that are actively exploited in security breaches. Sure, bad logic bugs happen of course, but more often than not they result in bugs relating only to their own area and often somewhat limited in scope. They're also usually a fairly significant mistake that's often times easier to see - not necessarily all the time, but I'm probably more likely to catch a logic bug in a code review than I am a memory issue beyond a missing free. Memory bugs however are much nastier - even a minor mistake can result in a complete takeover of the system as manipulation of the instruction pointer basically means game over and there are many ways to get that with only a little memory manipulation - blow out the stack until you overwrite the return address, overwrite vtables on the heap, overwrite function pointers, etc. Even a minor off-by-one can result in total exploitation in some scenarios.

pka 10y ago

That is definitely why we need to stop using C. It's beyond ridiculous.

sangnoir 10y ago
Not as ridiculous as the costs of rewriting monstrous codebases that thousands of people worked on over many years. Let's not lose our sense of scale. Businesses love money more than they love C, if rewriting made economic sense, it wouldn't need to be lobbied.
- pka 10y ago
  It doesn't make economic sense because VMWare and Microsoft don't have to pay out of pocket if a box in a datacenter is compromised and data is leaked because of bugs in their VMs and kernels that are only possible because of C. This is like hiring somebody to build a bridge, it falling due to incompetence killing hundreds of people and then having nobody suffer any consequences. "Eh, bridges fall, what can you do." Make people pay for buffer overflows and C is gone tomorrow.
  - jacquesm 10y ago
    Make people liable for software bugs and IT will be gone tomorrow.
    - pka 10y ago
      There will always be software bugs. What I'm trying to say is that people should be made liable for avoidable bugs due to incompetence or ill-placed personal preferences ("Real programmers write in C!11"). There are times when C is unavoidable, unfortunately, but when somebody chooses a technology regardless of better, safer alternatives, "just because", they should be made liable, absolutely.
      - jacquesm 10y ago
        It's a matter of economics already. There are safer, better alternatives for almost everything we do. But economy dictates that we end up with a compromise. Rust would be just another compromise, slightly different stage, no huge difference and potentially a huge cost. Silver bullets in software development do not exist, rust is no exception to this and the irrational hyping of rust as being a silver bullet actually has the opposite effect. If rust is that much better at all aspects of software development (and not just in preventing one class of bugs) then it will find mainstream adoption. But you don't get that effect by ramming it down other people's throats, you get that effect by showing it in practice. And this is where rust - at least so far - is underwhelming. Also, and this is another point of irritation with me, the rust community makes it seem as if theirs is the only language that will avoid this kind of bug, which is far from true, there are other platforms / languages with far wider adoption that have these traits as well.

jlgaddis 10y ago

Statements like these always remind me of the FUSSP [0]. I'm not anything close to a developer (scripting to scratch my own itches is the extent of any "development" I do) so I can't claim to truly understand the issues other than generally, at a high-level. I've heard variations of this argument -- "Rust will save us!", if I may exaggerate slightly -- many, many times and it seems to be occurring more often lately. It makes me genuinely wonder, then, why isn't the first priority to immediately begin work to rewrite all of the existing "legacy" code in Rust? IIUC, Mozilla has been working on rewriting Firefox is Rust -- which is A Good Thing(TM), it seems -- but that's the only major piece of software I've heard about. If Rust truly is this panacea that it's often made out to be, why is code continuing to be written in anything other than Rust? [0]: https://www.rhyolite.com/anti-spam/you-might-be.html https://www.rhyolite.com/anti-spam/you-might-be.html

staticassertion 10y ago
There are many, many factors that need to be taken into account when asking "will this technology succeed" and only one of those factors is "is the technology good/ better than what exists now". Familiarity is a huge one that impacts adoption. There's many other factors discussed. In the book The Diffusion Of Innovation there are two great examples given. The first is a health official trying to convince a town of people to boil their water in order to avoid infection. They utterly failed to convince anyone to do so because the concept of 'germs' was totally unfamiliar to these people, and the need to boil water conflicted with their cultural conception of the issue. The other is dvorak - a keyboard layout that is, by some metric, objectively better than QWERTY. And yet adoption barely exists. The reasons rust is not being used to replace C everywhere are many - Rust is young, many people do not want to learn rust, many people do not care about software security, rust has an unfamiliar syntax/ concepts in it, rust has a younger ecosystem, etc. There is also the issue of liability in software. If I write an internet facing text-parser in C, and it's full of vulnerabilities, I am not liable. My negligence in technology choice (and I do consider it negligence) does not impact liability, unlike any other engineering discipline. So why change?

quickben 10y ago

Every few years there is something. The sandbox, the VMs, Rust, etc. Some things never change.

cesarb 10y ago

While Rust can reduce the chance of these kinds of bugs, it cannot completely prevent them. For instance, the browser Javascript VM will most likely use some form of JIT, which works by generating machine code at runtime, and then executing the generated code. Nothing in the Rust language can prevent a bug in the generated code from being exploitable. And even within pure Rust code, developers can and will do unsafe tricks to get the last few percent points of speed (for instance, storing flags in the least significant bit of pointers). While Rust requires these parts to be marked with "unsafe" (which allows reviewers to focus on them), it cannot prevent bugs caused by these pieces of code.

staticassertion 10y ago
This seems like a strawman. "Rust prevents these bugs", "Oh, but Rust doesn't prevent all bugs!".

jacquesm 10y ago

So, instead of making every thread about every security issue ever a lament for how much better the world would have been if everything was written in rust: Where is the rust based OS that is in wide deployment because of its superior performance and bug free nature? It should be a walk in the park to power to world dominance with such a huge difference from the established order. Having the world re-written in rust is roughly the same as having linux on the desktop everywhere. It so far hasn't happened and what the world will look like once it does is anybody's guess, some classes of bugs will disappear, quite possibly. Other classes of bugs may then become more dominant. If rust automatically meant 'bug free software' that would be one thing but there are many classes of bugs and quite a few of those classes will lead to security issues.

Drdrdrq 10y ago
>...same as having linux on the desktop everywhere. It so far hasn't happened and... It kind of has, though Linux contributed kernel, not UI. And "desktop" is mobile phone. It's not what everyone had in mind when we talked about Linux on desktop though. But to answer your point about Rust, the reason there is no such OS is that security in itself is not a prevailing factor when people choose OS. Which doesn't make gp's argument false, it just shows why his wishes about Rust in critical software will probably never be granted.
- jacquesm 10y ago
  The linux on the desktop statements were aimed at displacing windows on the desktop in its traditional role in businesses and homes, something that hasn't really happened. What has happened is that a new class of devices was created that uses linux at the core, but that's not the desktop. (Happy 'linux on the desktop' user here since a very long time, roughly since it supported 'X' and my trusty SGI Indy got too slow to stay with the times). Anybody that wants rust to replace C (or any other language) would be better of coding than complaining.
  - Drdrdrq 10y ago
    I agree, I only wanted to point out the irony of "linux on desktop". It actually happened* (MS failed big time), but not the way it was meant. You had your own SGI Indy? I only had temporary access to one, but loved it at the time... EDIT: it happened at home (mobile), not so much in business.

sidlls 10y ago

Buffer overflows and uninitialized memory are not only possible in Rust (excuse me, "unsafe Rust", as if that were a different thing), if Rust gains any genuine traction and widespread use it is very likely they'll exist "in the wild" and as exploits waiting to be discovered. Rust isn't a panacea or cure-all, and its fans are doing more harm than good (for Rust) by their zealotry on this matter, in my view. And just to make it very clear: I do like Rust. It has some great features that I can envision having an excellent (and superior to C or C++) case for using in certain kinds of systems and application programming. But I'm not convinced these features are as much of a safeguard as some apparently are.

staticassertion 10y ago
> (excuse me, "unsafe Rust", as if that were a different thing) They are - there is a world of difference between the two. From a security perspective the ability to audit unsafety explicitly is massive. Right now we rely on intuition and fuzzing at large scale to try to cover massive parts of a codebase. With explicit unsafety you can limit your checks to a subset of modules, rather than the entire program. Massive, massive difference that can not be understated. > if Rust gains any genuine traction and widespread use it is very likely they'll exist "in the wild" and as exploits waiting to be discovered. Naturally. But this certainly isn't worse than where we are now - where languages make 0 effort to be safe, or have far too much historic baggage to do it meaningfully. Beyond that, rust's attitude towards security is pretty positive. Rust has been quick to adopt LLVM sanitizer support, fuzzer support for AFL and cargo-fuzz, and new mitigation techniques such as safestack. With rust's updates coming out quickly you get access to these in a matter of weeks/ months as opposed to years. Rust isn't a cure-all, no one should be calling it one. But your response is overly pessimistic.
- sidlls 10y ago
  I mostly agree, but I think pessimism and skepticism are very much warranted in the area of security especially. Perhaps doubly so with new languages, and even more with new languages that purport to be safe(r).