Security Errors in Code, Part 1

A couple of organizations, CWE and SANS (see their websites for a description of what the acronyms mean and what they do), have published a list of the "Top 25 Most Dangerous Programming Errors". This list enumerates common security problems in commercial code. See the list either here or here.

Some of the errors most programmers have heard of, even if some might not know exactly what they are. For example, "SQL Injection" and "Cross-site scripting" are well-known among some programmers because this is part of what they deal with everyday. Other programmers have not done any database or web site programming so might not fully understand these terms yet. Others are well-known, such as "Buffer overflow" and "Hardcoded passwords".

I was glad to see "Use of a Broken or Risky Cryptographic Algorithm", one of my Crypto Blunders (see this previous blog post). Another was "Use of Insufficiently Random Values". That has been one of my favorite topics for years. Back when I was the one who selected speakers for the Developers Track at the RSA Conference, I always made sure there was a talk on random number generation (Bob Baldwin's talk on hardware random number generation was probably the best conference talk I have ever seen in my life, at any conference, even better than Ron Rivest's talk on RC5).

In my opinion, many of the mistakes (not necessarily all) are caused by lazy programming. Let me give you an example of lazy programming.

In the C language, you allocate memory. This is usually a malloc or calloc or similar call. I have seen code that does not free the memory (memory leak). I have heard programmers say things like, "So what, I forgot to call the free. It doesn't really matter, once the process completes the Operating System will figure out that the memory is no longer used." By the way, is that true? Do modern systems have the ability to garbage collect? But even if that is true, it's lazy programming. Another thing I see is memory allocation and no check to see if it was successful or not. The excuse? "On modern computers, there's so much memory, no one ever runs out of memory." This is lazy programming.

And the thing about lazy programming is that if you're lazy in one place, you're lazy in other places. If you're lazy with memory allocation, you're probably lazy with "Improper Input Validation" and "Race Conditions".

For example, when you write an API, a function your customer can call might include 5 or 6 input variables. Do you check all of them to make sure they're valid? Do you have a way to know whether an input value is valid? Do you assume no one calling the function will make a mistake? The lazy programmer will simply write the function to work no matter what the input. That's lazy and it leads to the "Improper Input Validation" error. Anyone who is lazy with input validation is probably lazy with "Execution with Unnecessary Privileges".

Another way to put it is this, if you see code that does a bad job of input validation, but that error somehow does not cause a problem, some other error you don't see right now probably will cause a problem.

In part 2 I'll talk about how to avoid lazy code.