[Secure-testing-team] ELF problems

[Micah Anderson]

A reportback on the applicability of the "integer overflow in
applications parsing ELF headers" security issue for "crash" and
"lcrash".

crash - spoke with the upstream authors, they pointed out that this
was a heap-based overflow, meaning if an attacker can create a
malformed ELF file and use crash to manipulate it in the manner
described in this bug to get mallicious code on the heap then they
would be executing code as the user that is running crash, ie. an
unpriviledged user. They consider this (and I tend to agree) as very
low risk, and there are no plans to fix it in the near future. I would
not consider this an RC bug myself, if you actually assess its
potential risk. I could be convinced its a security bug and should be
fixed sometime.

lcrash - doesn't even link against bfd[1], if it did it would be
dynamically linked against the shared library, rather than static
(which means that if you are dynamically linked against the shared
library then you can simply fix the library on the system with an
upgrade and the binary that links to it would be fixed).


[1] libncurses.so.5 => /lib/libncurses.so.5 (0xb7faa000)
    libdl.so.2 => /lib/tls/libdl.so.2 (0x41185000)
    libz.so.1 => /usr/lib/libz.so.1 (0x41857000)
    libelf.so.0 => /usr/lib/libelf.so.0  (0xb7f95000)
    libc.so.6 => /lib/tls/libc.so.6 (0x41019000)
    /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x41000000)
			   
    (libelf.so is not linked against libbfd either).

Micah	
	
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20050518/6d232674/attachment.pgp