5 ms·

I’m gonna take the burden (someone would do that eventually anyway) and ask: how many of those issues would have been completely prevented by using a safer lang

by yuchi 9y ago

I’m gonna take the burden (someone would do that eventually anyway) and ask: how many of those issues would have been completely prevented by using a safer language such as Rust? How many would have been mitigated? I’m not a system programmer and the article, while indeed interesting, can be a little obscure.

alltakendamned 9y ago
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.
- 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
19218391 9y ago
We can answer that question when (if?) people actually start writing programs in Rust instead of speculating.
willvarfar 9y ago
Many of these bugs are specific to memory-unsafe languages. Writing in a memory-safe language would prevent many of these vulnerabilities. It would not stop all vulnerabilities.
- eeZah7Ux 9y ago
  ...and even introduce new issues: https://gankro.github.io/blah/only-in-rust/ https://gankro.github.io/blah/only-in-rust/
sillysaurus3 9y ago
OpenSSL's security is hard to beat. Constant code audits plus massive usage equals pretty secure software. The vulns in the blog post are denial of service bugs: memory exhaustion and an assertion crash. While these good to fix, they have little impact on security. You're much more likely to introduce hundreds of bugs attempting to port it to Rust than just maintaining OpenSSL's C code. Of course, you could try porting the codebase line-by-line to Rust. It'd certainly be an interesting challenge. But once you're done, you'll need to convince everybody to abandon a hardened, audited codebase for an untested, unaudited codebase written in an unfamiliar language, with a nascent open source ecosystem (mailing lists, CVE processes, etc).
- willvarfar 9y ago
  Eh hmm OpenSSL is infamously bad at security? There have been numerous critical bugs, and numerous criticism of its codebase, and numerous rewrites and migrations away from it! This is why the wikipedia page for OpenSSL https://en.wikipedia.org/wiki/OpenSSL https://en.wikipedia.org/wiki/OpenSSL lists notable vulnerabilities and even a list of forks away from it!
  - sillysaurus3 9y ago
    Well, yes. And now those bugs are fixed. Meanwhile, it's one of the most popular security libraries on the planet. The fact that everybody uses it means you're unlikely to be burned by any given vulnerability since every vulnerability impacts a huge number of people. From a security perspective, the worst situation to be in is where you're using some obscure library that has a critical flaw that nobody notices because it's obscure. At that point, a reasonably competent pentester will make your app sing and dance, and you won't know until too late. If you stick with OpenSSL, you leverage the massive investment of resources being poured into it.
    - deleted 9y ago
      [deleted]
    - omginternets 9y ago
simias 9y ago
All of them. But the remaining question is: how many more would've been introduced by rewriting OpenSSL and OpenVPN in a safe language? I think in the long run it's probably a good idea to do it, once things have settled a bit and there's a clear "winner" in the safe language front. In the meantime it'll be hard to beat the ubiquity and compatibility of a C library like OpenSSL. OpenVPN on the other hand, as a standalone application, could probably be rewritten right now in Rust, Go or Malbolge if somebody cared enough to do it.
yuchi 9y ago
I expected to be downvoted («the burden») but before you do please keep in mind I’m honestly trying to understand if those issues were preventable by using a different language. Just a honest curious question.
pjmlp 9y ago
Using a more safer systems programming language like Modula-2 (1978), would prevent in regards to C: - Out-of-bonds array and string access - Implicit type conversions - Accessing null pointers - Using pointers for output parameters - Casting integers to invalid enumeration values - Incompatible casts between data types - Allocating less memory than actually required In Modula-2 anything that requires C like low level tricks requires the explicit use of the pseudo-module SYSTEM. But I can go further to 1961 and ESPOOL and NEWP, Algol dialects for Burroughs B5500 systems programming, which already supported the use of then known as UNSAFE attributes for such low level coding outside Algol strong typing. Although they would still allow for memory leaks or the error of freeing unallocated memory, but they would panic for the later, instead of the UB in C.
- amelius 9y ago
  What would the performance penalty be?
  - pjmlp 9y ago
    Depends on the compiler. What many younger generation seem to miss is that in the 80's C compilers were pretty lame, most junior Assembly programmers could easily out perform them. The current state of C compiler performance is the outcome of almost 40 years of research in compiler optimizations for C, not anything of the language itself. Also for those that prefer "Performance trumps correctness" way of thinking, some compilers offered ways to disable those checks. But for anyone that thinks "Performance trumps correctness" is worthwhile, I advise to read C.A.R Hoare Turing award speech about the responsibility of software engineers, Algol use by the industry and law, done in 1981.
