[Bug 576431] Package Review: skipfish - Web application security scanner

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=576431

Michal Ambroz <rebus at seznam.cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
               Flag|needinfo?(rebus at seznam.cz)  |

--- Comment #24 from Michal Ambroz <rebus at seznam.cz> 2010-04-21 14:27:29 EDT ---
Hello Tomas,
regarding the FORIFY_SOURCE - here are the links to the skipfish bugzilla:
http://code.google.com/p/skipfish/issues/detail?id=34
http://code.google.com/p/skipfish/issues/detail?id=1


Result is that this won't be fixed in skipfish and is issue of the fortify code
in gcc. Skipfish upstream distributes with makefile containing
-DFORTIFY_SOURCE=0.

Issue which I have analyzed was working like that:
1) ask malloc to allocate buffer of size let say 97 bytes
2) malloc allocates 100 (according to malloc_usable_size)
3) to clean any leftovers memset(buffer, 0, 100) is called
4) this triggers coredump as FORTIFY code believes 97 bytes was requested, no
more should be accessed. 

Situation gets even more complicated with realloc.

In my opinion malloc_usable_size should be "FORTIFIED" (return only number of
requested and not allocated bytes) or FORTIFY_SOURCE should use
malloc_usable_size as the cap and not the requested bytes.

>From security point of view - if I got from kernel more space than requested it
is OK to clean it all from some lef-overs which have been there before to avoid
some posibility of injecting some unwanted data.


Best regards
Michal Ambroz

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.