From owner-freebsd-security@FreeBSD.ORG Tue Sep 16 09:35:02 2003 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75C9616A4B3 for ; Tue, 16 Sep 2003 09:35:02 -0700 (PDT) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DB9F43FBF for ; Tue, 16 Sep 2003 09:35:01 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id 21DA654846; Tue, 16 Sep 2003 11:35:01 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id B1DB86D454; Tue, 16 Sep 2003 11:35:00 -0500 (CDT) Date: Tue, 16 Sep 2003 11:35:00 -0500 From: "Jacques A. Vidrine" To: Matthew Dillon Message-ID: <20030916163500.GA93908@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Matthew Dillon , Udo Schweigert , freebsd-security@freebsd.org References: <20030916134347.GA30359@madman.celabo.org> <20030916160543.GA28313@alaska.cert.siemens.de> <20030916161121.GA91300@madman.celabo.org> <200309161632.h8GGW1PC002728@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200309161632.h8GGW1PC002728@apollo.backplane.com> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.4i-ja.1 cc: Udo Schweigert cc: freebsd-security@freebsd.org Subject: Re: OpenSSH heads-up X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2003 16:35:02 -0000 On Tue, Sep 16, 2003 at 09:32:01AM -0700, Matthew Dillon wrote: > I've been staring at the patch for 30 minutes and I can't figure > out what it is supposed to fix. Is there some other thread or > signal or something that might access the buffer while it's length > is in an indeterminant state? The code doesn't seem to be structured > for that case. Taken from my draft advisory to be released shortly: --- excerpt --- II. Problem Description When a packet is received that is larger than the space remaining in the currently allocated buffer, OpenSSH's buffer management attempts to reallocate a larger buffer. During this process, the recorded size of the buffer is increased. The new size is then range checked. If the range check fails, then fatal() is called to cleanup and exit. In some cases, the cleanup code will attempt to zero and free the buffer that just had its recorded size (but not actual allocation) increased. As a result, memory outside of the allocated buffer will be overwritten with NUL bytes. III. Impact A remote attacker can cause OpenSSH to crash. The bug is not believed to be exploitable for code execution on FreeBSD. --- excerpt --- Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se