Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 18 Feb 2008 17:27:34 +0000 (GMT)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Daniel Corrigan <phisher1@gmail.com>
Cc:        freebsd-fs@freebsd.org, freebsd-security@freebsd.org, FreeBSD-bugs@freebsd.org, freebsd-stable@freebsd.org
Subject:   Re: How to take down a system to the point of requiring a newfs	with one line of C (userland)
Message-ID:  <20080218172503.G49202@fledge.watson.org>
In-Reply-To: <291ddc4f0802180714g3d326626v9d9b767a61232cec@mail.gmail.com>
References:  <47B90868.7000900@electron-tube.net> <291ddc4f0802180714g3d326626v9d9b767a61232cec@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 18 Feb 2008, Daniel Corrigan wrote:

> Since this was released to a public mailing list, I can only assume some 
> less than nice user will attempt this. The only top level file system I have 
> that can be written to by normal users is /tmp
>
> Should clear_tmp_enable="YES" in /etc/rc.conf prevent this from causing 
> harm?

There are a few things that come to mind, depending on how reproduceable this 
is.  If we think it's purely a property of the number of files in the root 
directory (I think this is an unlikely single cause -- it might have to do 
with the size of the directory, or such, which loosely corresponds to it), 
then you can limit the number of inodes in the file system at all.  The 
example code in the report suggests 10,000 entries does the trick.  You could 
create a /tmp limited to, say, 5000 entries.  You can also use quotas to limit 
the number of inodes allocated by any one user but leave the file system 
unmodified, as while modifying the file system may be OK for /tmp, it's 
probably less OK for /home.

Robert N M Watson
Computer Laboratory
University of Cambridge

>
> Dan
>
> On Feb 17, 2008 10:24 PM, Jim Bryant <freebsd@electron-tube.net> wrote:
>
>> 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)
>>
>> _______________________________________________
>> freebsd-security@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-security
>> To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org
>> "
>>
> _______________________________________________
> freebsd-security@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"
> _______________________________________________
> freebsd-fs@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080218172503.G49202>