Dailydave mailing list archives
Re: Static Analysis part 5
From: nnp <version5 () gmail com>
Date: Mon, 27 Jul 2009 23:06:35 +0100
Err...so they had a PHP specific source code analysis tool *without* support for default language structures (or at least, without useful support)? I'm assuming they parse the source into some sort of AST and then do their analysis on that, so the only justification I could see would be that their AST format didn't have support for something like a dictionary, which seems pretty odd. On the topic of automated analysis, check this out http://klee.llvm.org/. I only just found out it was open source (via the RE reddit [1]). Their paper is linked from that site and it's pretty good. They take the "solve-massive-equation-to-understand-data-constraints" style approach. [1] http://www.reddit.com/r/ReverseEngineering/comments/94xxg/klee_unassisted_and_automatic_generation_of/ On Mon, Jul 27, 2009 at 9:05 PM, dave<dave () immunityinc com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If you haven't read it yet (and you like to read things), this is worth reading: http://samate.nist.gov/docs/NIST_Special_Publication_500-279.pdf There's a lot of meta-questions here, like "What sorts of vulnerabilities can automated techniques really find?" Scalability is hard too. "Can we look at 4500 buffer overflow bugs to triage them?" the paper asks. Many people don't see why it's hard to do static analysis automatically, which I think is always worth thinking about. For example, recently I was at a conference looking at a vendor's implementation of the traditional "data-flow-then-alert-on-tainted-data" algorithm. (As opposed to the "solve-massive-equation-to-understand-data-constraints" style).[1] We were looking at PHP, and I couldn't for the life of me figure out why the system was alerting on a particular code path. I will reproduce it here in python, since my PHP is weak. d={} //DEFINE dictionary d["HI"]=TAINTED_USER_DATA; //insert some tainted data to it, whole dictionary is tainted now. #stuff goes here that is not relevant (we think) os.system(d["BYE"]) //ALERT! It turns out the analysis tool tainted the whole dictionary if any tainted data was inserted into it, because all the other solutions for that are...insanely complex. Maybe one of the static analysis guru's on the list knows of the best way to solve that particular problem and wants to share. (Or maybe there isn't a solution for that problem, and no one wants to point that out either? :>) - -dave [1] Scanner Pong's rules are as follows. You must use the test programs the vendor brings with them to demonstrate their static analysis tool. For each vulnerability you look at you lose 1 point. For each vulnerability you look at that you show to be a false positive, you get 2 points. For each vulnerability you look at where the tool has missed an interesting vulnerability within 30 lines of code you get 5 points. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkpuCJUACgkQtehAhL0gherfQACfavVrp85RJrpJXv4apIip/UwL MMcAnjjBnCA6Zzv+uGYtMrABuoFTc8QI =1QFS -----END PGP SIGNATURE----- _______________________________________________ Dailydave mailing list Dailydave () lists immunitysec com http://lists.immunitysec.com/mailman/listinfo/dailydave
_______________________________________________ Dailydave mailing list Dailydave () lists immunitysec com http://lists.immunitysec.com/mailman/listinfo/dailydave
Current thread:
- Static Analysis part 5 dave (Jul 27)
- Re: Static Analysis part 5 nnp (Jul 27)
- Re: Static Analysis part 5 Halvar Flake (Jul 28)
- Re: Static Analysis part 5 Rafal M. Los (Jul 28)
- Re: Static Analysis part 5 Andy Steingruebl (Jul 29)
- Re: Static Analysis part 5 Adam Shostack (Jul 29)
- Re: Static Analysis part 5 Rafal M. Los (Jul 28)