6 ms·

C is a tadpole in the ocean of easily preventable bugs.

tempodox 10y ago
And when it grows up, it becomes the toad that is C++? I'm not sure I get your analogy. Besides, Real Programmers™ eat mutable state and NULL for breakfast.
- bluejekyll 10y ago
  NULL is just macro for Cheerios...
lmm 10y ago
Then why do we see a major internet security bug that would be simply impossible in any other language every couple of months?
- JustSomeNobody 10y ago
  Because the vast amount of C code running the internet. That's all. Rewrite everything in <language> and you'd see just as many security vulnerabilities.
  - lmm 10y ago
    I very much doubt that. Buffer overflows simply wouldn't happen in most languages, and those are the majority of the vulnerabilities we see.
    - f2f 10y ago
      XSS (cross-site scripting) replaced buffer overflows as the most common vulnerability in 2005. source: http://maxedv.com/wp-content/uploads/2011/12/Sourcefire-25-Years-of-Vulnerabilities-Research-Report.pdf http://maxedv.com/wp-content/uploads/2011/12/Sourcefire-25-Y...
    - peterwwillis 10y ago
      That appears not to be the case. pwillis@windows:~/Downloads$ wget -q -O allitems.csv https://cve.mitre.org/data/downloads/allitems.csv pwillis@windows:~/Downloads$ ( for year in `seq 1999 2016` ; do TOTAL=`cat allitems.csv | grep -v RESERVED | grep "^CVE-$year" | wc -l`; BUFF=`cat allitems.csv | grep -v RESERVED | grep "^CVE-$year" | grep -i -e "buffer.*overflow\|overflow.*buffer" | wc -l`; PERCENT=`awk "BEGIN{print $BUFF/$TOTAL*100}" | cut -d. -f1`; echo "Year $year: $TOTAL CVEs, $BUFF buffer overflow related, $PERCENT% total" ; done ) Year 1999: 1573 CVEs, 307 buffer overflow related, 19% total Year 2000: 1237 CVEs, 250 buffer overflow related, 20% total Year 2001: 1540 CVEs, 278 buffer overflow related, 18% total Year 2002: 2370 CVEs, 481 buffer overflow related, 20% total Year 2003: 1519 CVEs, 346 buffer overflow related, 22% total Year 2004: 2670 CVEs, 470 buffer overflow related, 17% total Year 2005: 4686 CVEs, 519 buffer overflow related, 11% total Year 2006: 7047 CVEs, 612 buffer overflow related, 8% total Year 2007: 6510 CVEs, 868 buffer overflow related, 13% total Year 2008: 7034 CVEs, 619 buffer overflow related, 8% total Year 2009: 4888 CVEs, 589 buffer overflow related, 12% total Year 2010: 4954 CVEs, 419 buffer overflow related, 8% total Year 2011: 4441 CVEs, 428 buffer overflow related, 9% total Year 2012: 5219 CVEs, 399 buffer overflow related, 7% total Year 2013: 5731 CVEs, 382 buffer overflow related, 6% total Year 2014: 7494 CVEs, 326 buffer overflow related, 4% total Year 2015: 6526 CVEs, 357 buffer overflow related, 5% total Year 2016: 7180 CVEs, 471 buffer overflow related, 6% total According to this really shitty review of CVEs, buffer overflow is less than 10% (recently less than 6%) of tracked vulnerabilities. That's still a lot, of course.
      - lmm 10y ago
        Fair enough; I was thinking of the occasional "the whole internet is broken" CVEs we see a few times a year. My impression is that they're mostly C and mostly memory-safety, but that's a human subjective thing. The right thing would be to weight by severity and number of users impacted, and bundle all the memory-safety vulnerabilities together (i.e. buffer overflow, double free, use-after-free, aliasing violation). I'll add it to the big list of blog posts I want to write.
- krylon 10y ago
  Not saying that C is not to blame, but there seems to be relatively little code written in languages other than C that is as widely used. C++ comes to mind for writing browser engines, but those have their fair share (if not more) of security issues as well.
  - lmm 10y ago
    My sense is that most new line-of-business code these days is written in Java or C#. Which are still dated languages with serious flaws (e.g. goto fail would still be possible) but do at least address C's memory safety issues. I don't know why so much Internet infrastructure managed to miss that shift. Possibly a case of "ain't broke, don't fix it" - Apache, OpenSSL and what have you haven't changed that much since the early '00s and few people are motivated to write a replacement. Databases mostly existed since then, and newer datastores do tend to use better languages.
