[cfe-dev] Static Analyzer Rocks Hard

[Török Edwin]

Ted Kremenek wrote:
>
> On Jun 23, 2008, at 9:05 AM, Török Edwin wrote:
>
>> Not handling allocation failures can lead to security holes if the
>> parameter to malloc
>> can be somehow controlled by an attacker.
>
> I'm inclined to believe that this is a slightly orthogonal issue,
> although your point is well-taken. The security bug comes from using
> an untrusted value as the size argument to malloc.  While checking for
> malloc failure might indirectly handle some of these issues, it
> doesn't really address the original security problem, as the untrusted
> data could be used to wreck havoc in other ways.
> The more complete way to catch these bugs (and potentially verify
> their absence) is to flag dangerous uses of untrusted data: using it
> as a size parameter to malloc, using it as an array index, and so on.
>
> My point here is that not checking for malloc failure is not
> inherently a security bug.

Agreed, it is not a security bug by itself, or as you explained, if
malloc can be made to return NULL there is a security bug elsewhere too.
However an application that cares about security should check the return
value of system/libc calls.

>
>> However in practice most allocations are unchecked leading to huge
>> number of warnings, so I think it would be best
>> to have an option to toggle checking for malloc failures.
>> Or classify them differently so you can filter the errors from the HTML
>> report:
>>    null dereference on allocation failure, uninitialized value on
>> allocation failure, ...
>
> I agree.  I think it all depends on the particular goals of the
> programmer for the application they are writing.
>
> The reality is that most code doesn't check to see if allocation
> fails.  In such cases, I don't believe that programmers are interested
> in seeing warnings from a tool that involve allocation failure.  When
> some warnings systematically become noise to the user, they really do
> compromise the value of the bug-finding tool.
>
> For those who want to be particularly vigilant about their code (at
> least as far as memory allocation failure is concerned), there
> certainly should be an option to either have the analyzer perform more
> aggressive checking (i.e., assume malloc can fail) or have the
> interface for inspecting bugs allow users to filter which bug reports
> they see based on whether or not the bug assumes malloc fails, etc.


Exactly :)

Best regards,
--Edwin