SecureProgramming.com

We've now been slashdotted. After lowering the idle connection timeout from hours to minutes, we're doing fine (famous last words). The comments are full of "C sucks" rants. I thought I'd summarize a few of my thoughts on this issue.

Yes, C and C++ have special "features" that make adding security problems easy, even for a fairly informed and careful developer. That's impossible to deny, though the book and this site do cover mitigation strategies that can make a big difference. However, people are miscalculating by assuming that just switching to another programming language is going to make a big difference. It can make a difference, but not as big of one as people are expecting. Defensive practices can offset the problem.

We've done a few case studies on number of defects per line of code when performing code audits. C and C++ programs have averaged 4-5 security-critical defects per thousand lines of code. Java programs still average 1-2 security-critical defect per thousand lines.

There are plenty of problems that programming languages themselves haven't fixed. And, honestly, most of those problems should be fixed at the API level. For example, it's stupid that neither OpenSSL or Microsoft supports full certificate validation by default. The programmer has to know what security checks to perform and write the code to do them manually, instead of getting "secure by default" behavior. As a result, most applications that use SSL/TLS are vulnerable to man-in-the-middle attacks. Sure, this is a problem in some common C-based libraries, but it's just as common in the SSL implementations for other languages. Other problems such as cross-site-scripting and SQL injection affect other languages far more commonly than C and C++, since those languages aren't often used in web apps.

In C and C++, the common security problems are relatively easy to understand, and if you are diligent and take the right preventative measures, they're not so hard to avoid. In other languages, the easy/obvious problems don't apply, but as people use high-level primitives to build complex applications, they tend to introduce complex security problems (race conditions in servlets can be quite tough to identify, and still have security implications).

In short, you aren't likely to accidentally end up with a "secure" program, no matter which programming language you use. We're currently working on a Java Secure Programming Cookbook, and are assembling a team for a PHP Secure Programming Cookbook. There's plenty of material for both books, without question. Expect both to be at least 400 pages, without even covering all of the low-level cryptographic stuff we cover in the C/C++ version.

At the end of the day, if you're going to be diligent, then security can be reduced to a fairly minor consideration in programming language choice.

One final note: C++ is often perceived as being more secure than C, because it has an abstracted string type. That's not really true, even ignoring the few cases where you can still overflow using C++ strings. Basically, heap overflows are far more dangerous in C++, because lots of function pointers tend to be stored on the heap, due to the way classes and exception handling is implemented (the GOT is stored on the heap even in C programs, but C++ programs tend to have function pointers coming out of the wazoo). If an attacker can overwrite one of those pointers, then it's often possible that he can replace it with a pointer to some sort of malicious payload.