"Jeff Williams" <[EMAIL PROTECTED]> wrote:
> I think there's a lot more that static analysis can do than what you're
> describing. They're not (necessarily) just fancy pattern matchers.
Jeff, you raise a important point. Getting good value out of static
analysis requires a second component in addition to a fancy pattern
matcher. You also need a good set of fancy patterns (aka rules)
to match against.
Understand that when I say ³fancy pattern², I don¹t mean ³regular
expression². More formally, I mean "program property". Taint
propagation, state transitions, feasible control flow paths,
alias analysis, etc. are all important if you¹d like to build
a tool, but if you¹re contemplating how to best apply a tool,
all of your interaction will be of the form
³Show me places in the program where property X holds²
and the goal of the tool is to match the code against the property
you've specified. For a good initial user experience, a tool
needs to come with a well-constructed default set of rules. For
aiding in program understanding, it needs to allow you to easily
add new rules of your own construction.
The number of false alarms you get from a good static analysis
tool is directly related to how aggressive the tool is in finding
constructs that might be what you're looking for. As an example, I'll
use a question you posed: "are there any paths around the
encryption?" If you're going to bet your life that there aren't
any such paths, then you'd like the tool to make conservative
assumptions and allow you to manually review anything that might
possibly match the pattern you've specified. If you only have a
passing interest in the property, then you'd prefer the tool weed
out paths that, while not impossible, are not likely to be of
interest. Maybe some code will help illustrate my point:
if (b) {
panic();
else {
buf = encrypt(buf);
}
return buf;
Would you like to be warned that buf may be returned unencrypted?
This code fragment guarantees that either buf is encrypted or
panic() is called. But usually control doesn't return from a
function named panic(). The problem is, that's not universally
true; sometimes panic() just sets a flag and the system reboot
happens shortly thereafter.
Whether or not you want to see this path depends on how important
it really is to you that encryption is absolutely never bypassed.
Your tolerance for noise is dictated by the level of assurance
you require.
Brian
_______________________________________________
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
