gzip memory corruption

[Xin LI]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eygene Ryabinkin wrote:
> Xin,
> 
> Thu, Jul 30, 2009 at 10:43:07PM -0700, Xin LI wrote:
>> After talking with Matthew Green (the author of NetBSD) it seems that it
>> would be more reasonable to fix the bug itself than breaking upon
>> receipt.  Here is the patch.
> 
> You'll probably want to check that (outsize - suffixes[0].ziplen - 1)
> is greater than zero.  Like this:
[...]
> Just now we can garantee that 'outsize' will fit any suffix because of
> the suffix length check, but when Someone (TM) will modify the code,
> this could no longer be true and a bug will arise again.  So it is
> better to check this locally and fail loudly if we can't make it happen.

We should probably add an assertion here (e.g. assert outsize >
suffixes[0].ziplen]), but no, I don't think it's the right thing to
re-check already sanitized input, it is not a good practice for
production code to check the same thing everywhere, it's something that
should happen during development and testing phase, these should be
assertions IMHO.

> I should say that transforming the "/long-path/foo.gz" (that is
> expected) into "/long-path/f.gz" isn't quite obvious for the end-user.
> But if the absence of such a transformation will break anything that
> relies on this behaviour (I can't think about any usages of this
> behaviour, but who knows), then the code should keep it.  What were
> Mattew's arguments for keeping the old behaviour?

Because GNU gzip do the truncation instead of reporting an error (I
think the original intention for the memcpy was to match this behavior
as well).

There are even worse cases for the problem you have raised, for instance
truncating /long/p/a/t/h.gz to /long/p/a/.gz .  But for now I think the
underflow issue is more serious than that, and it would be probably a
better idea if we address the stack underflow now, and have a clear mind
to re-think about how we should do it.  There is undergoing plan to
replace gzip with something more efficient as well, on the other hand.

Cheers,
- --
Xin LI <delphij at delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (FreeBSD)

iEYEARECAAYFAkpypNIACgkQi+vbBBjt66BVlQCdHJC1upV+z29Ex4pb86uDBoPc
PwsAni2t0pwuptNuP1uKKyX5LhjSSOKl
=Rf8c
-----END PGP SIGNATURE-----