Re: auditing

[Jose Nazario <jose () monkey org>]

some advice ...

look for tools to generate callgraphs from dynamic (runtime) analysis and
static (run them over the compiler binary or the source code) analysis.
graphing those relationships can be useful. one example:

        http://monkey.org/~jose/graphing/syscalls/

look for tools to do control flow analysis, again static or dynamic.

build an annotated C library that you can use to preload and watch
execution while the program runs (assuming you only have a binary
available on a UNIX platform, i would't know how to do this on windows).
invoke some of the old software cracker tricks ...

look for tools to do known hole analysis, they can be as simple as grep or
as complex as you can imagine ... this page has a few links to some tools
at teh bottom which may be useful:

        http://www.dwheeler.com/flawfinder/

(several easy to use tools of varying sophistication are listed in these):

        http://www.linuxjournal.com//article.php?sid=5673
        http://www.ida.liu.se/~johwi/research_publications/paper_nordsec2002_john_wilander.pdf
        http://www.ida.liu.se/~johwi/research_publications/paper_ndss2003_john_wilander.pdf
        http://www.cs.berkeley.edu/~pbwell/papers/saswifi.pdf

etc etc etc ... frankly the hard part if identifying the right terms to
use. once you do that you're all set.

big kudos to david wheeler for maintaining a nice repository of links
(along with flawfinder, a pretty decent first pass tool). even more links
to even more tools and techniques (scan the whole page):

        http://osq.cs.berkeley.edu/


remember. automated tools will only catch the things you already knew
about. they help because they don't get tired, see cross eyed (typically),
and can be fast. they fail because they're easy to confuse, they only work
on what you know, and get prohibitively difficult to write and use for
large forms of analysis. it's a hot topic, has attracted some of the best
and brightest, and is a fertile area for all levels of research. if you're
serious about studying it, learn compiler internals as a means to learn
model building, study the language specification (spot the ambiguities is
a fun game to play) and start hacking tools.

dilligance, dilligance, dilligance.

________
jose nazario, ph.d.                     [EMAIL PROTECTED]
http://monkey.org/~jose/                http://infosecdaily.net/