Andrew Arnott wrote: > Nate, > How do you ascertain that a given library is vulnerable? Just by code > inspection and assume you understand the implications of the platform and > surrounding code, or do you successfully exploit it to be certain?
There's a difference between "has a timing leak bug" and "is exploitable". The former can be found by inspection and verified by simple profiling. That's how we found and reported bugs in particular packages. "Vulnerable to a timing attack" depends on a number of factors including attacker vantage point from target, implementation language, number of samples collected, network packet loss and jitter, target CPU power management, and competing processes on target. We have been isolating each of those factors and seeing how much they affect visibility of timing flaws. But unless you test a particular installation of library X from a particular vantage point with a specific number of samples, you cannot say for sure whether it is or isn't vulnerable. We've also done this testing for a limited number of configurations and have successfully differentiated values in some configurations. Other configurations are not exploitable within a reasonable amount of time. However, as a general software provider, you really can't be sure of your users' configurations, attacker vantage points, or target value where an attacker would be willing to wait days (weeks?) for results. Our talk will give some hard numbers where you can get a feel for exploitability based on the above variables. But I wouldn't use those results to avoid fixing a flaw because you can't be sure about a particular user's configuration. -- Nate Lawson Root Labs :: www.rootlabs.com +1 (510) 595-9505 Solving embedded security, kernel and crypto challenges _______________________________________________ security mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-security
