[cfe-dev] Static Analyzer Rocks Hard

[Török Edwin]

Matthew Jimenez wrote:
> It's been my experience that developers assume success without much  
> thought as to the result of failure until they actually witness it.  
> Allocation failure is especially nasty since the chances of  
> reproducing the error is so slim, and Objective-C might be even  
> nastier as nil is a valid receiver. So the need for a tool to check  
> this exists, but for better or worse, I still wouldn't imagine  
> developers to be proactive about handling such situations.
>
> Strangely enough, I have seen many developers be much more paranoid  
> when allocating memory directly rather than through objects.
>   

Not handling allocation failures can lead to security holes if the
parameter to malloc
can be somehow controlled by an attacker.
It could request a huge amount of memory, that malloc would deny -> NULL
pointer.
You don't necessarely have to be really out-of-memory to get an
allocation failure.

DoS: NULL dereference -> app crash
Remote code execution hole: NULL pointer -> pointer arithmetic involving
another attacker controlled value
    -> valid *attacker controlled* address -> overwrite stack -> shellcode

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, ...
   
Best regards,
--Edwin