Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Xin LI (delphijdelphij.net)
Date: Fri Jul 31 2009 - 03:01:23 CDT
-----BEGIN PGP SIGNED MESSAGE-----
Eygene Ryabinkin wrote:
> 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.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.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
> 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
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.
Xin LI <delphijdelphij.net> http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (FreeBSD)
-----END PGP SIGNATURE-----
freebsd-securityfreebsd.org mailing list
To unsubscribe, send any mail to "freebsd-security-unsubscribefreebsd.org"