Possible security problem, need information...

John Chambers jc at minya.UUCP
Tue Mar 26 15:09:47 AEST 1991


In article <9385 at star.cs.vu.nl>, henk at cs.vu.nl (Henk Smit) writes:
> The "t" (sticky bit) on directories means that you must not only have write
> permission on the directory, but also be the owner of the file (or directory)
> that you want to (re)move.
> ...
> 		How strange it seems, I can't see an obvious security
> gap in "drwxrwxrwt" on /.

Some time back, when I had a security related job (and eventually got
fired for "breaking into" some of the computers on which they game me
test accounts ;-), I found a root directory like this.  I noticed that
there was no /.profile, so I graciously provided one.  Then I sat back
and waited for root to run a Bourne-shell script.  It didn't take long.
One of the commands I included was:
	echo "Gotcha!" | mail root
This caused some consternation, since of course it came from "root".

There seem to be some shells around now that only read their .profile
(or .login or .whatever) if it is owned by their real or effective user.
This would have blocked my ruse, since of course /.profile was owned by
my id, not root.  But this is a sophistication that probably hasn't yet
reached many vendors' shells.

In general, there is a potential problem with missing files which may
be created by users who understand how an application uses them.  This
can get subtle.  For instance, many versions of Ingres look for files
in the root directory (as well as in several other directories).  You
can have fun with your database users by creating these files for them
if they don't exist.  It's especially amusing to create them before the
package is installed, with yourself as owner.  When the package's users
complain about your file messing up their package, you complain right
back that you had the filename first, and they are just trying to harass 
you by coming along later and demanding that you change your filename 
because they want the name.  Of course, they don't have the source to 
the package, and they can't change its behavior, so...

-- 
All opinions Copyright (c) 1991 by John Chambers.  Inquire for licensing at:
Home: 1-617-484-6393 
Work: 1-508-486-5475
Uucp: ...!{bu.edu,harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc 



More information about the Comp.unix.admin mailing list