C is a tadpole in the ocean of easily preventable bugs.
I'm not sure I get your analogy.
Besides, Real Programmers™ eat mutable state and NULL for breakfast.
source: http://maxedv.com/wp-content/uploads/2011/12/Sourcefire-25-Y...
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
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.
C++ comes to mind for writing browser engines, but those have their fair share (if not more) of security issues as well.
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.
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.
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.