18 ms·

I really think this is the wrong way to look at issues like this. Software has bugs, some of which are security bugs. Whenever someone goes through the effort

I really think this is the wrong way to look at issues like this. Software has bugs, some of which are security bugs. Whenever someone goes through the effort of looking at software from a security perspective, issues might get identified and resolved and as such there is an incremental increase in security. Switching languages requires a full rewrite, which is often not only impractical, it will introduce new bugs as the maturity of the software will plummet because of the rewrite. Then the cycle simply starts again. Some languages have better features that may prevent some classes of security bugs, and Rust is just the new kid on the block. As such, new languages are unproven in the security area and there will be security bugs found there as well. Java and .NET don't have the same issues either but somehow nobody will ask about those :) But then again, Rust introduces other bug types for which the future will tell whether they have a security impact or not: https://gankro.github.io/blah/only-in-rust/ https://gankro.github.io/blah/only-in-rust/ My point of this rambling is that yes, C code is really hard to get right from a security perspective. But software like Apache httpd and OpenSSH demonstrates clearly it can be done. And switching languages is not the answer.

tinco 9y ago
How do Apache and OpenSSH demonstrate that C code can be done right from a security perspective?
- alltakendamned 9y ago
  By the lack of any serious vulnerabilities over the past years. If you're willing to give it a go, an Apache bug would've fetched you 200K$ at the latest Pwn2Own.
  - tinco 9y ago
    Over the past years Apache httpd has had 187 vulnerabilities, 24 of which had potential remote code execution consequences. I'm not saying anyone is ever going to find another RCE in Apache. I'll even go as far as to say it's not very likely. But I don't think develop a server and then put it in the world's most hostile environments for 20 years until we're certain it's safe is a particularily efficient development strategy. People should stop building stuff in C, it's that simple.
    - omginternets 9y ago
      >People should stop building stuff in C, it's that simple. I would attenuate this in one sense and amplify it in another: it's (almost always) irresponsible to write network-facing code in C.
      - pjmlp 9y ago
        Which is why although I dislike some decisions regarding Go's type system, I advocate its use by devops and UNIX userspace apps, the less C the better, regardless if Go has or not generics.
    - alltakendamned 9y ago
      OK, you're not wrong here, but let's qualify your answer a little bit for the people that are less "into this" and to introduce some intellectual honesty in the discussion. Apache has had 187 known vulnerabilities _since 1999_. The full list can be found at http://www.cvedetails.com/product/66/Apache-Http-Server.html?vendor_id=45 http://www.cvedetails.com/product/66/Apache-Http-Server.html... Of the 24 remote code execution bugs you mention, only 4 of them were found in the last 8 years. The one before dates from 2007. Of those 4, only 1 of them was considered critical, and even that one is Windows only. The others don't even breach a CVSS score of 7. So yeah, I stand by my comment that they have a pretty good track records over the past years. And as to stop building stuff in C, I agree that if you start a new project today that depends heavily on network facing code, parsing of untrusted input and does not have massive speed requirements, there are other language choices one could make. But rebuilding Apache in a memory safe language? Oh well, the beauty of open source is that anyone can take a stab at it.
  - hannob 9y ago
    This was pretty bad for openssh: https://www.qualys.com/2016/01/14/cve-2016-0777-cve-2016-0778/openssh-cve-2016-0777-cve-2016-0778.txt https://www.qualys.com/2016/01/14/cve-2016-0777-cve-2016-077...
    - alltakendamned 9y ago
      Agreed. Otoh, last RCE in 2006.
lmm 9y ago
> Switching languages requires a full rewrite Not true when those languages are ABI-compatible. E.g. I believe librsvg is introducing small amounts of Rust that can eventually become a gradual migration. > it will introduce new bugs as the maturity of the software will plummet because of the rewrite. Citation needed. I would expect a rewrite guided by an existing implementation (not the same thing as a rewrite aimed at achieving a from-scratch redesign) to result in fewer bugs as it would effectively be equivalent to a full code review, and that's before we take into account the difference-of-language effects. > As such, new languages are unproven in the security area and there will be security bugs found there as well. No. There are specific reasons C is so awful; it's not a question of maturity. > Java and .NET don't have the same issues either but somehow nobody will ask about those :) People are dumb. There's a popular myth that these languages are inherently slow, which combined with some genuine licensing issues means the OSS community doesn't use them, even though they'd be a perfect fit for OpenVPN-like processes. > But then again, Rust introduces other bug types for which the future will tell whether they have a security impact or not: https://gankro.github.io/blah/only-in-rust/ https://gankro.github.io/blah/only-in-rust/ No, read your link. Those issues happen only in unsafe code, and at absolute worst mean you're as badly off as you would be in C. > software like Apache httpd and OpenSSH demonstrates clearly it can be done Because those programs can go years at a time without a major security vulnerability? Oh wait, no they can't. Switching languages is absolutely the answer, and the sooner we get over ourselves and get on with it the better.
- laumars 9y ago
  > Citation needed. I would expect a rewrite guided by an existing implementation (not the same thing as a rewrite aimed at achieving a from-scratch redesign) to result in fewer bugs as it would effectively be equivalent to a full code review, and that's before we take into account the difference-of-language effects. Humans are fallible. Rewriting the code introduces the possibility that the human coding it might make a mistake. This is true even when using existing code as a guide.
  - lmm 9y ago
    True as far as it goes, but I would still expect the bugs caught by the rewrite to outweigh the newly-introduced ones most of the time.
