| This is a perfect example of how a source code analysis tool failed,
| because you let a developer tell it to NOT scan it. :) I wonder if
| there are flags like that in Fortify?
There are flags like that in *every* source code scanner I know of. The
state of the art is just not at a point where you don't need a way to
turn off warnings for false positives. The way you do it can be more or
less sophisticated, but even the most sophisticated can be fooled by
misunderstandings - much less deliberate lies - by the developer. For
example, Coverity has a nice feature that lets you provide it with
information about the characteristics of functions to which the scanner
doesn't have access. Rather than define a whole little language for
defining such things, Coverity has you write a dummy function that
simply undertakes the actions it will need to know about. For example,
to tell Coverity that void f(char* p) will write to *p, you provide
the dummy function:
void f(char* p) { *p = 0; }
If you accidentally - or deliberately - provide:
void f(char* p) { *p; }
you've just told Coverity that f() dereferences p, but never writes
through it. Needless to say, and subsequent analysis will be flawed.
Binary analysis doesn't, in principle, suffer from the problem of not
having access to everything - though even it may have a problem with
system calls (and of course in practice there may be other
difficulties).
"Unavailable source/binary" is a very simple issue. There are all kinds
of things that are beyond the capabilities of current analysis engines -
and always will be, given the Turing-completeness of all languages
people actually use. To take a simple example: A properly-written
quicksort that, before scanning a subfile, sorts the first, middle, and
last element in place before using the middle element as the pivot, does
not need to do any array-bounds checking: The element values will make
it impossible to walk "out of" the subfile. This is trivial to prove,
but I doubt any scanner will notice. It will complain that you *might*
exceed the array bounds. You basically have two alternatives at this
point:
1. Re-write the code to make it amenable to analysis.
2. Somehow tell the analyzer to back off.
The theoretically-correct approach is (1) - but it may not be practical
in particular cases. For quicksort applied to a type with a fast
comparison operation, doing that can double the time spent in the inner
loop and kill performance. In many cases, the performance or other
impact is minor, but someone has to go off and restructure and retest
the code. How much such effort can be justified to deal with an
"impossible" situation, just because the analyzer is too stupid to
understand it? Paradoxically, doing this can also lead to difficulty in
later maintenance: Someone looking at the code will ask "why are we
testing for null here, the value can't possibly be null because of
XYZ..." You don't want to be wasting your time going down such
pointless paths every time you need to change the code. (Yes, comments
can help - but all too often they aren't read or updated.)
Finally, I've seen cases where adding a check to keep the analyzer happy
can encourage a later bug. Consider a function that as part of some
computation we can prove always produces a non-negative value. We take
the square root of this value without checking. The analyzer complains.
So even though it can't matter, we use take the absolute value before
taking the square root. All is well. Later, the definition of the
function is changed, and the first computation *may* produce a negative
value, which is then used in some other way. A quick check of the code
reveals that negative values "are already being handled", so no attempt
is made to update the code. Boom.
-- Jerry
_______________________________________________
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
_______________________________________________
