12 ms·

You know, I totally buy that 70% of the vulnerabilities in complex C++ code relate to memory safety, especially in something like Chromium, which is incredibly

You know, I totally buy that 70% of the vulnerabilities in complex C++ code relate to memory safety, especially in something like Chromium, which is incredibly complex and includes a lot of third-party code that wasn't always designed at first to be robust to untrusted input, and also fast-moving with a ton of code added or churning every week. But I'm not sure I buy that memory-safe languages will consequently be as beneficial for safety (especially in other kinds of software) as that fact would suggest. For one, not all software is like Chromium. If you look at something like OpenSSH, the vast majority of their security holes have nothing to do with memory safety and are just logic bugs (often caused by features that somebody added that aren't core to the basic SSH experience, e.g. code that interfaces with X11 or something) or protocol weaknesses. (http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openssh http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openssh) The other effect is that in practice, memory-safe languages can come with security baggage of their own. If you look at the zillions of security holes in something like Rails or Wordpress or Django, a fair portion of them relate to an attacker's ability to invoke sophisticated-but-unintended behaviors that are more likely to be hiding in these managed languages (and their support libraries) than in something like C++. E.g. CVE-2013-0156 or CVE-2013-0277 or apparently any current Python or Ruby program that, even today, calls yaml.load on untrusted input. That kind of "security hole from unwanted latent functionality" is less likely to exist in C++. (I realize this is a contrarian view not shared by the vast majority of PL/security experts, but the ones I hang out with seem to interpret "memory-safe language" to mean "expert-written Haskell or, if you want to slum it, Rust" and are not thinking "random Ruby/Python/JavaScript/enterprise Java".) Not to mention the countless high-profile security holes that have nothing to do with memory safety, e.g. Shellshock, "goto fail", Lucky Thirteen, BEAST, CRIME, POODLE, FREAK, Logjam, etc. Or bugs that are very relevant to Chromium but aren't really Chromium's fault and probably don't appear on their own list, e.g. Meltdown/Spectre etc.

saagarjha 6y ago
Yes, it is important to note that switching to a memory safe language does not magically solve all your bugs. My own personal anecdote: when I found multiple bypasses in the sandboxing mechanism on macOS, it was not because the relevant code was written in C++, but because the dynamic linker is a really complex system; the things I found clearly flew under the engineer’s radar when they were designing it and they didn’t think beforehand about how those components interacted together. Still, being able to reduce the attack surface area to solely be logic errors is much better than having to deal with memory safety thrown in as well. (Similarly, languages with stricter type systems magically get rid of issues like “you gave me a string and I wanted an int”, but the problems of “you forgot to check the password in this one case” still remain.)
- nindalf 6y ago
  I think reduction in the number of errors is a worthwhile goal. Switching from C++ to a language without memory safety issues while being just as fast would reduce the number of things the developer and code reviewer have to worry about. They could spend more time searching for bugs in the logic, potentially eliminating further issues. In practice what I’ve found is that people prefer to deal in absolutes. A large reduction in a category of bugs isn’t enough, it needs to be eliminated altogether, they say. If it’s still possible in a contrived example, what’s the point of investing in switching?
  - whatshisface 6y ago
    It's a miracle that people who think like that use computers at all - after all, computers only reduce the time it takes to perform a clerical task or a calculation, they do not eliminate it.
    - TeMPOraL 6y ago
      No, it's a reflection of a very important heuristic used in programming (that's arguably much more fundamental on a philosophical level, but correct words to categorize it escape me): the zero-one-many principle. If there's more than one something, you have to treat it as if there may be an unbounded number of something. You can only get it out of your head if you can put reliable bounds on it; the best if you can prove there's less than two of something.
      - rictic 6y ago
        So if you could make your build 70% faster, philosophically it wouldn't matter, because you would still have a build step?
        jfoutz 6y ago
        No, you sort of walked past their point. A thing can happen zero times (never). An example might be 1+1 =0. You could get really unlucky with cosmic rays or something, but really adding two registers, both containing 1, that result isn't going to be zero unless there's some sort of hardware failure. A thing can happen once. an example might be, you can delete a file once. There are ways to get unlucky, of corse, but once it's unlinked it's gone. if it happens more than once, you really should probably think about an unbounded number of times. now days, that sorta means 2^64 times. There will be bugs when something overflows int64, but I hope you get the gist. The parent comment is talking about invariants you can use in an algorithm. I think you might be worried about python vs C or something along those lines. Really, it should all work with a pencil and paper. Which is obviously going to be slower than pushing around electrons. But if you can find those invariants, 0-1-many, you can make a better algorithm. If you're stuck with a pencil it'll still make that faster.
