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

[Robert Watson]

On Sun, 17 Feb 2008, Jim Bryant wrote:

> FYI: The system assigned kern/120781 to this bug report.
>
> IMHO, a security advisory should be issued ASAP.

Thanks for the report, I'm sure your widely distributed e-mail will get 
someone looking at it quickly.  In the future if you run into an issue you 
think might require a security advisory, consider e-mailing it privately to 
secteam at FreeBSD.org so that the release of patches can cooincide with 
publication of the problem.

That said, this is probably more a candidate for an errata patch rather than a 
security advisory -- security advisories are normally limited to local/remote 
privilege escalation or serious remote denial of service.  Local denial of 
service problems occur in all operating systems I'm aware of with such 
frequency that the world would be continuously innundated with advisories to 
the point of rendering advisories useless if we did them every time someone 
discovered a way users could crash the system.  You need only watch the change 
logs of the various open source kernels for the words "fix panic", "don't 
dereference NULL pointer", "don't leak a lock...", etc, to get a sense of the 
quantity of locally exercisable system bugs, many of which can lead to 
reboots, hangs, or data loss, to see why.  Hopefully this bug will get 
resolved shortly, and then we can evaluate if an errata notice is necessary.

Robert N M Watson
Computer Laboratory
University of Cambridge

>
> Jim Bryant 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"
>
_______________________________________________
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"