From owner-freebsd-security@FreeBSD.ORG Mon Feb 18 04:36:46 2008
Return-Path: <owner-freebsd-security@FreeBSD.ORG>
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 6C8BB16A421;
Mon, 18 Feb 2008 04:36:46 +0000 (UTC)
(envelope-from freebsd@electron-tube.net)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194])
by mx1.freebsd.org (Postfix) with ESMTP id 3367613C468;
Mon, 18 Feb 2008 04:36:46 +0000 (UTC)
(envelope-from freebsd@electron-tube.net)
Received: from [10.0.0.100] (c-66-41-19-246.hsd1.mn.comcast.net [66.41.19.246])
by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis)
id 0MKpCa-1JQxY10LmJ-0007KF; Sun, 17 Feb 2008 23:24:13 -0500
Message-ID: <47B90868.7000900@electron-tube.net>
Date: Sun, 17 Feb 2008 22:24:08 -0600
From: Jim Bryant <freebsd@electron-tube.net>
User-Agent: Thunderbird 1.5 (X11/20061230)
MIME-Version: 1.0
To: freebsd-fs@freebsd.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V01U2FsdGVkX18m4aZlpkrjVLAus8S+nj9gMeQSg5ef1kVfeL5
kBvaXrPkqcAljL7hUedzmZ1BOHwODKY8ldhtqzyKn8pRB4DeKh
4bKiIPYGZxwcwiK7ZMCUAgx2hLv+EHY
Cc: freebsd-security@freebsd.org, FreeBSD-bugs@freebsd.org,
freebsd-stable@freebsd.org
Subject: How to take down a system to the point of requiring a newfs with
one line of C (userland)
X-BeenThere: freebsd-security@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Security issues \[members-only posting\]"
<freebsd-security.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-security>,
<mailto:freebsd-security-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-security>
List-Post: <mailto:freebsd-security@freebsd.org>
List-Help: <mailto:freebsd-security-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-security>,
<mailto:freebsd-security-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Feb 2008 04:36:46 -0000
One line summary:
Too many files in a top-level UFS-2 filesystem directory will cause
a panic on mount.
Kern/Critical/High Priority/SW-Bug
Which FreeBSD Release You Are Using:
6.3-STABLE
Environment (output of "uname -a" on the problem machine):
FreeBSD wahoo.sd67dfl.org 6.3-STABLE FreeBSD 6.3-STABLE #0: Sun Feb
10 21:13:39 CST 2008
jbryant@wahoo.sd67dfl.org:/usr/obj/usr/src/sys/WAHOO-SMP i386
Note: I just cvsupped earlier, and no changes have been put into
cvsup that would fix this problem.
Full Description:
I was doing a reorganization of my filesystems, and since I do
offline installs, I keep a local distfiles collection (or did until
yesterday when this happened), and in the process, put all of the
distfiles on their own filesystem to be mounted under /usr/ports/distfiles.
All was fine until I rebooted.
On rebooting, I got a page fault panic on mount of the new distfiles
filesystem.
i booted again, got it again, booted again this time into single-user,
and did a fsck on the filesystem, and it only showed as being "dirty",
but otherwise had no problems in the eyes of fsck. booted again,
instant panic.
i booted an older 6.2 CD and mounted the filesystem fine. i then put
that filesystem the way it was by mkdir'ing a distfiles dir and mv'ing
everything into it, but on reboot it still paniced on mount.
only a newfs was able to enable the filesystem to be mounted.
today i did further research, thinking it had to do with the number of
files in the top-level filesystem directory, and found that to be true.
the short c program in the next section (how to repeat the problem)
contains this.
a second test shows that, after a newfs, if this done in any
subdirectory of that filesystem, the panic is averted, and all is well.
apparently this bug only effects top-level directories of a UFS2 filesystem.
I have not attempted this to a non-UFS2 filesystem.
IMHO, a security advisory should be released, since any user with write
access to ANY top level directory of ANY mounted filesystem (most
systems have /tmp as a world writable top level filesystem directory)
can create a panic situation requiring a newfs of the said filesystem.
A malicious user with root access can do this to /. Either way, on
boot, or any attempt to mount said filesystem on a running system, will
cause a panic, which of course will cause an unbootable system on reboot.
How to repeat the problem:
Compile and run the following as instructed:
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv) { int i; char buf[1024]; bzero(buf,
1024); for(i = 0; i < 10000; i++) { sprintf(buf, "touch %s%05d\n",
argv[1], i); system((const char *)buf);} return(0);}
/* pass a top-level mountpoint directory name of a mounted filesystem,
with a trailing slash to the above as argv[1], and run.
This will create 10,000 zero-length files in the specified directory.
umount that filesystem.
perform a shitload of sync's to make sure everything outstanding is
flushed to disk on all filesystems.
mount the target filesystem (preferably from a vty or serial console to
catch the messages when it panics, which it will as soon as the mount is
attempted).
*/
Fix to the problem if known:
newfs(8)