fpoling 6y ago
OpenSSH focuses on security and correctness, not performance. That allows to use simple idiomatic C. Still, as with Chromium, it does use process isolation to mitigate memory-safety bugs.
pvg 6y ago
Not to mention the countless high-profile security holes that have nothing to do with memory safety I'm not sure this is a sensible way to compare - Heartbleed is a memory safety bug and is a bigger bug than the rest of the ones you've listed combined. The various terrifying nameless iOS exploits that have had actual real-world, documented usage are not clever crypto protocol bugs with catchy names, either.
fetbaffe 6y ago
Meltdown & Spectre is actually consequence of C, Intel adapted their CPUs to emulate the architecture that C implements, so you as developer can still believe that you are working close to the metal. However modern CPUs are very complex so the abstraction was leaky, thus bugs. This is why we have to abandon C, not only is the language unsafe, it has also driven hardware manufacturing to a bad state with a reinforcing feedback loop, the more C we write the more hardware manufacturers want to make you believe that we still are working on PDP-11.
- amqpp 6y ago
  Not only that, C is solely responsible for the October revolution and WWII. C was Pol Pot's favorite language and is reportedly used by the Taliban.
  - fetbaffe 6y ago
    Big if true :-) But here is a great article https://queue.acm.org/detail.cfm?id=3212479 https://queue.acm.org/detail.cfm?id=3212479
    - SomeoneFromCA 6y ago
      A very odd article. Everything that said applies to any other compiled programming language, not only C. Even if Pascal or Ada had become more popular than C/C++, it would still have lead to the same architectural decisions we see in x86. In fact the biggest offender - SMT is actually the opposite of instruction-level parallelism the authors are blaming the x86 for.
fetbaffe 6y ago
If Wordpress had been written in C there would probably be even more security vulnerabilities.
- asjw 6y ago
  WordPress Is written in PHP which is written in C
simias 6y ago
I don't understand your argument. You're basically saying "it's possible to write safe code in unsafe languages and vice-versa". Obviously that's true, but I'm not really sure what that tells us. I mean, supposing that Chromium was rewritten in a safer language, have we any reason to believe that these memory issues would be replaced by a similar number of non-memory-safety issues? >That kind of "security hole from unwanted latent functionality" is less likely to exist in C++. Why? That seems like a non-sequitur to me. For me the real difference between the projects you list is that Chromium and OpenSSH are not, as you put it "random Ruby/Python/JavaScript/enterprise Java", they are heavily audited and have a lot of resources allocated into preventing the very issues you mention. Comparing OpenSSH to Wordpress and attributing their respective security track record mainly to the languages they use is fairly absurd IMO. If you're clueless enough not to properly sanitize untrusted input can I really believe that you'd manage to write safe C code? This thread is oddly reminiscent of discussions around gun control. Because something is not 100% effective doesn't mean that it's not valuable. Although I guess we do need these unsafe languages in case we ever need to overthrow a tyrannical government... no wait, I'm getting confused.
- steveklabnik 6y ago
  > Although I guess we do need these unsafe languages in case we ever need to overthrow a tyrannical government... no wait, I'm getting confused. I have heard people say "we rely on exploits to be able to exercise software freedom on locked-down platforms" and "if games were written in Rust, a lot of the glitches speedrunners use would go away and we'd lose our hobby" so... you're not always off.