- sidlls 10y ago
  You need to compare bugs on a per-usage basis (e.g. lines of code, programs written, some other similar metric), not a raw total. You're comparing numerators, not ratios.
- peterwwillis 10y ago
  https://www.cvedetails.com/vulnerability-list/year-2016/month-12/December.html https://www.cvedetails.com/vulnerability-list/year-2016/mont... Note the types of vulnerabilities and the languages they use. DoS, File Inclusion, XSS, Exec Code, Dir Traversal, Priv Escalation, SQLI, Bypass, CSRF, Info leak, etc. Many of them (including ones in C) have nothing to do with memory protection. Those that do (null pointer deref, use-after-free, memory leak, buffer overflow, etc) are all trivially protected with small kernel patches that have been around for 17 years, and of course most of these vulns would become trivial with proper mandatory access control. But for reasons that completely escape me, nobody has adopted these basic techniques to prevent small bugs from becoming big holes. Now balance the common holes in C against all the other bugs in higher level languages with otherwise suitable memory protection, and consider that at least with C there are basic steps that prevent many of these from becoming problems, whereas with other languages you need a hodge-podge of different, more complicated countermeasures. C is actually easier to secure because its bugs are common and not difficult to catch by the kernel. Honestly, if people spent as much time developing new industry best practices for use of the language as they do complaining about it, this would be a non-issue. But C isn't trendy, so let's all crap on it and pretend it's the only issue so we can have fun reinventing classical bugs with new languages.
  - lmm 10y ago
    > consider that at least with C there are basic steps that prevent many of these from becoming problems, whereas with other languages you need a hodge-podge of different, more complicated countermeasures. C is actually easier to secure because its bugs are common and not difficult to catch by the kernel. I think this is completely wrong. In other languages you just don't have these problems in the first place because you are memory-safe by default. It's not like there's some point-buy system where all languages have to have the same number of opportunities for bugs and not having stupid memory safety bugs means you have more complex subtle bugs instead. You just eliminate a huge proportion of your bugs.
CalChris 10y ago
SEL4 is written in ... C.

And when it grows up, it becomes the toad that is C++? I'm not sure I get your analogy. Besides, Real Programmers™ eat mutable state and NULL for breakfast.

bluejekyll 10y ago
NULL is just macro for Cheerios...

lmm 10y ago

Then why do we see a major internet security bug that would be simply impossible in any other language every couple of months?

JustSomeNobody 10y ago
Because the vast amount of C code running the internet. That's all. Rewrite everything in <language> and you'd see just as many security vulnerabilities.
- lmm 10y ago
  I very much doubt that. Buffer overflows simply wouldn't happen in most languages, and those are the majority of the vulnerabilities we see.
  - f2f 10y ago
    XSS (cross-site scripting) replaced buffer overflows as the most common vulnerability in 2005. source: http://maxedv.com/wp-content/uploads/2011/12/Sourcefire-25-Years-of-Vulnerabilities-Research-Report.pdf http://maxedv.com/wp-content/uploads/2011/12/Sourcefire-25-Y...
  - peterwwillis 10y ago
    That appears not to be the case. pwillis@windows:~/Downloads$ wget -q -O allitems.csv https://cve.mitre.org/data/downloads/allitems.csv pwillis@windows:~/Downloads$ ( for year in `seq 1999 2016` ; do TOTAL=`cat allitems.csv | grep -v RESERVED | grep "^CVE-$year" | wc -l`; BUFF=`cat allitems.csv | grep -v RESERVED | grep "^CVE-$year" | grep -i -e "buffer.*overflow\|overflow.*buffer" | wc -l`; PERCENT=`awk "BEGIN{print $BUFF/$TOTAL*100}" | cut -d. -f1`; echo "Year $year: $TOTAL CVEs, $BUFF buffer overflow related, $PERCENT% total" ; done ) Year 1999: 1573 CVEs, 307 buffer overflow related, 19% total Year 2000: 1237 CVEs, 250 buffer overflow related, 20% total Year 2001: 1540 CVEs, 278 buffer overflow related, 18% total Year 2002: 2370 CVEs, 481 buffer overflow related, 20% total Year 2003: 1519 CVEs, 346 buffer overflow related, 22% total Year 2004: 2670 CVEs, 470 buffer overflow related, 17% total Year 2005: 4686 CVEs, 519 buffer overflow related, 11% total Year 2006: 7047 CVEs, 612 buffer overflow related, 8% total Year 2007: 6510 CVEs, 868 buffer overflow related, 13% total Year 2008: 7034 CVEs, 619 buffer overflow related, 8% total Year 2009: 4888 CVEs, 589 buffer overflow related, 12% total Year 2010: 4954 CVEs, 419 buffer overflow related, 8% total Year 2011: 4441 CVEs, 428 buffer overflow related, 9% total Year 2012: 5219 CVEs, 399 buffer overflow related, 7% total Year 2013: 5731 CVEs, 382 buffer overflow related, 6% total Year 2014: 7494 CVEs, 326 buffer overflow related, 4% total Year 2015: 6526 CVEs, 357 buffer overflow related, 5% total Year 2016: 7180 CVEs, 471 buffer overflow related, 6% total According to this really shitty review of CVEs, buffer overflow is less than 10% (recently less than 6%) of tracked vulnerabilities. That's still a lot, of course.
    - lmm 10y ago
      Fair enough; I was thinking of the occasional "the whole internet is broken" CVEs we see a few times a year. My impression is that they're mostly C and mostly memory-safety, but that's a human subjective thing. The right thing would be to weight by severity and number of users impacted, and bundle all the memory-safety vulnerabilities together (i.e. buffer overflow, double free, use-after-free, aliasing violation). I'll add it to the big list of blog posts I want to write.