verytrivial 9y ago
.. Or in a language designed for proof of correctness? See e.g. https://mitls.org/ https://mitls.org/ -- I think this is very important work. Imagine only dealing with bugs in the spec? Maybe one day, when all the hearts are finally bled, something like this will become the default unless and until you have a proven^1 unmet performance requirement, and only then after you've spoken to your lawyers. 1. Pun intended.

by yuchi 9y ago

alltakendamned 9y ago

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

19218391 9y ago

We can answer that question when (if?) people actually start writing programs in Rust instead of speculating.

willvarfar 9y ago

Many of these bugs are specific to memory-unsafe languages. Writing in a memory-safe language would prevent many of these vulnerabilities. It would not stop all vulnerabilities.

eeZah7Ux 9y ago
...and even introduce new issues: https://gankro.github.io/blah/only-in-rust/ https://gankro.github.io/blah/only-in-rust/

sillysaurus3 9y ago

OpenSSL's security is hard to beat. Constant code audits plus massive usage equals pretty secure software. The vulns in the blog post are denial of service bugs: memory exhaustion and an assertion crash. While these good to fix, they have little impact on security. You're much more likely to introduce hundreds of bugs attempting to port it to Rust than just maintaining OpenSSL's C code. Of course, you could try porting the codebase line-by-line to Rust. It'd certainly be an interesting challenge. But once you're done, you'll need to convince everybody to abandon a hardened, audited codebase for an untested, unaudited codebase written in an unfamiliar language, with a nascent open source ecosystem (mailing lists, CVE processes, etc).

willvarfar 9y ago
Eh hmm OpenSSL is infamously bad at security? There have been numerous critical bugs, and numerous criticism of its codebase, and numerous rewrites and migrations away from it! This is why the wikipedia page for OpenSSL https://en.wikipedia.org/wiki/OpenSSL https://en.wikipedia.org/wiki/OpenSSL lists notable vulnerabilities and even a list of forks away from it!
- sillysaurus3 9y ago
  Well, yes. And now those bugs are fixed. Meanwhile, it's one of the most popular security libraries on the planet. The fact that everybody uses it means you're unlikely to be burned by any given vulnerability since every vulnerability impacts a huge number of people. From a security perspective, the worst situation to be in is where you're using some obscure library that has a critical flaw that nobody notices because it's obscure. At that point, a reasonably competent pentester will make your app sing and dance, and you won't know until too late. If you stick with OpenSSL, you leverage the massive investment of resources being poured into it.
  - deleted 9y ago
    [deleted]
  - omginternets 9y ago

simias 9y ago

All of them. But the remaining question is: how many more would've been introduced by rewriting OpenSSL and OpenVPN in a safe language? I think in the long run it's probably a good idea to do it, once things have settled a bit and there's a clear "winner" in the safe language front. In the meantime it'll be hard to beat the ubiquity and compatibility of a C library like OpenSSL. OpenVPN on the other hand, as a standalone application, could probably be rewritten right now in Rust, Go or Malbolge if somebody cared enough to do it.

yuchi 9y ago

I expected to be downvoted («the burden») but before you do please keep in mind I’m honestly trying to understand if those issues were preventable by using a different language. Just a honest curious question.

pjmlp 9y ago

Using a more safer systems programming language like Modula-2 (1978), would prevent in regards to C: - Out-of-bonds array and string access - Implicit type conversions - Accessing null pointers - Using pointers for output parameters - Casting integers to invalid enumeration values - Incompatible casts between data types - Allocating less memory than actually required In Modula-2 anything that requires C like low level tricks requires the explicit use of the pseudo-module SYSTEM. But I can go further to 1961 and ESPOOL and NEWP, Algol dialects for Burroughs B5500 systems programming, which already supported the use of then known as UNSAFE attributes for such low level coding outside Algol strong typing. Although they would still allow for memory leaks or the error of freeing unallocated memory, but they would panic for the later, instead of the UB in C.

amelius 9y ago
What would the performance penalty be?
- pjmlp 9y ago
  Depends on the compiler. What many younger generation seem to miss is that in the 80's C compilers were pretty lame, most junior Assembly programmers could easily out perform them. The current state of C compiler performance is the outcome of almost 40 years of research in compiler optimizations for C, not anything of the language itself. Also for those that prefer "Performance trumps correctness" way of thinking, some compilers offered ways to disable those checks. But for anyone that thinks "Performance trumps correctness" is worthwhile, I advise to read C.A.R Hoare Turing award speech about the responsibility of software engineers, Algol use by the industry and law, done in 1981.

verytrivial 9y ago

.. Or in a language designed for proof of correctness? See e.g. https://mitls.org/ https://mitls.org/ -- I think this is very important work. Imagine only dealing with bugs in the spec? Maybe one day, when all the hearts are finally bled, something like this will become the default unless and until you have a proven^1 unmet performance requirement, and only then after you've spoken to your lawyers. 1. Pun intended.