How to take down a system to the point of requiring a newfs with one line of C (userland)

[Alexander V. Chernikov]

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?

/etc/rc.d/cleartmp does /tmp clearing only at startup, after file 
systems are mounted.


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