krylon 10y ago
Not saying that C is not to blame, but there seems to be relatively little code written in languages other than C that is as widely used. C++ comes to mind for writing browser engines, but those have their fair share (if not more) of security issues as well.
- lmm 10y ago
  My sense is that most new line-of-business code these days is written in Java or C#. Which are still dated languages with serious flaws (e.g. goto fail would still be possible) but do at least address C's memory safety issues. I don't know why so much Internet infrastructure managed to miss that shift. Possibly a case of "ain't broke, don't fix it" - Apache, OpenSSL and what have you haven't changed that much since the early '00s and few people are motivated to write a replacement. Databases mostly existed since then, and newer datastores do tend to use better languages.
sidlls 10y ago
You need to compare bugs on a per-usage basis (e.g. lines of code, programs written, some other similar metric), not a raw total. You're comparing numerators, not ratios.
peterwwillis 10y ago
https://www.cvedetails.com/vulnerability-list/year-2016/month-12/December.html https://www.cvedetails.com/vulnerability-list/year-2016/mont... Note the types of vulnerabilities and the languages they use. DoS, File Inclusion, XSS, Exec Code, Dir Traversal, Priv Escalation, SQLI, Bypass, CSRF, Info leak, etc. Many of them (including ones in C) have nothing to do with memory protection. Those that do (null pointer deref, use-after-free, memory leak, buffer overflow, etc) are all trivially protected with small kernel patches that have been around for 17 years, and of course most of these vulns would become trivial with proper mandatory access control. But for reasons that completely escape me, nobody has adopted these basic techniques to prevent small bugs from becoming big holes. Now balance the common holes in C against all the other bugs in higher level languages with otherwise suitable memory protection, and consider that at least with C there are basic steps that prevent many of these from becoming problems, whereas with other languages you need a hodge-podge of different, more complicated countermeasures. C is actually easier to secure because its bugs are common and not difficult to catch by the kernel. Honestly, if people spent as much time developing new industry best practices for use of the language as they do complaining about it, this would be a non-issue. But C isn't trendy, so let's all crap on it and pretend it's the only issue so we can have fun reinventing classical bugs with new languages.
- lmm 10y ago
  > consider that at least with C there are basic steps that prevent many of these from becoming problems, whereas with other languages you need a hodge-podge of different, more complicated countermeasures. C is actually easier to secure because its bugs are common and not difficult to catch by the kernel. I think this is completely wrong. In other languages you just don't have these problems in the first place because you are memory-safe by default. It's not like there's some point-buy system where all languages have to have the same number of opportunities for bugs and not having stupid memory safety bugs means you have more complex subtle bugs instead. You just eliminate a huge proportion of your bugs.

CalChris 10y ago

SEL4 is written in ... C.