Vulnerability spotting the DHS way
Connecting state and local government leaders
When the Department of Homeland Security's Open Source Code Hardening Project scans open source applications for vulnerabilities, what kinds of problems does it look for?
When we spoke with David Maxwell, who is the open source strategist for Coverity, the company executing the scans, he mentioned that the company scans for 12 different types of vulnerabilities. He subsequently sent along a list of the 12.
They're pretty interesting in their own right (Who knew so many things could go wrong when programming?), so we decided to post them in their entirety (NOTE: The descriptions below are Coverity's, not ours):
*Deadcode: Unreachable portions of code which usually indicate a flaw in the program logic. Note, this does not refer to code that is commented out, only code which is included in the program, but will never execute.
*Forward Null: A pointer variable which is known to have a value of NULL is dereferenced on the indicated line, which will cause the program to crash.
*Negative Returns: A function which can return a negative value is called, and the result is used where negative values will cause unpredictable or problematic behavior. One example is using the value to index an array variable, thereby walking off the start of the array into other memory.
*Null Returns: A function which can return NULL is called, and the result is used where NULL values will cause unpredictable or problematic behavior.
*Dynamic Overrun: A piece of dynamically allocated memory is written to, and its size is not respected.
*Static Overrun: A piece of statically allocated memory is written to, and its size is not respected.
*Resource Leak: Memory, or other system resources are allocated by the program, and not released.
*Reverse Null: A pointer variable which has been used, is subsequently tested for having a NULL value. This test indicates that the programmer thinks the value could be NULL at this point, except the test comes too late, since a NULL value, if used, would already have caused a crash. This is often the result of multiple programmers making changes to the same section of code.
*Reverse Negative: A variable is checked for having a negative value, where a negative value would already have violated safe usage of the value, such as use in an array index.
*Sizecheck: A pointer is cast to a datatype, and assigned to dynamically allocated memory which is not large enough to hold that data type. Writing to that type/address pair will overwrite other memory as well.
*Uninit: A variable is used before it has been initialized. This will result in unpredictable behavior, depending on what happens to be in the memory from before.
*Use After Free: Memory is allocated, then freed, but a pointer to it is retained. That pointer is then used. This causes silent memory corruption, which leads to very difficult to debug errors, as the program does not crash, but begins to execute incorrectly. This can lead to further data corruption.
NEXT STORY: Open source apps get DHS fix-up