Path: utzoo!mnetor!uunet!yale!husc6!bu-cs!madd
From: madd@bu-cs.BU.EDU (Jim Frost)
Newsgroups: comp.unix.wizards
Subject: Re: Guide to writing secure setuid programs?
Message-ID: <21104@bu-cs.BU.EDU>
Date: 31 Mar 88 03:10:38 GMT
References: <181@wsccs.UUCP> <722@rivm05.UUCP> <1037@woton.UUCP> <386@vsi.UUCP> <347@wsccs.UUCP> <469@fornax.UUCP>
Reply-To: madd@bu-it.bu.edu (Jim Frost)
Followup-To: comp.unix.wizards
Organization: Boston University Distributed Systems Group
Lines: 61

In article <469@fornax.UUCP> stevec@fornax.UUCP (Steve Cumming) writes:
>In article <347@wsccs.UUCP>, terry@wsccs.UUCP (terry) writes:
>> 
>> 	1) if /usr/spool/mail is writeable and on the same device as /etc:
>> 
>> 		$ ln /etc/passwd /usr/spool/mail/fred
>> 		$ echo "sneak::0:1:A hacker:/:/bin/sh" | mail fred
>> 		$ su fred
>> 		#
>
>I tried this out on a Sun running 3.4. It don't work. 
>Mail is evidently smart enough to check for the existence of 
>the addressee, either locally or through the Yellow Pages.

Don't forget that a Sun uses a slightly different environment than
straight UNIX.  Also, user "fred" should be the person who's trying to
do this.  He'll have an /etc/passwd entry.

>I don't see as it matters whether /etc/passwd and the mail
>directory are on the same file system.

He requires two things -- /usr/spool/mail must be writable (usually it
isn't) so that you can create a file (ie /usr/spool/mail/fred) which
is a hard link to /etc/passwd.  They must be on the same file system
because cross-device hard links aren't possible, which is the second
requirement.

Obviously sendmail must be able to write /etc/passwd for this to work.
For many systems, it may well be able to.  Machines which use the smtp
service (tcp port 25, at least on this system) must have sendmail
running root or they will be unable to access the port (as it's <
1024).

This technique won't work on a lot of systems, but I'd suspect that it
would work on many of the smaller ones (the ones with little disk
space and untrained sysadmins, mostly).  Some flaws in this system
include:

	* some systems use a hash table created by vipw to maintain
	  fast /etc/passwd lookups.  If you try this and the system
	  uses a hash table, you're going to get killed the next time
	  the administrator looks at the passwd file, since it'll have
	  your name in it from the mail header.  You won't be able to
	  su because the hash table won't be updated.  You can't
	  update it because you're not root and can't run vipw.  Too
	  bad.
	* some systems don't use /etc/passwd for the real password
	  file.  Sun yellowpages is an example, although /etc/passwd
	  is used locally to that machine.
	* most systems don't put /etc/passwd and /usr/spool/mail on
	  the same device.
	* most systems don't have a public-writable /usr/spool/mail.

All you'd have to do to defend against this method is make
/usr/spool/mail non-publicly writable, which it should be anyway.

Another example of how "innocent" things like links can be used
against you....

jim frost
madd@bu-it.bu.edu