- ptsneves 6y ago
  Wow. To equate logic errors with being clueless? You do not need to be clueless to not sanitize input. You just need to forget about it, or incorrectly assume the input is safe, or, basically have a bad day. I make bad assumptions and stupid logic mistakes all the time. I guess everybody does because I see logic bugs everywhere. Also you assert it is absurd to compare WordPress and openssh In the context of this argument why? They are both widely used software with very high stakes on their reliability and security. They show very well the contrast that even though one is memory managed and the other is not, that does not stop both having serious bugs. Actually it shows memory management is a don't care variable. On the other hand if chromium finds their project has much more memory management issues than other issues, then yes: memory management for the functionality of chromium seems to be a relevant facto upon which improvements can be done.
fluffything 6y ago
Chromium, Mozilla, and Microsoft have posted studies that attribute ~70% of their security vulnerabilities to memory safety. I'm not sure which point you are trying to make, but yes, 100%-70% = 30%, i.e., there are many security vulnerabilities in Firefox, Chrome and Windows that are not attributed to memory safety by these projects, and preventing memory unsafety wouldn't remove all of them (at most "only" 70% of them). Nobody is claiming here that fixing memory unsafety in software fixes hardware bugs, nor anything about OpenSSH or other projects, and your anecdotes do not show how many security vulnerabilities are caused in those projects due to memory unsafety.

saagarjha 6y ago

Yes, it is important to note that switching to a memory safe language does not magically solve all your bugs. My own personal anecdote: when I found multiple bypasses in the sandboxing mechanism on macOS, it was not because the relevant code was written in C++, but because the dynamic linker is a really complex system; the things I found clearly flew under the engineer’s radar when they were designing it and they didn’t think beforehand about how those components interacted together. Still, being able to reduce the attack surface area to solely be logic errors is much better than having to deal with memory safety thrown in as well. (Similarly, languages with stricter type systems magically get rid of issues like “you gave me a string and I wanted an int”, but the problems of “you forgot to check the password in this one case” still remain.)

nindalf 6y ago
I think reduction in the number of errors is a worthwhile goal. Switching from C++ to a language without memory safety issues while being just as fast would reduce the number of things the developer and code reviewer have to worry about. They could spend more time searching for bugs in the logic, potentially eliminating further issues. In practice what I’ve found is that people prefer to deal in absolutes. A large reduction in a category of bugs isn’t enough, it needs to be eliminated altogether, they say. If it’s still possible in a contrived example, what’s the point of investing in switching?
- whatshisface 6y ago
  It's a miracle that people who think like that use computers at all - after all, computers only reduce the time it takes to perform a clerical task or a calculation, they do not eliminate it.
  - TeMPOraL 6y ago
    No, it's a reflection of a very important heuristic used in programming (that's arguably much more fundamental on a philosophical level, but correct words to categorize it escape me): the zero-one-many principle. If there's more than one something, you have to treat it as if there may be an unbounded number of something. You can only get it out of your head if you can put reliable bounds on it; the best if you can prove there's less than two of something.
    - rictic 6y ago
      So if you could make your build 70% faster, philosophically it wouldn't matter, because you would still have a build step?
      - jfoutz 6y ago
        No, you sort of walked past their point. A thing can happen zero times (never). An example might be 1+1 =0. You could get really unlucky with cosmic rays or something, but really adding two registers, both containing 1, that result isn't going to be zero unless there's some sort of hardware failure. A thing can happen once. an example might be, you can delete a file once. There are ways to get unlucky, of corse, but once it's unlinked it's gone. if it happens more than once, you really should probably think about an unbounded number of times. now days, that sorta means 2^64 times. There will be bugs when something overflows int64, but I hope you get the gist. The parent comment is talking about invariants you can use in an algorithm. I think you might be worried about python vs C or something along those lines. Really, it should all work with a pencil and paper. Which is obviously going to be slower than pushing around electrons. But if you can find those invariants, 0-1-many, you can make a better algorithm. If you're stuck with a pencil it'll still make that faster.

fpoling 6y ago

OpenSSH focuses on security and correctness, not performance. That allows to use simple idiomatic C. Still, as with Chromium, it does use process isolation to mitigate memory-safety bugs.

pvg 6y ago

Not to mention the countless high-profile security holes that have nothing to do with memory safety I'm not sure this is a sensible way to compare - Heartbleed is a memory safety bug and is a bigger bug than the rest of the ones you've listed combined. The various terrifying nameless iOS exploits that have had actual real-world, documented usage are not clever crypto protocol bugs with catchy names, either.

