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 _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________
