From owner-freebsd-bugs@FreeBSD.ORG Mon Feb 18 17:27:35 2008 Return-Path: Delivered-To: FreeBSD-bugs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21DC816A468; Mon, 18 Feb 2008 17:27:35 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id CB98F13C46A; Mon, 18 Feb 2008 17:27:34 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 7326646B66; Mon, 18 Feb 2008 12:27:34 -0500 (EST) Date: Mon, 18 Feb 2008 17:27:34 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Daniel Corrigan In-Reply-To: <291ddc4f0802180714g3d326626v9d9b767a61232cec@mail.gmail.com> Message-ID: <20080218172503.G49202@fledge.watson.org> References: <47B90868.7000900@electron-tube.net> <291ddc4f0802180714g3d326626v9d9b767a61232cec@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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) X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 17:27:35 -0000 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 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 >> #include >> >> 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" >