3 ms·

It boggles the mind how utterly misguided the "let's rewrite everything in Rust!" people are when it comes to understanding security and its implications. Let

It boggles the mind how utterly misguided the "let's rewrite everything in Rust!" people are when it comes to understanding security and its implications. Let me begin by introducing my premise: Rust will do NOTHING for security, it is not an improvement in any way, and at least as far as security is concerned, it will lead to at best colossal time waste, at worst actively damage the cause by misdirection, making ppl feel warm and fuzzy, providing illusion of security. What??? B-b-but memory safety, I hear you say. How can this even be possible I hear you cry. Memory safety (assuming that Rust completely solves it, which it absolutely DOES NOT) is but one (small) piece of the entire puzzle. In the same way that the skilled craftsman knows that he can't build a castle on top of sand, the skilled (and security conscious) software engineer should realize that memory corruption (and race conditions in the same unit/process) are not the foundation of the security chain. I dare say that a lot of the bugs exploited out there today (but not necessarily made public), are pure LOGIC bugs (that include race conditions) that stem from the interactions between extremely complex autonomous subsystems. Rust is simply operating at a too high-level abstraction layer to deal with any of these issues. This is the logical progression of Sergey Bratus's weird machines taken to the next level. Some examples: The Linux kernel. Any UNIX operating system taken as a whole. Any Windows taken as a whole. Any OSX system. Anything built on top any of the above. Anything built on combinations of any of the above. Weird machines are not limited to isolated units, you know, they very well exhibit EMERGENT behavior. Are you starting to get the picture now? And then of course we still have the bugs that stem from unsafe languages, as long as there's a path that cuts through all the intermediate layers of "safe" code. Graphics drivers and webgl anyone? Truetype in the kernel? Rust has plenty of things in its favor but to position it as a cure for issues that it doesn't even know how to address is a colossal mistake. We have given rise to a beast that threatens to consume us all. It's one thing to despair due to the immense complexity of the domain and quite another to step into an imaginary realm and solve illusionary problems that we create just to feel "safe".

geofft 11y ago
It boggles the mind how people think the only benefit of Rust is memory safety. Rust has novel features for solving concurrency issues, what you call "pure LOGIC bugs (that include race conditions)". Of course memory safety is one small piece of the entire puzzle. That's why Rust has features besides just being a memory-safe version of C.
- armitron 11y ago
  Read my post again cause you obviously didn't understand anything of what I wrote. You can have 2 components written in 100% safe language with no memory corruption and no race conditions. You can have security critical race conditions that arise out of the interaction of same components. How is Rust or whatever solving this? It doesn't.
  - geofft 11y ago
    Rust isn't just a safe language. It has other features. For instance, it's a much more strongly-typed language. You can use strong type systems to solve that exact problem. If you give me a more concrete example, besides "you can have race conditions," I can give you a more concrete way Rust fixes it, besides "you can use types."
    - armitron 11y ago
      You still don't get it (this exchange is a great example of how hard it is for ordinary technically-minded people to shift into the proper mindset and begin to understand what the real issues are). The race conditions I refer to DO NOT EXIST in the static pieces of code written in Rust or whatever ivory tower language. They are EMERGENT pieces of DYNAMIC behavior that only manifest at RUNTIME due to subsystem interactions. And by subsystem I don't just mean pieces of code...
      - sanderjd 11y ago
        Can you give a concrete example of a recent major security issue caused by the sort of dynamically emergent interaction you're referring to? Anecdotally, the hair-on-fire security issues in fundamental components that keep coming up always seem to involve unsafe memory usage.
        bpicolo 11y ago
        Buffer overflows seem to be a pretty recurring theme in these security issues, yep.