fetbaffe 6y ago

Meltdown & Spectre is actually consequence of C, Intel adapted their CPUs to emulate the architecture that C implements, so you as developer can still believe that you are working close to the metal. However modern CPUs are very complex so the abstraction was leaky, thus bugs. This is why we have to abandon C, not only is the language unsafe, it has also driven hardware manufacturing to a bad state with a reinforcing feedback loop, the more C we write the more hardware manufacturers want to make you believe that we still are working on PDP-11.

amqpp 6y ago
Not only that, C is solely responsible for the October revolution and WWII. C was Pol Pot's favorite language and is reportedly used by the Taliban.
- fetbaffe 6y ago
  Big if true :-) But here is a great article https://queue.acm.org/detail.cfm?id=3212479 https://queue.acm.org/detail.cfm?id=3212479
  - SomeoneFromCA 6y ago
    A very odd article. Everything that said applies to any other compiled programming language, not only C. Even if Pascal or Ada had become more popular than C/C++, it would still have lead to the same architectural decisions we see in x86. In fact the biggest offender - SMT is actually the opposite of instruction-level parallelism the authors are blaming the x86 for.

fetbaffe 6y ago

If Wordpress had been written in C there would probably be even more security vulnerabilities.

asjw 6y ago
WordPress Is written in PHP which is written in C

simias 6y ago

I don't understand your argument. You're basically saying "it's possible to write safe code in unsafe languages and vice-versa". Obviously that's true, but I'm not really sure what that tells us. I mean, supposing that Chromium was rewritten in a safer language, have we any reason to believe that these memory issues would be replaced by a similar number of non-memory-safety issues? >That kind of "security hole from unwanted latent functionality" is less likely to exist in C++. Why? That seems like a non-sequitur to me. For me the real difference between the projects you list is that Chromium and OpenSSH are not, as you put it "random Ruby/Python/JavaScript/enterprise Java", they are heavily audited and have a lot of resources allocated into preventing the very issues you mention. Comparing OpenSSH to Wordpress and attributing their respective security track record mainly to the languages they use is fairly absurd IMO. If you're clueless enough not to properly sanitize untrusted input can I really believe that you'd manage to write safe C code? This thread is oddly reminiscent of discussions around gun control. Because something is not 100% effective doesn't mean that it's not valuable. Although I guess we do need these unsafe languages in case we ever need to overthrow a tyrannical government... no wait, I'm getting confused.

steveklabnik 6y ago
> Although I guess we do need these unsafe languages in case we ever need to overthrow a tyrannical government... no wait, I'm getting confused. I have heard people say "we rely on exploits to be able to exercise software freedom on locked-down platforms" and "if games were written in Rust, a lot of the glitches speedrunners use would go away and we'd lose our hobby" so... you're not always off.
ptsneves 6y ago
Wow. To equate logic errors with being clueless? You do not need to be clueless to not sanitize input. You just need to forget about it, or incorrectly assume the input is safe, or, basically have a bad day. I make bad assumptions and stupid logic mistakes all the time. I guess everybody does because I see logic bugs everywhere. Also you assert it is absurd to compare WordPress and openssh In the context of this argument why? They are both widely used software with very high stakes on their reliability and security. They show very well the contrast that even though one is memory managed and the other is not, that does not stop both having serious bugs. Actually it shows memory management is a don't care variable. On the other hand if chromium finds their project has much more memory management issues than other issues, then yes: memory management for the functionality of chromium seems to be a relevant facto upon which improvements can be done.

fluffything 6y ago

Chromium, Mozilla, and Microsoft have posted studies that attribute ~70% of their security vulnerabilities to memory safety. I'm not sure which point you are trying to make, but yes, 100%-70% = 30%, i.e., there are many security vulnerabilities in Firefox, Chrome and Windows that are not attributed to memory safety by these projects, and preventing memory unsafety wouldn't remove all of them (at most "only" 70% of them). Nobody is claiming here that fixing memory unsafety in software fixes hardware bugs, nor anything about OpenSSH or other projects, and your anecdotes do not show how many security vulnerabilities are caused in those projects due to memory unsafety.