Xref: utzoo news.groups:6241 news.sysadmin:1542
Path: utzoo!attcan!uunet!husc6!mailrus!ncar!tank!mimsy!aplcen!bright
From: bright@aplcen.apl.jhu.edu (Jonathan Bright)
Newsgroups: news.groups,news.sysadmin
Subject: Re: who, me?
Keywords: security, virus, summer job
Message-ID: <257@aplcen.apl.jhu.edu>
Date: 16 Nov 88 17:16:56 GMT
References: <247@aplcen.apl.jhu.edu> <2975@ci.sei.cmu.edu>
Reply-To: bright@aplcen.UUCP (Jonathan Bright)
Organization: Johns Hopkins University/CPP, Laurel, MD
Lines: 37

In article <2975@ci.sei.cmu.edu> pdb@sei.cmu.edu (Patrick Barron) writes:
>You can't necessarily TIOCSTI a terminal if you can write to it.  TIOCSTI
>only works if 1) the terminal in question is your process's control terminal,
>or 2) you're root.
>
>--Pat.

But it is easy enough to change your control terminal to that of the
terminal that you have the file descriptor for, using TIOCNOTTY and
then opening up the terminal in question.

Somebody also wrote that they don't think that this bug works on 4.3,
but it worked on a 4.3 system that I used in the past (whatever the machine
vax1.acs.udel.edu runs, and I'm happy to say that they don't have terminals
writable), and it also works on ULTRIX.

I think that it is dangerous for a process to be able to open up
the file /dev/tty, and have it return a file descriptor for for the
processes control terminal.  Very convenient from a systems programming
standpoint, but still dangerous.

Also, sendmail link bugs still work on both suns and ULTRIX, and I suspect
other machines.  Users must not be allowed to write to the directory 
/usr/spool/mail.  Whenever somebody is given an account root should
create their mail drop in /usr/spool/mail for them.

Jon Bright

P.S. Somebody on the net pointed out to me that 30k was a bit too
little to pay to get somebody good to security hack for you.  They
are of course right.  But to somebody who has never earned more than
$5 an hour, 30k seems like a lot. 
P.P.S. Nobody has yet mailed me offering me a job or anything. 

Disclaimer:  This letter was orginally meant to be sent to /dev/null,
but due to a hardware failure on our system it was accidentally posted 
instead, and this disclaimer was appended to the end.