coldtobi's blog

• Main
• Archives
• Albums
• Links
• Admin

• Blog and Website [88]
• DSL RAM [2]
• Electronics and Atmel AVR [10]
• fanctrl [3]
• General [7]
• German [1]
• La Fonera [28]
• Lifetype [17]
• Linux / Debian [30]
• Monetizing A Blog [8]
• my 2 cents [19]
• Netzfunde [16]
• Nice Links [1]
• solarpowerlog [1]
• Thecus N2100 [14]
• Tips and Tricks [17]

• Nice Links #1 -- How hardrives works and how they do recovery
• Squirrelmail and lighttpd -- An Installation Guide --
• Link Crosscompiling
• git cheat sheet
• A Happy new Year 2010!
• nfs: read-only-filesystem
• online ebook about autotools

• RSS 0.90
• RSS 1.0
• RSS 2.0
• Atom

• Privacy Policy
• Disclosure Policy

Not all "defects" are security bugs

Today's slashdot is linking to an interesting article on Information Week, the analyzed took the results of an DHS (Department of Homeland Security) Scan about some used FOSS-Software.

Its especially interesting for me, as they used Coverity, a static code analyzing tool, which I came across not long ago during the Embedded World last year A like system is used in our company for automotive embedded software analyzises, so I know how these software works and how the reports looks like. .

However, reading through the aritcle on Information Week, gave me the hint, that not everthing written by an journalist needs to be correct. The impression arose especially about the given facts: 

 one security exposure for every 1,000 lines of code

As a full-heart coder, this  figure is very familiar to me, but in a slightly different context: A assumed bug rate for a very coder is  usually 1 bug in 1000 lines of code. And for sure not every one being exploitable.

But if your read Coverity's scan page, the always mention "defects". A defect is a bug. An not every bug is exploitable. 

On the other side, one should look what that Coverity et. al. are looking for: The analyze code for several aspects: Data types, array boundaries, language ambiguousness and other like things things. So the term "defects" is basically "coding errors". This says about absolutely nothing about if these are exploitable.

An example:

The lines  

 unsigned int tmp; int tmp2;  tmp+= tmp2; 

would produce a "defect" as the types are not matching, because of the missing cast because of not matching data types. However, this will usually not be a problem, as long tmp is not used for pointer calculations (incl. dereferencing arrays

   
So the author is quite trying to hide the information: FOSS is doing very well, as the defect-rate is very low among most of the analyzed projects. And if he complains , that there a many bugs out there, that are not fixed, he should keep in mind, that among the defects might be some, that are really harmless, and the danger of changing working code must always be considered. Yes, you can introduce bugs by "beautifying", and lines like the above tends to a cast-mania. which makes code ugly and hard to read: However, the example above does not require this, but if you have to use different "typedefs" in a line, you have some casts to apply.