Subject: fd 0/1/2
To: None <tech-security@netbsd.org>
From: None <itojun@iijlab.net>
List: tech-security
Date: 05/14/2002 19:14:29
sorry for dumb question - does it affect us?
itojun
------- Forwarded Message
Delivery-Date: Mon May 13 10:48:42 2002
by coconut.itojun.org (Postfix) with ESMTP id 6102C4B22
for <itojun@itojun.org>; Mon, 13 May 2002 10:48:41 +0900 (JST)
id BB884628; Mon, 13 May 2002 10:48:40 +0900 (JST)
by sh1.iijlab.net (Postfix) with ESMTP id 6CBF864C
for <itojun@iijlab.net>; Mon, 13 May 2002 10:47:14 +0900 (JST)
by outgoing.securityfocus.com (Postfix) with QMQP
id CC610A313D; Fri, 10 May 2002 18:28:43 -0600 (MDT)
Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm
List-Id: <bugtraq.list-id.securityfocus.com>
List-Post: <mailto:bugtraq@securityfocus.com>
List-Help: <mailto:bugtraq-help@securityfocus.com>
List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com>
List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com>
Date: Thu, 9 May 2002 18:54:31 +0200 (CEST)
From: Jonas Eriksson <je@sekure.net>
To: bugtraq@securityfocus.com
Subject: Re: OpenBSD local DoS and root exploit
In-Reply-To: <Pine.LNX.4.43.0205090924490.17487-100000@mail.securityfocus.com>
Message-ID: <Pine.BSO.4.44.0205091852200.17828-100000@birdie.sekure.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
The response from the OpenBSD team:
- ---
Date: Thu, 09 May 2002 08:35:34 -0600
From: Todd C. Miller <Todd.Miller@courtesan.com>
To: security-announce@openbsd.org
Subject: Potential localhost root hole
In July of 1998 the OpenBSD kernel was modified to populate file
descriptors 0-2 on exec for setuid (and setgid) processes. This
was done to defeat an attack on setuid programs that open files for
writing and also write to descriptors 0-2 (usually via stdin, stdout
or stderr).
The fix at that time didn't properly deal with the possibility that
the allocation of the dummy descriptors could fail due to a full
file descriptor table. It has come to our attention that there is
a winnable race condition when the file descriptor table is full,
allowing an fd 0-2 attack to succeed.
Credit for finding this goes to FozZy of Hackademy / Hackerz Voice.
Please see his advisory on bugtraq for more in-depth details.
The following patches are available:
OpenBSD-3.1:
ftp://ftp.openbsd.org/pub/OpenBSD/patches/3.1/common/003_fdalloc2.patch
OpenBSD-3.0:
ftp://ftp.openbsd.org/pub/OpenBSD/patches/3.0/common/021_fdalloc2.patch
OpenBSD-2.9:
ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.9/common/026_fdalloc2.patch
OpenBSD-current as well as the OpenBSD 2.9, 3.0 and 3.1 -stable
branches have already been patched.
On Thu, 9 May 2002, Dave Ahmad wrote:
> Hey,
>
> After posting this, Fozzy sent another message mentioning that he left out
> some credit. I requested that he fix the advisory and re-send it to the
> list, but he hasn't gotten back to me fast enough ;). This needs to go
> out, so here's the correction:
>
> >I realized this credit problem just after sending my post :
> >"Three weeks ago, XXXXXXXX from Pine released an advisory..." should be :
> >"Three weeks ago, Joost Pol from Pine released an advisory...".
>
> Dave Ahmad
> SecurityFocus
> www.securityfocus.com
>
> On Thu, 9 May 2002 fozzy@dmpfrance.com wrote:
>
> >
> > The following is research material from FozZy from Hackademy and Hackerz
> > Voice newspaper (http://www.hackerzvoice.org), and can be distributed
> > modified or not if proper credits are given to them. For educational
> > purposes only, no warranty of any kind, I may be wrong, this post could
> > kill you mail reader, etc.
> >
> >
> > -= OVERVIEW =-
> >
> > On current OpenBSD systems, any local user (being or not in the wheel
> > group) can fill the kernel file descriptors table, leading to a denial of
> > service. Because of a flaw in the way the kernel checks closed file
> > descriptors 0-2 when running a setuid program, it is possible to combine
> > these bugs and earn root access by winning a race condition.
> >
> >
>
>
- --
Favourite pickup line: Hey baby, wanna synchronize sequence numbers?
Warning: not always effective
------- End of Forwarded Message