me, 2.0: more thoughts on google code search

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 Lexical 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 @ 10:34pm | previous Saturday, Oct 07, 2006 @ 03:38pm | archives

Last modified: Saturday, Oct 07, 2006 @ 10:05pm

Your Ad Here