Micah Anderson wrote:> 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.I disagree: First with the Linux kernel''s stock structure the differentation between local users and root is not very distinct. Every local user can become root on any Woody kernel and on every Sarge kernel as of today (and according to Horms from the kernel team the kernel vulnerabilities are supposed to be fixed after Sarge has been released (probably to avoid another d-i test cycle)). Even with a fixed kernel without local privilege escalation the execution of arbitrary code still may have grave effects, from stealing sensitive data to being the launchpad for another attack.> 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).Does it compile the same without the bfd build dep? Cheers, Moritz
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