From owner-freebsd-security Tue May 21 16:01:55 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA08002 for security-outgoing; Tue, 21 May 1996 16:01:55 -0700 (PDT) Received: from onyx.nervosa.com (root@nervosa.com [192.187.228.86]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA07975 for ; Tue, 21 May 1996 16:01:41 -0700 (PDT) Received: from onyx.nervosa.com (coredump@onyx.nervosa.com [10.0.0.1]) by onyx.nervosa.com (8.7.5/8.7.3) with SMTP id QAA04487 for ; Tue, 21 May 1996 16:01:34 -0700 (PDT) Date: Tue, 21 May 1996 16:01:33 -0700 (PDT) From: "Chris J. Layne" To: freebsd-security@freebsd.org Subject: [linux-security] Things NOT to put in root's crontab (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I think this applies to our cleanup of /tmp in /etc/rc == Chris Layne ======================================== Nervosa Computing == == coredump@nervosa.com ================ http://www.nervosa.com/~coredump == ---------- Forwarded message ---------- Date: Tue, 21 May 1996 13:10:36 -0400 (EDT) From: Zygo Blaxell To: linux-security@tarsier.cv.nrao.edu, best-of-security@suburbia.net Subject: [linux-security] Things NOT to put in root's crontab Sigh. Here are several things I've just removed from /etc/crontab on every RedHat Linux system I can get my hands on. They contain security holes related to the use of 'find' and 'rm' to expire old files in /tmp and other places. It seems that awareness of this type of security problem is rather low, so I'll explain the class of problem and how to fix it. >From Redhat's /etc/crontab file: ># Remove /var/tmp files not accessed in 10 days >43 02 * * * root find /var/tmp/* -atime +3 -exec rm -f {} \; 2> /dev/null > ># Remove /tmp files not accessed in 10 days ># I commented out this line because I tend to "store" stuff in /tmp ># 41 02 * * * root find /tmp/* -atime +10 -exec rm -f {} \; 2> /dev/null > ># Remove formatted man pages not accessed in 10 days >39 02 * * * root find /var/catman/cat?/* -atime +10 -exec rm -f {} \; 2> /dev/null > ># Remove and TeX fonts not used in 10 days >35 02 * * * root find /var/lib/texmf/* -type f -atime +10 -exec rm -f {} \; 2> /dev/null Folks, do NOT use 'find' on a public directory with '-exec rm -f' as root. Period. Ever. Delete it from your crontab *now* and finish reading the rest of this message later. * PROBLEM DISCUSSION AND EXPLOITATION The immediate security problem is that 'rm' doesn't check that components of the directory name are not symlinks. This means that you can delete any file on the system; indeed, with a little work you can delete *every* file on the system, provided that you can determine the file names (though you might be limited to deleting files more than ten days old). First, create the directories and file: /tmp/hacker-fest/some/arbitrary/set/of/path/names/etc/passwd where all but the last component is a directory. Be ready to replace 'etc' with a symlink to '/etc', so that: /tmp/hacker-fest/some/arbitrary/set/of/path/names/etc -> /etc i.e. the path components of the file name will point to a file named 'passwd' in a different directory. If the replacement operation occurs between when 'find' sets {} to "/tmp/hacker...etc/passwd" and when 'rm' calls unlink on "/tmp/hacker...etc/passwd", then rm will in fact delete '/etc/passwd', and not a file in /tmp. Deleting other files is left as an exercise. The race condition is really easy to win. Create a directory with 400 path components, like this: /tmp/hacker-fest/a/a/a/a/a/a/a.../a/a/a/etc/passwd (1) Then arrange for each of the 'a' components to be a symlink to a directory somewhere near the bottom of a similar tree. For example, /tmp/hacker-fest/a could be a symlink to /tmp/hacker-fest/b/b/b/b/b/b/b/b/b/.../b/b/b/b/b/b/a which could be a symlink to /tmp/hacker-fest/c/c/c/c/c/c/.../c/c/c/c/c/c/c and so on. In fact, *each* path component can be a symlink up to about 8 levels or so. Any operation such as stat(), open(), lstat(), etc. on one of these pathnames will cause the kernel to follow each and every symlink. The difference between lstat() and stat() in this case is that lstat() will not follow the *last* symlink. This will make lstat() and friends *extremely* slow, on the order of several *minutes* per lstat() operation, because each lstat() is now reading in several thousand inodes and disk blocks. If you fill each directory with several hundred entries, then create the entry you want, then delete the others, you force the kernel to waste its time reading kilobytes of empty directory blocks--in fact, you can make one stat() or unlink() operation read almost the entire disk in an order designed to maximize disk head motion if you know what you're doing. If you have an NFS, CDROM, or floppy-disk filesystem handy, you can get *weeks* per lstat(). Of course, 'find' will normally see the first symlink and stop. To prevent this, you rename the original directory (at (1) above) and create another directory with the same name and about 5000 empty files, some of which have the same name as files you want to delete. Note that these 5000 empty files can all be hard links to the same file, to save precious inodes for more of those symlinks. 'find' will spend considerable time iterating through these 5000 files. When it does (you'll be able to tell because the atime of the directory changes as find reads it), put the directory with the millions of symlinks at (1) back with a couple of rename operations. Some versions of 'find' will not be adversely impacted by this, but 'rm' definitely will. It is usually sufficient to simply create the 400-component-long directory, put 5000 files in it, wait for the atime of the directory to change, then do the rename so that 'rm' follows a symlink. I used this technique to remove /etc/crontab as a test case. If you have: /tmp/hacker-fest/a/a/a/a/a/.../a/etc/passwd (and 5000+ other files) /tmp/hacker-fest/a/a/a/a/a/.../a/usr where 'usr' is a symlink to '/usr', you can get some implementations of find to start recursing through /usr as well. * OTHER PROBLEMS WITH THIS CRONTAB A user can set the atime of any file they own to an arbitrary value, and that programs like zip, tar, and cpio will do this for you automatically; this makes 'atime' an almost useless indicator of when a file was last used ('mtime' has the same problem). Either the file will be deleted too early, because it was extracted from an archive using a program that preserves timestamps, or users can set the atime to well into the future and use /tmp space indefinitely. The later of ctime (to detect writes) and atime (to detect reads; must check that atime is not in the future) is a good indicator of when a file was last used. Miscellaneous bugs: the use of '*' means that files in a directory named '.foo' will never be cleaned (and you can prevent 'find' from working at all by putting more than 1020 files in /tmp). There are subdirectories of /var/catman that aren't properly handled by the 'find' command given (local and X11). You can't delete a directory with 'rm -f'. In other words, not only is RedHat's /etc/crontab a major security hole, it doesn't actually work properly, either. :( * FIXES The easiest way to fix this is to get rid of the find/rm stuff completely. If you need a garbage collector, try our LRU garbage collection daemon at the URL given below. Adding a system call that sets a flag that prevents a process from being able to ever follow a symlink would be non-portable, but efficient and effective. The next easiest way to fix this is to replace 'rm' with a program that does not follow symlinks. It must check that each filename component in turn by doing an lstat() of the directory, chdir() into the directory, and further lstat()s to check that the device/inode number of '.' is the same as the directory's device/inode number before chdir(). The parameter of the 'unlink' or 'rmdir' system call must not contain a slash; if it does, then the directory name before the slash can be replaced by a symlink to a different directory between verification of path components and the actual unlink() call. Another way to fix this is with a smarter version of find. A smart find does the chdir() and lstat() checks to make sure that it never crosses a symlink, and calls the program in 'exec' using a filename with no directory components, relative to the current directory. Thus, to delete: /tmp/hacker-fest/a/a/a/a/a/.../etc/passwd find first carefully (checking for attempts to exploit race conditions before and *after* each chdir()) chdir()s into /tmp/hacker-fest/a/a/a/a/a/.../etc and will fail if any of the components is a symlink, plugging the hole described above. After verifying that the '.../etc' is really a subdirectory of /tmp, and not some random point on the filesystem, find exec's the command: rm -f ./passwd which is secure as long as '.' isn't in your PATH. Note the leading './' to prevent rm from interpreting the filename as a parameter. Note: this is in *addition* to the checks that find already makes to determine whether a file is a symlink *before* chdir()ing into it. It must make sure that components of the path that have *already* been tested are not replaced with symlinks or renamed directories *after* find has started processing subdirectories of them. Note that the 'smart' find without the post-chdir symlink tests won't work. While smart-find is processing: /tmp/hacker-fest/a/a/a/a/* you can rename /tmp/hacker-fest/a/a/a/a to /tmp/hacker-fest/a/a/b (note: one less pathname component) and eventually smart-find will 'cd ..', but since the current directory of find has moved, '..' will move as well, and eventually smart-find will be one level too high and can start descending into other subdirectories of '/'. To help this along you may need to create: /tmp/hacker-fest/usr /tmp/hacker-fest/var etc. * SAFE LRU GARBAGE COLLECTION Our LRU /tmp garbage collector daemon is available at . It is implemented in perl5. It depends on a Linux-specific 'statfs()' system call to monitor available free space, so non-Linux people will need to do a port (send me patches and I'll incorporate them). Our garbage collector: handles the above security problems correctly, handles pathnames more than 1024 characters, uses smarter last-access estimates than just atime or ctime, can support "permanent" subdirectories, handles files, symlinks, directories, devices, mount points correctly, can support minimum age of files (e.g. no files < 1 day old), deletes oldest files first, deletes files only when disk space is low, and responds in less than ten seconds to low disk space conditions. Our garbage collector works on any directory where files can gracefully disappear at arbitrary times, such as /var/catman, /tmp, /var/tmp, TeX font directories, and our HTTP proxy cache. One directory where the garbage collector doesn't work very well is /var/spool/news; we had to hack things up a bit to fix the article databases when article files disappear. -- Zygo Blaxell. Former Unix/soft/hardware guru, U of Waterloo Computer Science Club. Current sysadmin for Myrus Design, Inc. 10th place, ACM Intl Collegiate Programming Contest Finals, 1994. Administer Linux nets for food, clothing, and anime. "I gave up $1000 to avoid working on windoze... *sigh*" - Amy Fong From owner-freebsd-security Tue May 21 20:51:20 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA05847 for security-outgoing; Tue, 21 May 1996 20:51:20 -0700 (PDT) Received: from haven.uniserve.com (haven.uniserve.com [198.53.215.121]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id UAA05818 for ; Tue, 21 May 1996 20:51:07 -0700 (PDT) Received: by haven.uniserve.com id <30782-15631>; Tue, 21 May 1996 20:54:32 -0800 Date: Tue, 21 May 1996 20:54:18 -0700 (PDT) From: Tom Samplonius To: "Chris J. Layne" cc: freebsd-security@freebsd.org Subject: Re: [linux-security] Things NOT to put in root's crontab (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 21 May 1996, Chris J. Layne wrote: > I think this applies to our cleanup of /tmp in /etc/rc I think it doesn't. Our rm removes links, not files pointed to by links. So: cd /tmp ln -s /etc/passwd thing rm thing will remove the link, not /etc/passwd. We are not dependant on find to produce a "valid" list of files, so that rm does not remove something important. Tom > == Chris Layne ======================================== Nervosa Computing == > == coredump@nervosa.com ================ http://www.nervosa.com/~coredump == > > ---------- Forwarded message ---------- > Date: Tue, 21 May 1996 13:10:36 -0400 (EDT) > From: Zygo Blaxell > To: linux-security@tarsier.cv.nrao.edu, best-of-security@suburbia.net > Subject: [linux-security] Things NOT to put in root's crontab > > Sigh. Here are several things I've just removed from /etc/crontab on > every RedHat Linux system I can get my hands on. They contain security > holes related to the use of 'find' and 'rm' to expire old files in /tmp > and other places. > > It seems that awareness of this type of security problem is rather low, > so I'll explain the class of problem and how to fix it. > > >From Redhat's /etc/crontab file: > ># Remove /var/tmp files not accessed in 10 days > >43 02 * * * root find /var/tmp/* -atime +3 -exec rm -f {} \; 2> /dev/null > > > ># Remove /tmp files not accessed in 10 days > ># I commented out this line because I tend to "store" stuff in /tmp > ># 41 02 * * * root find /tmp/* -atime +10 -exec rm -f {} \; 2> /dev/null > > > ># Remove formatted man pages not accessed in 10 days > >39 02 * * * root find /var/catman/cat?/* -atime +10 -exec rm -f {} \; 2> /dev/null > > > ># Remove and TeX fonts not used in 10 days > >35 02 * * * root find /var/lib/texmf/* -type f -atime +10 -exec rm -f {} \; 2> /dev/null > > Folks, do NOT use 'find' on a public directory with '-exec rm -f' as root. > Period. Ever. Delete it from your crontab *now* and finish reading the > rest of this message later. > > * PROBLEM DISCUSSION AND EXPLOITATION > > The immediate security problem is that 'rm' doesn't check that > components of the directory name are not symlinks. This means that you > can delete any file on the system; indeed, with a little work you can > delete *every* file on the system, provided that you can determine the > file names (though you might be limited to deleting files more than ten > days old). > > First, create the directories and file: > > /tmp/hacker-fest/some/arbitrary/set/of/path/names/etc/passwd > > where all but the last component is a directory. Be ready to > replace 'etc' with a symlink to '/etc', so that: > > /tmp/hacker-fest/some/arbitrary/set/of/path/names/etc -> /etc > > i.e. the path components of the file name will point to a file named > 'passwd' in a different directory. > > If the replacement operation occurs between when 'find' sets {} to > "/tmp/hacker...etc/passwd" and when 'rm' calls unlink on > "/tmp/hacker...etc/passwd", then rm will in fact delete '/etc/passwd', > and not a file in /tmp. Deleting other files is left as an exercise. > > The race condition is really easy to win. Create a directory with 400 > path components, like this: > > /tmp/hacker-fest/a/a/a/a/a/a/a.../a/a/a/etc/passwd (1) > > Then arrange for each of the 'a' components to be a symlink to a > directory somewhere near the bottom of a similar tree. For example, > > /tmp/hacker-fest/a > > could be a symlink to > > /tmp/hacker-fest/b/b/b/b/b/b/b/b/b/.../b/b/b/b/b/b/a > > which could be a symlink to > > /tmp/hacker-fest/c/c/c/c/c/c/.../c/c/c/c/c/c/c > > and so on. In fact, *each* path component can be a symlink up to about > 8 levels or so. Any operation such as stat(), open(), lstat(), etc. > on one of these pathnames will cause the kernel to follow each and every > symlink. The difference between lstat() and stat() in this case is that > lstat() will not follow the *last* symlink. > > This will make lstat() and friends *extremely* slow, on the order of > several *minutes* per lstat() operation, because each lstat() is now > reading in several thousand inodes and disk blocks. If you fill each > directory with several hundred entries, then create the entry you want, > then delete the others, you force the kernel to waste its time reading > kilobytes of empty directory blocks--in fact, you can make one stat() or > unlink() operation read almost the entire disk in an order designed to > maximize disk head motion if you know what you're doing. If you have an > NFS, CDROM, or floppy-disk filesystem handy, you can get *weeks* per > lstat(). > > Of course, 'find' will normally see the first symlink and stop. To > prevent this, you rename the original directory (at (1) above) and > create another directory with the same name and about 5000 empty files, > some of which have the same name as files you want to delete. Note that > these 5000 empty files can all be hard links to the same file, to save > precious inodes for more of those symlinks. > > 'find' will spend considerable time iterating through these 5000 files. > When it does (you'll be able to tell because the atime of the directory > changes as find reads it), put the directory with the millions of > symlinks at (1) back with a couple of rename operations. Some versions > of 'find' will not be adversely impacted by this, but 'rm' definitely > will. > > It is usually sufficient to simply create the 400-component-long > directory, put 5000 files in it, wait for the atime of the directory to > change, then do the rename so that 'rm' follows a symlink. I used this > technique to remove /etc/crontab as a test case. > > If you have: > > /tmp/hacker-fest/a/a/a/a/a/.../a/etc/passwd (and 5000+ other files) > /tmp/hacker-fest/a/a/a/a/a/.../a/usr > > where 'usr' is a symlink to '/usr', you can get some implementations of > find to start recursing through /usr as well. > > * OTHER PROBLEMS WITH THIS CRONTAB > > A user can set the atime of any file they own to an arbitrary value, and > that programs like zip, tar, and cpio will do this for you > automatically; this makes 'atime' an almost useless indicator of when a > file was last used ('mtime' has the same problem). Either the file will > be deleted too early, because it was extracted from an archive using a > program that preserves timestamps, or users can set the atime to well > into the future and use /tmp space indefinitely. The later of ctime (to > detect writes) and atime (to detect reads; must check that atime is not > in the future) is a good indicator of when a file was last used. > > Miscellaneous bugs: the use of '*' means that files in a directory > named '.foo' will never be cleaned (and you can prevent 'find' from > working at all by putting more than 1020 files in /tmp). There are > subdirectories of /var/catman that aren't properly handled by the 'find' > command given (local and X11). You can't delete a directory with > 'rm -f'. > > In other words, not only is RedHat's /etc/crontab a major security hole, > it doesn't actually work properly, either. :( > > * FIXES > > The easiest way to fix this is to get rid of the find/rm stuff > completely. If you need a garbage collector, try our LRU garbage > collection daemon at the URL given below. > > Adding a system call that sets a flag that prevents a process from being > able to ever follow a symlink would be non-portable, but efficient and > effective. > > The next easiest way to fix this is to replace 'rm' with a program that > does not follow symlinks. It must check that each filename component in > turn by doing an lstat() of the directory, chdir() into the directory, > and further lstat()s to check that the device/inode number of '.' is > the same as the directory's device/inode number before chdir(). The > parameter of the 'unlink' or 'rmdir' system call must not contain a > slash; if it does, then the directory name before the slash can be > replaced by a symlink to a different directory between verification of > path components and the actual unlink() call. > > Another way to fix this is with a smarter version of find. A smart > find does the chdir() and lstat() checks to make sure that it never > crosses a symlink, and calls the program in 'exec' using a filename > with no directory components, relative to the current directory. > Thus, to delete: > > /tmp/hacker-fest/a/a/a/a/a/.../etc/passwd > > find first carefully (checking for attempts to exploit race conditions > before and *after* each chdir()) chdir()s into > > /tmp/hacker-fest/a/a/a/a/a/.../etc > > and will fail if any of the components is a symlink, plugging the hole > described above. After verifying that the '.../etc' is really a > subdirectory of /tmp, and not some random point on the filesystem, find > exec's the command: > > rm -f ./passwd > > which is secure as long as '.' isn't in your PATH. Note the leading > './' to prevent rm from interpreting the filename as a parameter. > > Note: this is in *addition* to the checks that find already makes to > determine whether a file is a symlink *before* chdir()ing into it. It must > make sure that components of the path that have *already* been tested > are not replaced with symlinks or renamed directories *after* find has > started processing subdirectories of them. > > Note that the 'smart' find without the post-chdir symlink tests won't > work. While smart-find is processing: > > /tmp/hacker-fest/a/a/a/a/* > > you can rename > > /tmp/hacker-fest/a/a/a/a > > to > > /tmp/hacker-fest/a/a/b (note: one less pathname component) > > and eventually smart-find will 'cd ..', but since the current directory > of find has moved, '..' will move as well, and eventually smart-find > will be one level too high and can start descending into other > subdirectories of '/'. To help this along you may need to create: > > /tmp/hacker-fest/usr > /tmp/hacker-fest/var > etc. > > * SAFE LRU GARBAGE COLLECTION > > Our LRU /tmp garbage collector daemon is available at > . It > is implemented in perl5. It depends on a Linux-specific 'statfs()' > system call to monitor available free space, so non-Linux people will > need to do a port (send me patches and I'll incorporate them). > > Our garbage collector: > handles the above security problems correctly, > handles pathnames more than 1024 characters, > uses smarter last-access estimates than just atime or ctime, > can support "permanent" subdirectories, > handles files, symlinks, directories, devices, mount points correctly, > can support minimum age of files (e.g. no files < 1 day old), > deletes oldest files first, > deletes files only when disk space is low, > and responds in less than ten seconds to low disk space conditions. > > Our garbage collector works on any directory where files can gracefully > disappear at arbitrary times, such as /var/catman, /tmp, /var/tmp, > TeX font directories, and our HTTP proxy cache. One directory where > the garbage collector doesn't work very well is /var/spool/news; we > had to hack things up a bit to fix the article databases when article > files disappear. > > -- > Zygo Blaxell. Former Unix/soft/hardware guru, U of Waterloo Computer Science > Club. Current sysadmin for Myrus Design, Inc. 10th place, ACM Intl Collegiate > Programming Contest Finals, 1994. Administer Linux nets for food, clothing, > and anime. "I gave up $1000 to avoid working on windoze... *sigh*" - Amy Fong > > From owner-freebsd-security Tue May 21 21:17:07 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA09263 for security-outgoing; Tue, 21 May 1996 21:17:07 -0700 (PDT) Received: from haven.uniserve.com (haven.uniserve.com [198.53.215.121]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id VAA09256 for ; Tue, 21 May 1996 21:17:03 -0700 (PDT) Received: by haven.uniserve.com id <30780-15629>; Tue, 21 May 1996 21:20:23 -0800 Date: Tue, 21 May 1996 21:20:22 -0700 (PDT) From: Tom Samplonius To: "Chris J. Layne" , freebsd-security@FreeBSD.ORG Subject: Re: [linux-security] Things NOT to put in root's crontab (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 21 May 1996, Tom Samplonius wrote: > > On Tue, 21 May 1996, Chris J. Layne wrote: > > > I think this applies to our cleanup of /tmp in /etc/rc > > I think it doesn't. > > Our rm removes links, not files pointed to by links. So: > > cd /tmp > ln -s /etc/passwd thing > rm thing > > will remove the link, not /etc/passwd. I don't know what I was thinking when I wrote that: cd /tmp ln -s /etc b rm b/passwd will remove /etc/passwd. However, I don't believe that this method can exploited with the standard /etc/rc because we use "rm -rf". I don't find should be doing a depth-first traversal in this case. I'll get sleep before I comment more. Tom From owner-freebsd-security Tue May 21 23:54:12 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA22659 for security-outgoing; Tue, 21 May 1996 23:54:12 -0700 (PDT) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA22653 for ; Tue, 21 May 1996 23:54:09 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id XAA13950; Tue, 21 May 1996 23:53:40 -0700 From: "Rodney W. Grimes" Message-Id: <199605220653.XAA13950@GndRsh.aac.dev.com> Subject: Re: [linux-security] Things NOT to put in root's crontab (fwd) To: tom@uniserve.com (Tom Samplonius) Date: Tue, 21 May 1996 23:53:40 -0700 (PDT) Cc: coredump@nervosa.com, freebsd-security@FreeBSD.ORG In-Reply-To: from Tom Samplonius at "May 21, 96 09:20:22 pm" X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > On Tue, 21 May 1996, Tom Samplonius wrote: > > > > > On Tue, 21 May 1996, Chris J. Layne wrote: > > > > > I think this applies to our cleanup of /tmp in /etc/rc > > > > I think it doesn't. > > > > Our rm removes links, not files pointed to by links. So: > > > > cd /tmp > > ln -s /etc/passwd thing > > rm thing > > > > will remove the link, not /etc/passwd. > > I don't know what I was thinking when I wrote that: > > cd /tmp > ln -s /etc b > rm b/passwd > > will remove /etc/passwd. > > However, I don't believe that this method can exploited with > the standard /etc/rc because we use "rm -rf". I don't find should be > doing a depth-first traversal in this case. /etc/rc is not the problem, /etc/*ly is: SkyRsh# grep exec /etc/*ly /etc/daily: find . ! -name . -mtime +7 -exec rm -f -- {} \; ; } ^^^^^^^^^^^ /etc/daily: find . ! -name . -mtime +7 -exec rm -f -- {} \; ; } ^^^^^^^^^^^ /etc/daily:# -a -atime +3 -exec rm -f -- {} \; ^^^^^^^^^^^ /etc/weekly:PATH=/bin:/sbin:/usr/sbin:/usr/bin:/usr/libexec /etc/weekly:#find /usr/src -name '*.o' -atime +21 -print -a -exec rm -f {} \; ^^^^^^^^^^^ /etc/weekly:echo /usr/libexec/locate.updatedb | nice -5 su -m nobody 2>&1 |\ > > I'll get sleep before I comment more. > > Tom > -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-security Tue May 21 23:55:46 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA22752 for security-outgoing; Tue, 21 May 1996 23:55:46 -0700 (PDT) Received: from relay.philips.nl (ns.philips.nl [130.144.65.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id XAA22747 for ; Tue, 21 May 1996 23:55:43 -0700 (PDT) Received: (from smap@localhost) by relay.philips.nl (8.6.9/8.6.9-950414) id IAA16103; Wed, 22 May 1996 08:54:19 +0200 Received: from unknown(192.26.173.32) by ns.philips.nl via smap (V1.3+ESMTP) with ESMTP id sma016042; Wed May 22 08:53:39 1996 Received: from spooky.lss.cp.philips.com (spooky.lss.cp.philips.com [130.144.199.105]) by smtp.nl.cis.philips.com (8.6.10/8.6.10-0.9z-02May95) with ESMTP id IAA01327; Wed, 22 May 1996 08:55:23 +0200 Received: (from guido@localhost) by spooky.lss.cp.philips.com (8.6.10/8.6.10-0.991c-08Nov95) id IAA23614; Wed, 22 May 1996 08:53:31 +0200 From: Guido van Rooij Message-Id: <199605220653.IAA23614@spooky.lss.cp.philips.com> Subject: Re: [linux-security] Things NOT to put in root's crontab (fwd) To: tom@uniserve.com (Tom Samplonius) Date: Wed, 22 May 1996 08:53:31 +0200 (MET DST) Cc: coredump@nervosa.com, freebsd-security@FreeBSD.ORG In-Reply-To: from "Tom Samplonius" at May 21, 96 08:54:18 pm Reply-To: Guido.vanRooij@nl.cis.philips.com (Guido van Rooij) X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Tom Samplonius wrote: > > > On Tue, 21 May 1996, Chris J. Layne wrote: > > > I think this applies to our cleanup of /tmp in /etc/rc > > I think it doesn't. > > Our rm removes links, not files pointed to by links. So: > > cd /tmp > ln -s /etc/passwd thing > rm thing > > will remove the link, not /etc/passwd. > > We are not dependant on find to produce a "valid" list of files, so > that rm does not remove something important. > Besides, our find contains a -type, which also does not find symlinks ( as long as type is not l). Furthermore, the find is commented out by default stating it is not secure. -Guido From owner-freebsd-security Wed May 22 02:26:43 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA05235 for security-outgoing; Wed, 22 May 1996 02:26:43 -0700 (PDT) Received: from nil.fnet.fr (nil.fnet.fr [193.104.112.66]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id CAA05203 for ; Wed, 22 May 1996 02:26:24 -0700 (PDT) Received: from nil.fnet.fr (localhost.fnet.fr [127.0.0.1]) by nil.fnet.fr (8.7.5/8.7.3) with ESMTP id LAA00905; Wed, 22 May 1996 11:24:56 +0100 (METDST) Message-Id: <199605221024.LAA00905@nil.fnet.fr> To: "Rodney W. Grimes" cc: freebsd-security@freebsd.org Subject: Re: [linux-security] Things NOT to put in root's crontab (fwd) In-reply-to: Your message of "Tue, 21 May 1996 23:53:40 METDST." <199605220653.XAA13950@GndRsh.aac.dev.com> X-MAILER: MH 6.8.3 Date: Wed, 22 May 1996 11:24:56 +0100 From: Luc Beurton Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk #> #> On Tue, 21 May 1996, Tom Samplonius wrote: #> #> > #> > On Tue, 21 May 1996, Chris J. Layne wrote: #> > #> > > I think this applies to our cleanup of /tmp in /etc/rc #> > #> > I think it doesn't. #> > #> > Our rm removes links, not files pointed to by links. So: #> > #> > cd /tmp #> > ln -s /etc/passwd thing #> > rm thing #> > #> > will remove the link, not /etc/passwd. #> #> I don't know what I was thinking when I wrote that: #> #> cd /tmp #> ln -s /etc b #> rm b/passwd #> #> will remove /etc/passwd. #> #> However, I don't believe that this method can exploited with #> the standard /etc/rc because we use "rm -rf". I don't find should be #> doing a depth-first traversal in this case. # #/etc/rc is not the problem, /etc/*ly is: #SkyRsh# grep exec /etc/*ly #/etc/daily: find . ! -name . -mtime +7 -exec rm -f -- {} \; ; } # ^^^^^^^^^^^ #/etc/daily: find . ! -name . -mtime +7 -exec rm -f -- {} \; ; } # ^^^^^^^^^^^ #/etc/daily:# -a -atime +3 -exec rm -f -- {} \; # ^^^^^^^^^^^ #/etc/weekly:PATH=/bin:/sbin:/usr/sbin:/usr/bin:/usr/libexec #/etc/weekly:#find /usr/src -name '*.o' -atime +21 -print -a -exec rm -f {} \; # ^^^^^^^^^^^ #/etc/weekly:echo /usr/libexec/locate.updatedb | nice -5 su -m nobody 2>&1 |\ '-exec rm -f' is not a probleme because: only /var/tmp/etc (the symbolic link) will be removed I think ,the real probleme is to use the flags `-r' because rm follow the symbolic link. Luc. #> #> I'll get sleep before I comment more. #> #> Tom #> # # #-- #Rod Grimes rgrimes@gndrsh.aac.dev.com #Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-security Wed May 22 08:22:38 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA03265 for security-outgoing; Wed, 22 May 1996 08:22:38 -0700 (PDT) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA03256 for ; Wed, 22 May 1996 08:22:30 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id IAA14176; Wed, 22 May 1996 08:21:47 -0700 From: "Rodney W. Grimes" Message-Id: <199605221521.IAA14176@GndRsh.aac.dev.com> Subject: Re: [linux-security] Things NOT to put in root's crontab (fwd) To: beurton@fnet.fr (Luc Beurton) Date: Wed, 22 May 1996 08:21:47 -0700 (PDT) Cc: freebsd-security@freebsd.org In-Reply-To: <199605221024.LAA00905@nil.fnet.fr> from Luc Beurton at "May 22, 96 11:24:56 am" X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ... > # > #/etc/rc is not the problem, /etc/*ly is: > #SkyRsh# grep exec /etc/*ly > #/etc/daily: find . ! -name . -mtime +7 -exec rm -f -- {} \; ; } > # ^^^^^^^^^^^ > #/etc/daily: find . ! -name . -mtime +7 -exec rm -f -- {} \; ; } > # ^^^^^^^^^^^ > #/etc/daily:# -a -atime +3 -exec rm -f -- {} \; > # ^^^^^^^^^^^ > #/etc/weekly:PATH=/bin:/sbin:/usr/sbin:/usr/bin:/usr/libexec > #/etc/weekly:#find /usr/src -name '*.o' -atime +21 -print -a -exec rm -f {} \; > # ^^^^^^^^^^^ > #/etc/weekly:echo /usr/libexec/locate.updatedb | nice -5 su -m nobody 2>&1 |\ > > '-exec rm -f' is not a probleme because: > only /var/tmp/etc (the symbolic link) will be removed Read the LONG post very carefully. There is a potential race condition by using a combination attack of LOTS of directories in /tmp with LOTS of symbolic links. If you switch between a dir and link at the right time it will be followed due to delays betweeen the find execution and the exec'ing of rm -f. > > I think ,the real probleme is to use the flags `-r' because rm > follow the symbolic link. rm -r will not follow a symbolic link, any more than find will. You may be able to spoof rm -r with the same type of attach, that I don't know. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-security Wed May 22 08:25:02 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA03455 for security-outgoing; Wed, 22 May 1996 08:25:02 -0700 (PDT) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA03441 for ; Wed, 22 May 1996 08:24:51 -0700 (PDT) Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA07530; Wed, 22 May 1996 11:24:40 -0400 Date: Wed, 22 May 1996 11:24:40 -0400 From: Garrett Wollman Message-Id: <9605221524.AA07530@halloran-eldar.lcs.mit.edu> To: Guido.vanRooij@nl.cis.philips.com (Guido van Rooij) Cc: freebsd-security@FreeBSD.ORG Subject: Re: [linux-security] Things NOT to put in root's crontab (fwd) In-Reply-To: <199605220653.IAA23614@spooky.lss.cp.philips.com> References: <199605220653.IAA23614@spooky.lss.cp.philips.com> Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk < said: >> I think it doesn't. >> >> Our rm removes links, not files pointed to by links. So: >> >> cd /tmp >> ln -s /etc/passwd thing >> rm thing > Besides, our find contains a -type, which also does not find symlinks ( > as long as type is not l). Furthermore, the find is commented out > by default stating it is not secure. Everyone seems to be completely missing the point! The exploit described takes advantage of a race condtion inherent in any sort of `find -exec' operation. To put it simply: Script Attacker 1) create foo/bar/baz 2) execute find on foo 3) locate foo/bar/baz 4) fork 5) move foo/bar to foo/bletch 6) ln -s /etc foo/bar 7) exec rm -f foo/bar/baz oops, /etc/baz is now gone! This is a problem in /etc/*ly, because they run in multiuser mode. It is not a problem for /etc/rc. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-security Wed May 22 13:20:43 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA23406 for security-outgoing; Wed, 22 May 1996 13:20:43 -0700 (PDT) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA23399; Wed, 22 May 1996 13:20:34 -0700 (PDT) Received: from shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.5/8.7.3) with ESMTP id NAA06596; Wed, 22 May 1996 13:20:00 -0700 (PDT) Message-Id: <199605222020.NAA06596@precipice.shockwave.com> To: freebsd-security-announcements@freebsd.org cc: freebsd-announce@freebsd.org, security@freebsd.org From: "FreeBSD Security Officer" Reply-To: security-officer@freebsd.org Subject: FreeBSD security advisory: FreeBSD-SA-96:11 Date: Wed, 22 May 1996 13:20:00 -0700 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= FreeBSD-SA-96:11 Security Advisory Revised: Wed May 22 00:11:46 PDT 1996 FreeBSD, Inc. Topic: security compromise from man page utility Category: core Module: man Announced: 1996-05-21 Affects: FreeBSD 2.0, 2.0.5, 2.1, 2.1-stable, and 2.2-current Corrected: 2.1-stable and 2.2-current as of 1996-05-21 FreeBSD only: yes Patches: ftp://freebsd.org/pub/CERT/patches/SA-96:11/ ============================================================================= I. Background FreeBSD replaced the standard BSD manual page reader with code developed by a third party to support compressed manual pages. A bug was found in the manual page reader which can allow an unprivileged local user to compromise system security in a limited fashion. This problem is present in all source code and binary distributions of FreeBSD version 2.x released before 1996-05-21. II. Problem Description The man program is setuid to the "man" user. By executing a particular sequence of commands, an unprivileged local user may gain the access privileges of the "man" user. However, root access could be obtained with further work. III. Impact The "man" user has no particular special privileges, it is the owner of the /usr/share/man/cat[0-9] directory hierarchy. Unformatted system manual pages are owned by the "bin" user. However, further exploits once "man" is obtained could possibly allow a local user to obtain unlimited access via a trojan horse. This vulnerability can only be exploited by users with a valid account on the local system. IV. Workaround One may simply disable the setuid bit on the /usr/bin/man file. This will disable caching of formatted manual pages, no system functionality will be lost. This workaround will suffice for all versions of FreeBSD affected by this problem. As root, execute the command: # chmod u-s /usr/bin/man then verify that the setuid permissions of the files have been removed. The permissions array should read "-r-xr-xr-x" as shown here: # ls -l /usr/bin/man -r-xr-xr-x 1 man bin 28672 May 19 20:38 /usr/bin/man We also suggest applying the following patch to the source distribution so that the man program will not be installed setuid man should you rebuild from sources: *** /usr/src/gnu/usr.bin/man/man/Makefile Sun Feb 25 13:39:52 1996 --- /usr/src/gnu/usr.bin/man/man/Makefile Wed May 22 00:13:05 1996 *************** *** 1,7 **** PROG= man SRCS= man.c manpath.c glob.c - BINMODE=4555 - BINOWN= man .if exists(${.CURDIR}/../lib/obj) LDADD= -L${.CURDIR}/../lib/obj -lman --- 1,5 ---- V. Solution The FreeBSD team is in the process of rewriting portions of the manual program to avoid this and similar vulnerabilities. This security advisory will be updated when a complete solution is available. ============================================================================= FreeBSD, Inc. Web Site: http://www.freebsd.org/ Confidential contacts: security-officer@freebsd.org PGP Key: ftp://freebsd.org/pub/CERT/public_key.asc Security notifications: security-notifications@freebsd.org Security public discussion: security@freebsd.org Notice: Any patches in this document may not apply cleanly due to modifications caused by digital signature or mailer software. Please reference the URL listed at the top of this document for original copies of all patches if necessary. ============================================================================= -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMaLAllUuHi5z0oilAQFblwP/atY+PmOBakOsKhWywcPu5LvjaAAH5m8B 3KGrtM/CBGEeFvk4qth8aeoTxLfhNtwrsvvnAAKFvqWbdHNU8CnlRgPKbzpyq+cs JB5NAaUYiCI9/87qRajpbjNLxJuDiCOUKcuvU/lgKLvr4oZ86ZVSu5uPieVXaJ8L RVKCjkRnUw8= =IMYL -----END PGP SIGNATURE----- From owner-freebsd-security Thu May 23 04:52:52 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA06183 for security-outgoing; Thu, 23 May 1996 04:52:52 -0700 (PDT) Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id EAA06171; Thu, 23 May 1996 04:52:49 -0700 (PDT) Received: from campa.panke.de (anonymous229.ppp.cs.tu-berlin.de [130.149.17.229]) by mail.cs.tu-berlin.de (8.6.12/8.6.12) with ESMTP id NAA05173; Thu, 23 May 1996 13:30:18 +0200 Received: (from wosch@localhost) by campa.panke.de (8.6.12/8.6.12) id MAA00803; Thu, 23 May 1996 12:27:52 +0200 Date: Thu, 23 May 1996 12:27:52 +0200 From: Wolfram Schneider Message-Id: <199605231027.MAA00803@campa.panke.de> To: security-officer@freebsd.org Cc: security@freebsd.org Subject: FreeBSD security advisory: FreeBSD-SA-96:11 In-Reply-To: <199605222020.NAA06596@precipice.shockwave.com> References: <199605222020.NAA06596@precipice.shockwave.com> Reply-to: Wolfram Schneider MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk How about set *g*id man(1)? $ ls -l /usr/bin/man -r-xr-sr-x 1 man man 28672 May 19 20:38 /usr/bin/man ^ and group man writable /usr/share/man/cat* $ ls -ld /usr/share/man/cat1 drwxrwxr-x 2 man man 7680 Apr 20 21:53 /usr/share/man/cat1 ^ ^^^ Wolfram FreeBSD Security Officer writes: > >-----BEGIN PGP SIGNED MESSAGE----- > >============================================================================= >FreeBSD-SA-96:11 Security Advisory >Revised: Wed May 22 00:11:46 PDT 1996 FreeBSD, Inc. > >Topic: security compromise from man page utility > >Category: core >Module: man >Announced: 1996-05-21 >Affects: FreeBSD 2.0, 2.0.5, 2.1, 2.1-stable, and 2.2-current >Corrected: 2.1-stable and 2.2-current as of 1996-05-21 >FreeBSD only: yes > >Patches: ftp://freebsd.org/pub/CERT/patches/SA-96:11/ > >============================================================================= > >I. Background > > FreeBSD replaced the standard BSD manual page reader with > code developed by a third party to support compressed manual > pages. A bug was found in the manual page reader which can > allow an unprivileged local user to compromise system security > in a limited fashion. This problem is present in all source > code and binary distributions of FreeBSD version 2.x released > before 1996-05-21. > > >II. Problem Description > > The man program is setuid to the "man" user. By executing a > particular sequence of commands, an unprivileged local user > may gain the access privileges of the "man" user. However, > root access could be obtained with further work. > > >III. Impact > > The "man" user has no particular special privileges, it is > the owner of the /usr/share/man/cat[0-9] directory hierarchy. > Unformatted system manual pages are owned by the "bin" user. > However, further exploits once "man" is obtained could > possibly allow a local user to obtain unlimited access via > a trojan horse. > > This vulnerability can only be exploited by users with a valid > account on the local system. [...]