Interesting tidbit in iDefense Security Advisory 06.26.07

[jms at bughunter.ca (J. M. Seitz)]

Hey all,

> 1) the original author of the defect thought that s/he was 
> doing things correctly in using strncpy (vs. strcpy).
> 2) the original author had apparently been doing static 
> source analysis using David Wheeler's Flawfinder tool, as we 
> can tell from the comments.

This is humorous, suppose they put it there intentionally and created the
flawfinder tag so that bughunters wouldn't see it doing a quick code scan :)
Conspiracy theory++! But on the other hand, if you can make big bucks
selling 0-days, and can write code, why wouldn't you try to sneak a few into
an open source app?

> Mind you, the overrun can only be exploited when specific 
> characters are used as input to the loop in the code.  Thus, 
> I'm inclined to think that this is an interesting example of 
> a bug that would have been extraordinarily difficult to find 
> using black box testing, even fuzzing.  The iDefense team 
> doesn't say how the (anonymous) person who reported it found 
> it, but I for one would be really curious to hear that story.

<sigh>I disagree, and do we include reverse engineering as black-box
testing? For example, maybe straight up RFC-style fuzzer wouldn't have hit
this one immediately, but there is the possibility that it could have
eventually found that code path, even a dumb fuzzer *could* have. Now let's
take something like Demott's EFS system which uses code-coverage and a
genetic algorithm to hammer further and further into the code. As it would
have hit this basic block of assembly, it may have found that the necessary
characters to continue through this code path had to be mutated or included
in a recombination for the next generation (it's fitness score would be
higher),it's not unreasonable....I have seen it do it myself! 

Now if a RE guy would have looked at this (and some of us prefer
disassembled binaries over C-source), its VERY plausible that they would
have found that path, and found the way to exploit it. Take a look at my
blog posting on
http://www.openrce.org/blog/view/775/Tracing_Naughty_Functions where I drop
some subtle hints on how to quickly find these dangerous functions, and
begin determining the best path towards them. Definitely not a new
approach...

This is a perfect example of how a source code analysis tool failed, because
you let a developer tell it to NOT scan it. :) I wonder if there are flags
like that in Fortify?

JS