_ph_ 11y ago
I have trouble understanding what you try to say - but a library like glibc must not have memory corruption problems to start with. Clearly, it seems that currently it has those problems. Either you can find maintainers for the C code which will never create a memory corruption problem, or use a tool which assists the maintainers with this. Also, more modern languages than C would in general make the code more maintainable, again helping with weeding out security problems, be they coming from memory corruption or any other cause.
- armitron 11y ago
  You assume that a glibc written in Rust would not have memory corruption problems. This is a naive assumption. I'll leave you to discover why.
  - geofft 11y ago
    If you are not putting forward an argument, then you are not contributing to the conversation, just wasting people's time reading your comment. Therefore I am downvoting you. There are cogent arguments to be made about why Rust isn't a panacea. (I have a few I'm partial to, like integer overflow / truncation bugs.) But if you want people to listen to those arguments, make them.
  - Someone1234 11y ago
    It would likely have LESS memory corruption problems, as you're eliminating places in the code that that can occur. The real question is: Does Rust allow you to write less bugs? That's a somewhat open question, but it definitely eliminates certain classes of bugs which are common today.
    - neikos 11y ago
      From intensive but still hobby usage for the past 10+ months I get a feeling that I have a lot /less/ bugs, and if I do have one it is an algorithmical error rather than some UB. This is of course just my view and is heavily skewed towards what I usually do, which is Games and Web Apps. It also depends on how you qualify a bug. (Is a panic a bug? Might or might not be.) To continue that train of thought: I have a feeling Rust will change what one would consider a bug (inside the Rust ecosystem at least). Since you do not actually corrupt memory most of the time (minus unsafe shenanigans) you actually do not get a lot of cases where you get a crash and you don't know why. RUST_BACKTRACE always told me where something panicked which is pretty much always sufficient to debug since you just have to verify your invariants you thought were correct when you for example 'unwrap' or call panic! yourself.
ohnomrbill 11y ago
Viewing Rust as a panacea for security issues is certainly misguided. However, people should at least attempt to use a more memory safe language to write this stuff. If it proves to be worse code, then we're not forced to use it - we already have getaddrinfo to fall back on.
topspin 11y ago
There were about 36 000 traffic fatalities in the US in 2015. This is inherent to the trillions of miles traveled in affordable machines operated by drivers of variable competence, and nobody has a solution to fix the problem today. Maybe one will emerge, but between now and that day we're going to keep driving and keep killing each other. Should engineers, admittedly lacking an absolute solution to traffic fatalities, forego seeking designs and materials that reduce the frequency and consequences of failure? Rust delivers a higher degree of memory safety. It is a better tool in the tool box and arguing that engineers should ignore it because their efforts are inherently flawed won't work, any more than arguing that a new headlamp or traffic light design is futile. Also, you should understand now what you're up against. The legacy stack is riddled with flaws; every day we face a deluge of security notices, some large fraction of which are caused by memory safety problems. In other words, your opponents in this debate have an endless supply of ammunition. Good luck with that.
- Alupis 11y ago
  > here were about 36 000 traffic fatalities in the US in 2015 > nobody has a solution to fix the problem today. You're entire premise revolves around 0.01% of the population. That's not a good basis. There's about 34,000 automobile related deaths annually in the US[1]. There's about 323,000,000 people in the US.[2] The point I'm making, is let's not get carried away with exaggerating how "bad" a "problem" is. According to the CDC, more people die annually from accidental poisoning (about 39,000) than automobile related accidents - but I don't hear all the calls to "solve" that problem. Will things be "safer" written in Rust? Maybe. Does Rust solve everything? Absolutely not. Yes, a lot of bugs are "unsafe" memory access issues, but a lot of bugs are not. Re-writing everything in a pet language that happens to be popular today in 2016 is not a good call. Rust is fairly new, and nobody has any idea if it will stand the test of time. C has, clearly. Instead of getting out our pitchforks, we should rally to guarantee these critical projects are fully funded and staffed with full time developers. That alone, will yield far greater results than some lofty goal of completely re-writing 100's of thousands of lines of code which have been working, tested, and matured for almost 3 decades. [1] http://www.cdc.gov/nchs/fastats/accidental-injury.htm http://www.cdc.gov/nchs/fastats/accidental-injury.htm [2] http://www.census.gov/popclock/ http://www.census.gov/popclock/
feintruled 11y ago
One of my personal internet observations is that any post containing the formulation "b-b-but" is a bad one. Usually betrays a sort of sarcastic know-it-all attitude. I see you've used it. I think it sets a bad tone for an argument.
- JoeAltmaier 11y ago
  My rule for internet observations is, any post containing "you" is argumentative and off topic. The topic is never the other commenter. Using "you" is often received as a personal affront, derailing the conversation. It betrays a me-vs-you superior attitude?
  - feintruled 11y ago
    Not a bad rule, I have to admit (and true in my case, my post was certainly off topic). As a general rule it's a bit broad though, I think. If one wants to address another's points directly, it can be hard to avoid the second person pronoun.
    - JoeAltmaier 11y ago
      It takes practice. Addressing the points as points instead of something 'you' said is about all there is to it. But we're so used to conversational modes, its easy to fall back.
pcwalton 11y ago
> Memory safety (assuming that Rust completely solves it, which it absolutely DOES NOT) is but one (small) piece of the entire puzzle. Visit https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-767/GNU-Glibc.html https://www.cvedetails.com/vulnerability-list/vendor_id-72/p.... Count the number of memory safety issues. The first five, for example, are all memory safety problems.

geofft 11y ago

It boggles the mind how people think the only benefit of Rust is memory safety. Rust has novel features for solving concurrency issues, what you call "pure LOGIC bugs (that include race conditions)". Of course memory safety is one small piece of the entire puzzle. That's why Rust has features besides just being a memory-safe version of C.

armitron 11y ago
Read my post again cause you obviously didn't understand anything of what I wrote. You can have 2 components written in 100% safe language with no memory corruption and no race conditions. You can have security critical race conditions that arise out of the interaction of same components. How is Rust or whatever solving this? It doesn't.
- geofft 11y ago
  Rust isn't just a safe language. It has other features. For instance, it's a much more strongly-typed language. You can use strong type systems to solve that exact problem. If you give me a more concrete example, besides "you can have race conditions," I can give you a more concrete way Rust fixes it, besides "you can use types."
  - armitron 11y ago
    You still don't get it (this exchange is a great example of how hard it is for ordinary technically-minded people to shift into the proper mindset and begin to understand what the real issues are). The race conditions I refer to DO NOT EXIST in the static pieces of code written in Rust or whatever ivory tower language. They are EMERGENT pieces of DYNAMIC behavior that only manifest at RUNTIME due to subsystem interactions. And by subsystem I don't just mean pieces of code...
    - sanderjd 11y ago
      Can you give a concrete example of a recent major security issue caused by the sort of dynamically emergent interaction you're referring to? Anecdotally, the hair-on-fire security issues in fundamental components that keep coming up always seem to involve unsafe memory usage.
      - bpicolo 11y ago
        Buffer overflows seem to be a pretty recurring theme in these security issues, yep.

_ph_ 11y ago

I have trouble understanding what you try to say - but a library like glibc must not have memory corruption problems to start with. Clearly, it seems that currently it has those problems. Either you can find maintainers for the C code which will never create a memory corruption problem, or use a tool which assists the maintainers with this. Also, more modern languages than C would in general make the code more maintainable, again helping with weeding out security problems, be they coming from memory corruption or any other cause.

armitron 11y ago
You assume that a glibc written in Rust would not have memory corruption problems. This is a naive assumption. I'll leave you to discover why.
- geofft 11y ago
  If you are not putting forward an argument, then you are not contributing to the conversation, just wasting people's time reading your comment. Therefore I am downvoting you. There are cogent arguments to be made about why Rust isn't a panacea. (I have a few I'm partial to, like integer overflow / truncation bugs.) But if you want people to listen to those arguments, make them.
- Someone1234 11y ago
  It would likely have LESS memory corruption problems, as you're eliminating places in the code that that can occur. The real question is: Does Rust allow you to write less bugs? That's a somewhat open question, but it definitely eliminates certain classes of bugs which are common today.
  - neikos 11y ago
    From intensive but still hobby usage for the past 10+ months I get a feeling that I have a lot /less/ bugs, and if I do have one it is an algorithmical error rather than some UB. This is of course just my view and is heavily skewed towards what I usually do, which is Games and Web Apps. It also depends on how you qualify a bug. (Is a panic a bug? Might or might not be.) To continue that train of thought: I have a feeling Rust will change what one would consider a bug (inside the Rust ecosystem at least). Since you do not actually corrupt memory most of the time (minus unsafe shenanigans) you actually do not get a lot of cases where you get a crash and you don't know why. RUST_BACKTRACE always told me where something panicked which is pretty much always sufficient to debug since you just have to verify your invariants you thought were correct when you for example 'unwrap' or call panic! yourself.

ohnomrbill 11y ago

Viewing Rust as a panacea for security issues is certainly misguided. However, people should at least attempt to use a more memory safe language to write this stuff. If it proves to be worse code, then we're not forced to use it - we already have getaddrinfo to fall back on.

topspin 11y ago

There were about 36 000 traffic fatalities in the US in 2015. This is inherent to the trillions of miles traveled in affordable machines operated by drivers of variable competence, and nobody has a solution to fix the problem today. Maybe one will emerge, but between now and that day we're going to keep driving and keep killing each other. Should engineers, admittedly lacking an absolute solution to traffic fatalities, forego seeking designs and materials that reduce the frequency and consequences of failure? Rust delivers a higher degree of memory safety. It is a better tool in the tool box and arguing that engineers should ignore it because their efforts are inherently flawed won't work, any more than arguing that a new headlamp or traffic light design is futile. Also, you should understand now what you're up against. The legacy stack is riddled with flaws; every day we face a deluge of security notices, some large fraction of which are caused by memory safety problems. In other words, your opponents in this debate have an endless supply of ammunition. Good luck with that.

Alupis 11y ago
> here were about 36 000 traffic fatalities in the US in 2015 > nobody has a solution to fix the problem today. You're entire premise revolves around 0.01% of the population. That's not a good basis. There's about 34,000 automobile related deaths annually in the US[1]. There's about 323,000,000 people in the US.[2] The point I'm making, is let's not get carried away with exaggerating how "bad" a "problem" is. According to the CDC, more people die annually from accidental poisoning (about 39,000) than automobile related accidents - but I don't hear all the calls to "solve" that problem. Will things be "safer" written in Rust? Maybe. Does Rust solve everything? Absolutely not. Yes, a lot of bugs are "unsafe" memory access issues, but a lot of bugs are not. Re-writing everything in a pet language that happens to be popular today in 2016 is not a good call. Rust is fairly new, and nobody has any idea if it will stand the test of time. C has, clearly. Instead of getting out our pitchforks, we should rally to guarantee these critical projects are fully funded and staffed with full time developers. That alone, will yield far greater results than some lofty goal of completely re-writing 100's of thousands of lines of code which have been working, tested, and matured for almost 3 decades. [1] http://www.cdc.gov/nchs/fastats/accidental-injury.htm http://www.cdc.gov/nchs/fastats/accidental-injury.htm [2] http://www.census.gov/popclock/ http://www.census.gov/popclock/

feintruled 11y ago

One of my personal internet observations is that any post containing the formulation "b-b-but" is a bad one. Usually betrays a sort of sarcastic know-it-all attitude. I see you've used it. I think it sets a bad tone for an argument.

JoeAltmaier 11y ago
My rule for internet observations is, any post containing "you" is argumentative and off topic. The topic is never the other commenter. Using "you" is often received as a personal affront, derailing the conversation. It betrays a me-vs-you superior attitude?
- feintruled 11y ago
  Not a bad rule, I have to admit (and true in my case, my post was certainly off topic). As a general rule it's a bit broad though, I think. If one wants to address another's points directly, it can be hard to avoid the second person pronoun.
  - JoeAltmaier 11y ago
    It takes practice. Addressing the points as points instead of something 'you' said is about all there is to it. But we're so used to conversational modes, its easy to fall back.

pcwalton 11y ago

> Memory safety (assuming that Rust completely solves it, which it absolutely DOES NOT) is but one (small) piece of the entire puzzle. Visit https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-767/GNU-Glibc.html https://www.cvedetails.com/vulnerability-list/vendor_id-72/p.... Count the number of memory safety issues. The first five, for example, are all memory safety problems.