Georgi Guninski wrote: > Brendan,
No need to update a closed bug, especially one in the JavaScript Engine component, given your statements below. I'm not going to update that bug any more, although "last word" arguably should go to the people working on the module the bug was assigned against, don't you think? > I have spent quite a time analyzing logs of czech (a tool quite > similar to flawfinder). From personal experience I can say that the > "statical quality" of the JavaScript engine is very good so your > bashing of the false positives is understandable, but totally bashing > the use of such tools for other modules is wrong IMHO. I'm not bashing "such tools", because I haven't had a chance to evaluate czech. If it's better, maybe it is worth using. I do not think flawfinder is worth using, and I've said so clearly. But even better than czech, I bet, would be a tool based on gcc (gcc can be made to dump various intermediate forms, including abstract syntax trees). And we know, as roc and I have pointed out, even with bugs filed earlier this year that rotted, that you cannot "cry wolf" with noisy results and get good response the next time. > The fact is with the help of source analysis I have found an > expploitable bug in Mailnews and another exploitable one which was > hopefully #ifdef'ed. > In some cases with sprintf (and such) and pointer arithmetic I was > unable to tell whether the warning is exploitable or a false positive > - a person who is familiar with the source can tell and better yet use > the safe function having in mind lengths. What is that bug #, please? > As someone already pointed these warning though false positive, may > have some educational effect on some developers - I suggest always use > strncpy instead of strcpy That doesn't make sense in all cases. strncpy NUL-pads, and may not NUL-terminate at the limit. Pointers are hard, thought is required when dealing with them, auditing (starting with code review, which we do more than other projects, open source and commercial) is good because we all make mistakes. But if we have programmers who too often can't be trusted to use strcpy well, we have worse problems than can be solved by using strncpy, or by putting up big posters around all the untrustworthy programmers saying "USE STRNCPY NOT STRCPY" ;-). Such programmers should perhaps stop using C and C++ (JS has no pointers to mess up), or else stop working on the project. > - the overhead is minimal. > Also the following does not work - some one checks the source and in > the same time some people continue to write insecure code. > I may be wrong, but practice shows that the more warnings tools give > about a product, the more security bugs are discovered - good examples > about this are qmail and apache. I have seen no convincing data or arguments that injecting >90% noise, a la these flawfinder bugs, does any good. Can you provide some URLs or something for the qmail and apache cases? What tool(s) did they use? > I also disagree that buying an expensive auditing tool is a good solution. I actually proposed we develop a gcc-based one, and save some money. > Such an expensive tool may somewhat decrease the number of false > positives, It would dramatically reduce the number of false positives, for the JS flawfinder bug by something close to 100%. > but it can't brove bugness of bugfreeness - this is a human decision > still - there was a quote from Dejkstra IIRC: > "The testing for bugs can prove their presence, but not their absence" > or something like this. Of course. No one is disputing that, or claiming otherwise. RIP Dijkstra. I want to say again that security is not a cost-free good, and any tool is not better than no tool. If it were the case that we'd pay nearly any price for the next marginal increment of security through code inspection, our economics would be badly broken. And again, people don't like the boy who cried wolf, and will stop listening. So it is incumbent on we who care about security to use the best tools, and to make our bugs count. /be
