Re: Static Analysis part 5

[Adam Shostack <adam () homeport org>]

Untainting is difficult because it's impossible.  The problems needs
to be stated differently to be solvable.  Validating data for input
into certain functions, or families of functions may be a more
interesting statement of the problem.

Adam

On Tue, Jul 28, 2009 at 05:40:23AM +0200, Halvar Flake wrote:
| Tainting / untainting is generally a difficult topic.
| 
| - If I calculate the length of a tainted string, is the result tainted ?
| - If I check some boundaries on this string, is the result untainted ?
| - What if the boundaries I checked for are wrong ?
| 
| Can of worms, difficult to solve.
| 
| Cheers,
| Halvar
| 
| dave wrote:
| > 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.
| _______________________________________________
| 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

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave