Ben Laurie a écrit :
On Fri, Apr 20, 2012 at 4:53 PM, Jean-Marc Desperrier<jmd...@free.fr>wrote:
It's a bit surprising if none of those tools could identify the badness of
the code involved in the just published memory corruption vulnerability.
Every now and then I look at trying to eliminate the possibility of this
kind of bug. Its really hard. I'd be interested if Clang could be persuaded
to spot the bug ... even more interested if it could find conversion bugs
generically.
At least, it's possible to use the AST to get a list of all cast, and
then consider ways of calculating which ones are suspicious.
I think it would be really interesting to understand *why* this wasn't
seen earlier, and check all the rest of the code for potentially similar
problem. Or similar case of assuming that "doing this is not very clean but
won't hurt us" instead of cleaning the code to do things properly.
The core problem is that the language doesn't do things properly :-)
But seriously, this is an important problem that crops up all the time, but
is hard to deal with. I've long suspected that a combination of static
analysis, good idioms and annotation could go a long way towards making
things better, but haven't really had time/energy to do more than speculate
There's an interesting, and little known, tool called sixgill (
http://sixgill.org/ ) that can be used to add annotations to C code.
It would be interesting to check what it could do here.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
