From owner-freebsd-security@FreeBSD.ORG Fri Jul 31 08:02:33 2009 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63FF3106566B for ; Fri, 31 Jul 2009 08:02:33 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id C5FF68FC1B for ; Fri, 31 Jul 2009 08:02:32 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 009895C024 for ; Fri, 31 Jul 2009 16:02:31 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id C66C755CD9AD; Fri, 31 Jul 2009 16:02:31 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id OTGOsGsV7zhu; Fri, 31 Jul 2009 16:01:48 +0800 (CST) Received: from charlie.delphij.net (c-67-188-2-183.hsd1.ca.comcast.net [67.188.2.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id BB92655CD9AC; Fri, 31 Jul 2009 16:01:41 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=DBFgQvQk8q8rcgaPjMXhadb7M4aixNlHak9ROZcAkJ8H4/hk5iTX9OHEy2ez+6TQ4 62yO+O52ieluwEBuwGQ1Q== Message-ID: <4A72A4D3.1070902@delphij.net> Date: Fri, 31 Jul 2009 01:01:23 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: rea-fbsd@codelabs.ru References: <20090708193339.GA4836@minerva.freedsl.mg> <4A553080.5060205@delphij.net> <4A553458.70005@delphij.net> <4A7231A1.2050104@delphij.net> <856ux8zhn21/d1hDLYeNjC7FQ1Y@xg9dzetjpj18poIU9mNsJ0TqP1U> <4A72846B.60604@delphij.net> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rrl , freebsd-security@freebsd.org, d@delphij.net Subject: Re: gzip memory corruption X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 08:02:33 -0000 -----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 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-----