duneroadrunner 9y ago
> Switching languages requires a full rewrite ... It's not ready for use in the wild, but I'll just mention that some good progress is being made on a "C to SaferCPlusPlus[1]" auto-translation assistant. (SaferCPlusPlus is essentially a memory-safe subset of C++.) At this point it can recognize arrays and "pointers used as array iterators" in C code and replace them with memory-safe substitutes. Hopefully an (incomplete but) usable version will be available before long and we can gauge the interest of developers/maintainers. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus

tinco 9y ago

How do Apache and OpenSSH demonstrate that C code can be done right from a security perspective?

alltakendamned 9y ago
By the lack of any serious vulnerabilities over the past years. If you're willing to give it a go, an Apache bug would've fetched you 200K$ at the latest Pwn2Own.
- tinco 9y ago
  Over the past years Apache httpd has had 187 vulnerabilities, 24 of which had potential remote code execution consequences. I'm not saying anyone is ever going to find another RCE in Apache. I'll even go as far as to say it's not very likely. But I don't think develop a server and then put it in the world's most hostile environments for 20 years until we're certain it's safe is a particularily efficient development strategy. People should stop building stuff in C, it's that simple.
  - omginternets 9y ago
    >People should stop building stuff in C, it's that simple. I would attenuate this in one sense and amplify it in another: it's (almost always) irresponsible to write network-facing code in C.
    - pjmlp 9y ago
      Which is why although I dislike some decisions regarding Go's type system, I advocate its use by devops and UNIX userspace apps, the less C the better, regardless if Go has or not generics.
  - alltakendamned 9y ago
    OK, you're not wrong here, but let's qualify your answer a little bit for the people that are less "into this" and to introduce some intellectual honesty in the discussion. Apache has had 187 known vulnerabilities _since 1999_. The full list can be found at http://www.cvedetails.com/product/66/Apache-Http-Server.html?vendor_id=45 http://www.cvedetails.com/product/66/Apache-Http-Server.html... Of the 24 remote code execution bugs you mention, only 4 of them were found in the last 8 years. The one before dates from 2007. Of those 4, only 1 of them was considered critical, and even that one is Windows only. The others don't even breach a CVSS score of 7. So yeah, I stand by my comment that they have a pretty good track records over the past years. And as to stop building stuff in C, I agree that if you start a new project today that depends heavily on network facing code, parsing of untrusted input and does not have massive speed requirements, there are other language choices one could make. But rebuilding Apache in a memory safe language? Oh well, the beauty of open source is that anyone can take a stab at it.
- hannob 9y ago
  This was pretty bad for openssh: https://www.qualys.com/2016/01/14/cve-2016-0777-cve-2016-0778/openssh-cve-2016-0777-cve-2016-0778.txt https://www.qualys.com/2016/01/14/cve-2016-0777-cve-2016-077...
  - alltakendamned 9y ago
    Agreed. Otoh, last RCE in 2006.

lmm 9y ago

> Switching languages requires a full rewrite Not true when those languages are ABI-compatible. E.g. I believe librsvg is introducing small amounts of Rust that can eventually become a gradual migration. > it will introduce new bugs as the maturity of the software will plummet because of the rewrite. Citation needed. I would expect a rewrite guided by an existing implementation (not the same thing as a rewrite aimed at achieving a from-scratch redesign) to result in fewer bugs as it would effectively be equivalent to a full code review, and that's before we take into account the difference-of-language effects. > As such, new languages are unproven in the security area and there will be security bugs found there as well. No. There are specific reasons C is so awful; it's not a question of maturity. > Java and .NET don't have the same issues either but somehow nobody will ask about those :) People are dumb. There's a popular myth that these languages are inherently slow, which combined with some genuine licensing issues means the OSS community doesn't use them, even though they'd be a perfect fit for OpenVPN-like processes. > But then again, Rust introduces other bug types for which the future will tell whether they have a security impact or not: https://gankro.github.io/blah/only-in-rust/ https://gankro.github.io/blah/only-in-rust/ No, read your link. Those issues happen only in unsafe code, and at absolute worst mean you're as badly off as you would be in C. > software like Apache httpd and OpenSSH demonstrates clearly it can be done Because those programs can go years at a time without a major security vulnerability? Oh wait, no they can't. Switching languages is absolutely the answer, and the sooner we get over ourselves and get on with it the better.

laumars 9y ago
> Citation needed. I would expect a rewrite guided by an existing implementation (not the same thing as a rewrite aimed at achieving a from-scratch redesign) to result in fewer bugs as it would effectively be equivalent to a full code review, and that's before we take into account the difference-of-language effects. Humans are fallible. Rewriting the code introduces the possibility that the human coding it might make a mistake. This is true even when using existing code as a guide.
- lmm 9y ago
  True as far as it goes, but I would still expect the bugs caught by the rewrite to outweigh the newly-introduced ones most of the time.

duneroadrunner 9y ago

> Switching languages requires a full rewrite ... It's not ready for use in the wild, but I'll just mention that some good progress is being made on a "C to SaferCPlusPlus[1]" auto-translation assistant. (SaferCPlusPlus is essentially a memory-safe subset of C++.) At this point it can recognize arrays and "pointers used as array iterators" in C code and replace them with memory-safe substitutes. Hopefully an (incomplete but) usable version will be available before long and we can gauge the interest of developers/maintainers. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus