me, 2.0: jose nazario
beauty and the street
more thoughts on google code search
years ago i gave a talk about static analysis using various tools entitled
analysis in source code scanning. at the time i had written a piece for
Linux Journal about static analyzers -- specifically flawfinder, its4, and
rats -- and actually startd writing my own. after a couple of years of
languishing, i officially ditched the project. the code is embarassing,
to be honest, but i have to say i did find real bugs in OpenBSD, including
one or two that could lead to remote root.
anyhow, back to google codesearch.
i spent a lot of time in the past couple of days messing around finding bugs,
and in many cases they are real bugs, but in many cases they aren't. like
i said earlier, about 5% are security-related bugs. if you
look at the results of a typical search, you'll see about 40-50% bugs vs non-bugs,
depending on your search criteria. it takes a good programmer to really be able to
discriminate and understand the impact of many of them (i'm not quite that good
after writing poor quality code for years). it takes training and discipline
to see the security implications. maybe you want to do that, it is, after all,
a growth industry. if so, you should look at some of these references to get started
in understanding code.
learn C very well:
read Advanced Programming in the UNIX(R) Environment (2nd Edition) (Addison-Wesley Professional Computing Series) if you code in UNIX, or even if you just use a lot of ANSI C.
the old standard The Practice of Programming is just as important for anyone coding in any language.
you'll spend a lot of time at MSDN and the
various informational pages on the API in Windows if you do any Win32 analysis or coding. there
are thousands of calls with various semantics and quirks, you'll get to know them.
once you learn C well, you should look at these:
Writing Secure Code, Second Edition covers a lot of common pitfalls in code, both Windows and generic C.
Secure Programming Cookbook for C and C++ covers how to do it right.
i haven't looked at this one, Hunting Security Bugs, but it looks like it could be worthwhile to examine.
one last tip: when you see a bug hit a security list or get fixed in CVS or SVN, look it over
and see the pattern there. then write a regular expression for it. then go hit google codesearch
with it (ie typos in conditionals). voila, you just found yourself
some bug fodder.
next Saturday, Oct 07, 2006 @ 09:34pm |
previous Saturday, Oct 07, 2006 @ 02:38pm
Last modified: Saturday, Oct 07, 2006 @ 09:05pm
copyright © 2002-2005 jose nazario, all rights reserved.