[Secure-testing-team] ELF problems

[Moritz Muehlenhoff]

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