Branden Robinson asked: > Could I get a second opinion (or more than one) from you guys as to > whether this is actually an exploitable security problem?
I can't answer this in the affirmative, but then I only spent
about 15 minutes looking for a way to exploit it. I note that
apt-rdepends finds 9043 packages that depend on libxpm4, so
the opportunities are immense. It's probably easier to fix
the problem then scrutinize 9043 packages for plausible cases
of uncontrolled input of xpm file names.
Matej's assessment is:
> This completely breaks the transparent compression and decompression.
Which I agree with. The options for addressing this bug are:
1. Do nothing, almost guaranteeing an exploit will be found.
2. Write a real fix, instead of the stupid s_popen thing.
I might play around with option 2. There are two strategies
that make technical sense:
a. skip the sprintf/parsing step, and go directly to
execlp("uncompress","-c",filename);
b. put the uncompress/unzip code (zlib calls) inline
Where (a) involves less coding and makes fewer changes to the
build/depends process, but (b) is probably more robust at runtime.
The compression and decompression methods become distinct code paths.
Is someone from the Debian X Strike Force already working on this?
- Larry
signature.asc
Description: Digital signature
