Jim Bryant
2008-Feb-17 20:59 UTC
How to take down a system to the point of requiring a newfs with one line of C (userland)
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"
Jim Bryant
2008-Feb-17 21:04 UTC
How to take down a system to the point of requiring a newfs with one line of C (userland)
FYI: The system assigned kern/120781 to this bug report. IMHO, a security advisory should be issued ASAP. 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@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"
Dag-Erling Smørgrav
2008-Feb-18 05:39 UTC
How to take down a system to the point of requiring a newfs with one line of C (userland)
Jim Bryant <freebsd@electron-tube.net> writes:> #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);}Subject should be "how to take down a system [...] with three lines of badly written C, provided you have root privileges already and are too lazy to just dd if=/dev/zero of=/dev/ad0s1 count=100", which would accomplish the job much faster. Purely in the interest of showing off, here is my version. It is 81 bytes shorter than yours, it is valid C99 with POSIX extensions (yours is not), and it produces 11,450 files in about 0.2% of the time yours takes to produce 10,000. #include <unistd.h> #define b(i,v) for(int v=48;v<127;++v){f[i]=v; #define a(i) b(i,v##i) int main(void){char f[5]={'/'};a(1)a(2)a(3)truncate(f,0);}}}} DES -- Dag-Erling Sm?rgrav - des@des.no
Daniel Corrigan
2008-Feb-18 07:30 UTC
How to take down a system to the point of requiring a newfs with one line of C (userland)
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? 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"
Mike Tancsa
2008-Feb-18 12:52 UTC
How to take down a system to the point of requiring a newfs with one line of C (userland)
At 11:24 PM 2/17/2008, Jim Bryant wrote:>One line summary: > Too many files in a top-level UFS-2 filesystem directory will > cause a panic on mount. >How to repeat the problem: > Compile and run the following as instructed: > >umount that filesystem.Hi, I tried this on RELENG_7 and RELENG_6 and was not able to panic the box 0[releng7]# ls -l | wc 20098 200972 1377211 0[releng7]# df -i Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/ad6s1a 1012974 284464 647474 31% 3308 138002 2% / devfs 1 1 0 100% 0 0 100% /dev /dev/ad6s1d 5077038 1221890 3448986 26% 20243 639211 3% /tmp /dev/ad6s1e 25385516 15683412 7671264 67% 370099 2927179 11% /usr /dev/ad6s1f 40139596 847342 36081088 2% 1001 5203989 0% /var 0[releng7]# and releng_6 0[nanobsd]# ./a.out /tmp/k 0[nanobsd]# ./a.out /tmp/kl 0[nanobsd]# ls -l /tmp/ | wc 20248 182229 1327842 0[nanobsd]# df -i Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/twed0s1a 1012974 109076 822862 12% 2099 139211 1% / devfs 1 1 0 100% 0 0 100% /dev /dev/twed0s1d 4058062 3264732 468686 87% 23045 518649 4% /tmp /dev/twed0s1f 82042376 57488474 17990512 76% 2014718 8607232 19% /usr /dev/twed0s1e 20308398 5173252 13510476 28% 1813 2636009 0% /var 0[nanobsd]# After running the program and creating all the files, I just did a reboot and all worked just fine post reboot. Did you fill up the partition or run out of inodes perhaps ? ---Mike
Peter Jeremy
2008-Feb-18 13:11 UTC
How to take down a system to the point of requiring a newfs with one line of C (userland)
[CC list trimmed] On Sun, Feb 17, 2008 at 10:24:08PM -0600, Jim Bryant wrote:>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). >*/FreeBSD pjfbsd6.alcatel.com.au 6.3-STABLE FreeBSD 6.3-STABLE #4: Wed Jan 23 08:21:27 EST 2008 root@pjfbsd6.alcatel.com.au:/var/obj/usr/src/sys/pjfbsd6 i386 I have been unable to reproduce the problem as described with or without softupdates, even when I run the filesystem out of inodes. I have also tried filling '/'?? and rebooting to no avail. That said, I did run into a bug where, for some time after deleting the files from a soft-updates partition, 'df' would report that the inodes were freed but attempting to create a new file would fail with ENOSPC. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080218/6ad7f475/attachment.pgp
Technical Department
2008-Feb-18 13:12 UTC
How to take down a system to the point of requiring a newfs with one line of C (userland)
I have tried on 6.3p1 Release and 6.2p10 Release - ran out of inodes - system fine. Mike Tancsa wrote:> At 11:24 PM 2/17/2008, Jim Bryant wrote: >> One line summary: >> Too many files in a top-level UFS-2 filesystem directory will cause >> a panic on mount. >> How to repeat the problem: >> Compile and run the following as instructed: >> >> umount that filesystem. > > Hi, > > I tried this on RELENG_7 and RELENG_6 and was not able to panic the box > > 0[releng7]# ls -l | wc > 20098 200972 1377211 > 0[releng7]# df -i > Filesystem 1K-blocks Used Avail Capacity iused ifree %iused > Mounted on > /dev/ad6s1a 1012974 284464 647474 31% 3308 138002 2% / > devfs 1 1 0 100% 0 0 100% /dev > /dev/ad6s1d 5077038 1221890 3448986 26% 20243 639211 3% /tmp > /dev/ad6s1e 25385516 15683412 7671264 67% 370099 2927179 11% /usr > /dev/ad6s1f 40139596 847342 36081088 2% 1001 5203989 0% /var > 0[releng7]# > > and releng_6 > 0[nanobsd]# ./a.out /tmp/k > 0[nanobsd]# ./a.out /tmp/kl > 0[nanobsd]# ls -l /tmp/ | wc > 20248 182229 1327842 > 0[nanobsd]# df -i > Filesystem 1K-blocks Used Avail Capacity iused ifree %iused > Mounted on > /dev/twed0s1a 1012974 109076 822862 12% 2099 139211 1% / > devfs 1 1 0 100% 0 0 100% > /dev > /dev/twed0s1d 4058062 3264732 468686 87% 23045 518649 4% > /tmp > /dev/twed0s1f 82042376 57488474 17990512 76% 2014718 8607232 19% > /usr > /dev/twed0s1e 20308398 5173252 13510476 28% 1813 2636009 0% > /var > 0[nanobsd]# > > After running the program and creating all the files, I just did a > reboot and all worked just fine post reboot. > > Did you fill up the partition or run out of inodes perhaps ? > > ---Mike > _______________________________________________ > 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"