Re: gzip memory corruption

Hash: SHA1

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[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.

- --
Xin LI <delphij@xxxxxxxxxxx>
FreeBSD - The Power to Serve!
Version: GnuPG v2.0.12 (FreeBSD)

freebsd-security@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-security-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • RE: Anthonys drive issues.Re: ssh password delay
    ... The dmesg you sent indicated that the 2 disks were negotiating at ... > possible cause in the universe before blaming it on FreeBSD. ... to take the risk of it being hardware, ... believe is that it's a bug in the FreeBSD driver. ...
  • Re: What do you dislike about OSX?
    ... is is when you claim that OS X is derivative of FreeBSD. ... about *other people* not needing to have all windows visible at all times. ... Most end users don't even know the bug exists. ... offer reasons for me to change my mind. ...
  • Re: Support for 5.x (Was: Re: What about BIND 9.3.4 in FreeBSD in base system ?)
    ... Handling other people's send-pr bug input would be boring ... I've filed some send-pr diffs years back & not seen action, ... so if the FreeBSD Foundation ever has spare ...
  • Re: reverse a string
    ... the digital root of the specified characters. ... That is, if the constraints are violated, ... Therefore, if they are not observed, it indicates a bug in the ... should certainly try to fire this assertion, ...
  • Re: Do we need this junk?
    ... I have an 1742A if any developer needs it for bug chasing. ... It's a full length card. ... To counter Nikolas' `stats' argument to abandon much hardware support: ... There's scanners with FreeBSD embedded inside: ...