The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: Unix 'Security Mailing List' - Archives (1984 - 1987)
DOCUMENT: Unix 'Security Mailing List' #15 1985-05-05 (1 file, 7279 bytes)
NOTICE: recognises the rights of all third-party works.


Date:  5 May 1985 1042-MDT (Sunday)
Subject: Security Mailing List, # 15


Editor's corner

        Again, #12 is a null content issue of this list.

Newcomers to the list since last issue:
        Fred Avolio ([email protected])
        David L. Parnas (denelcor!hao!seismo!!vax-populi!security)
        Daniel Flickinger ([email protected])
        Rocke Verser ([email protected])
        Rick Hester ([email protected])
        Steve Bellovin ([email protected])
        Charlie Perkins ([email protected]abs)


Date: Mon, 22 Apr 85 16:59:05 pst
From: John Bruner <ihnp4!dual!mordor!jdb>
Subject: TIOCSTI

[I'm new to this list.  I've scanned the archives and I don't see
any direct discussion of this issue, but I'll trust the moderator
to delete this letter if I'm rehashing old material.]

[It has, but what the hell.  --ed]

The TIOCSTI ioctl (a.k.a. the "force" command) is one of the worst
security holes in 4.XBSD.  As far as I can tell, it was implemented
so that the "To:", "Subject:", "Cc:", etc. lines in Berkeley Mail
could be input-edited by the kernel.

TIOCSTI places a specified character on the input clist of a
terminal, effectively making that character appear as if it were
typed on the terminal.  Thus, the kernel provides the insecurity
of a terminal with an "answer-back" or "block transfer" mode.

TIOCSTI requires that the invoking process run as root or that the
terminal on which the input is to be placed be the controlling
terminal.  Alas, these restrictions are hopelessly inadequate.  If
the terminal is writeable, any user can place characters on its
input clist.  In many places, users will leave their terminals
logged in overnight.  In some places, console terminals will be
left logged in as "root" indefinitely.  If these terminals are
writeable, anyone can effectively type commands on them.

If a process has no controlling terminal, the first terminal that
it successfully opens will become its controlling terminal.  A process
may clear its controlling terminal in 4.2BSD by using the TIOCNOTTY
ioctl.  If TIOCNOTTY (or setpgrp) is not available, any user may
obtain a process without a controlling terminal by running it via
"at".  By using one of these mechanisms and then opening the desired
terminal for write-only, an ordinary user may create a process which
has any writeable terminal as its controlling terminal and thereafter
send input to it using TIOCSTI.

If terminals are made non-writeable by default, a malicious user
can still leave a "time bomb" running.  "/dev/tty" can be held open
across a logout/vhangup, so the malicious user can write a program
which ignores SIGTTOU, SIGTTIN, SIGHUP, traps some specified signal,
and then pause()s.  The malicious user then logs out and a victim
logs in.  The malicious user waits for an appropriate time and
sends a signal to his/her sleeping process.  The process wakes
up, does its foul deed, and goes away.  (A clever abuser can disguise
this time bomb as a long-running program or even hide it inside a
legitimate program to make it harder to detect.)

I recommend getting rid of TIOCSTI entirely, except perhaps for
the super-user.  The input-editing problem in "Mail" should be
solved at the user level rather than at the kernel level.

A less radical fix would be to implement a "detached" bit (4.2BSD
has a SLOGIN process flag defined, but I can't find any use of it).
A process which issued a TIOCNOTTY ioctl or whose parent had died
would be flagged as "detached".  This bit would be inherited by
children during a fork().  Detached processes would not be
permitted to use TIOCSTI.  This would close the holes I mentioned
above.  Unfortunately, one problem that it would cause would
be the inability to use TIOCSTI on "rlogin" or "telnet" connections,
since the servers for these are started from "/etc/rc".  (I suppose
one solution to this would be to allow the super-user to clear the
"detached" bit.)


Date: Thu, 25 Apr 85 11:30:08 pst
From: Matt Bishop <hydra!hao!riacs!mab>
Subject: 4bsd-bugs fix of big 4.2 vm bug -- BOGUS!!!

   This is in response to allegra!mp's posting that gave the 4bsd-bugs
collection fix of the ptrace bug ("a.k.a. "big 4.2 vm bug" on this list.)

   DO NOT INSTALL THAT FIX!!!!!!  We did, and it worked beautifully for a
couple of months, then took out a VAX780.  Nothing irreparable, but it defin-
itely does create a race condition.  (Don't ask me why; I haven't gone into
the code yet to track it down.  If I'm lucky, someone else will!)  At any
rate, I strongly recommend using this one (from George Gobel at Purdue).

   This fix prevents adb (or anything that uses ptrace) from writing into a
process' space unless the UID of the traced process and the uid of the
tracing process are the same.  Add the following test to procxmt() in
sys/sys_process.c (around lines 137 - 149; the new lines have `+' in the
left margin):

        /* write user I */
        /* Must set up to allow writing */
        case 4:
                 * If text, must assure exclusive use
                if (xp = u.u_procp->p_textp) {
 +                      if (u.u_uid && xp -> x_iptr -> i_uid != u.u_uid) 
 +                              goto error;
                        if (xp->x_count!=1 || xp->x_iptr->i_mode&ISVTX)
                                goto error;
                        xp->x_iptr->i_flag &= ~ITEXT;

   I have a 4-page writeup of this little goodie that I'll be glad to send to
anyone who is on Lyle's list; just let me know.

   One more (administrative) note:  hydra is an internal RIACS name, no machine
other than our gateway knows about it, so ignore the return address above,
and use one of the ones below.

   Matt Bishop
   Research Institute for Advanced Computer Science
   NASA Ames Research Center
   Moffett Field, CA  94035

   [email protected]  ...!ihnp4!ames!riacs!mab  ...!decvax!decwrl!riacs!mab


Date:     Thu, 25 Apr 85 18:47:29 EST
From: Ron Natalie <[email protected]>
Subject:  Re:  Douglas Robinson's Security Breach #2 made more vicious

The latest version of the Berkeley code has much more restrictive access on
controlling terminals.



Date:     Thu, 25 Apr 85 18:49:24 EST
From: Ron Natalie <[email protected]>
Subject:  Re:  Secure UN*X O/S

GOULD claims to be working on making their 4.2 secure.  Seeing the current
level of their operating system robustness, they've got a long way to go
before they even start to address the "SECURITY" in the defense sense of
the word.



Date: Thu, 25 Apr 85 12:02:32 pst
From: allegra!nsc!chuqui (Chuq Von Rospach)
Subject: faking news

Any attempt at making news secure is a joke. If you are worried about it,
all you can do is turn off news, which isn't what I would call a useful

You can improve the security by doing what was suggested on USER and
ORGANIZATION, but you should also seriously consider removing the '-f'
option of inews as well, since this allows you to toss out a forged address
and remove your account name completely from the header. This was how the
now infamous 'moscvax' message of two April firsts ago was generated at
mcvax. By tightening those, you can take care of a good percentage of the
obvious security holes in news.

News is, however, still wide open. I point your way to two messages posted
on April 1 of this year. One was reportedly from me (and wasn't, by the way)
and generated a rmgroup of net.general. The other was a LOT more subtle, and
WAS by me, from wobegon!prarie (through stonehenge, nsacray, moscvax and
kremcyber). What is MOST interesting about both is that nowhere in the 
header is any information that can be used to track down the sender. None.
Zero. Zilch. The first moscvax message had the senders site (mcvax) in it,
but there is a better way of forging message.

Grab a message out of /usr/spool/news, put it somewhere. Edit
the message, and change all of the headers to say what you want. Be
inventive. Be outrageous. Be dangerous! Be sure you pull out ALL references
to your site from the Posting-version, Relay-version, Path, From, and 
organization lines. When it is ready, run the thing through uux and have
uux spawn rnews on some other site that you talk to. 

That's it. 5 minutes work, an untraceable message. The problem is that
rnews/inews on the other side assumes that all of the information it got
is correct. It doesn't/can't verify from uux that the site that it got
this message from is the site that the headers say it came from. Once it
gets on that site, all trace of where it came from is gone unless you want
to manually crosscheck the uucp LOGFILE times with the usenet logs and find
out who was REALLY executing the uux. This, of course, has to be done by
hand, and assumes you find the message before you flush the logs. Most
sites, also, aren't picky about who they talk to so a REALLY motivated
individual could change the hostname of his site to something like
'moscvax' before calling ihnp4 to dump off the message. Or change it to
allegra, or cbosgd, or nsc, even. Nobody is safe, and I've looked at this 
and I simply don't see a solution at this point. 

This brings up LOTS of interesting points. It is impossible to verify
the author of ANY message. Someone with a bone to pick could set up his
hostname to 'nsc' and dump the system V source to net.sources in my name.
Someone could set his hostname to 'gatech' and post rmgroups to the entire
net is spaffords name. The possibility for harrasement or damage is high
here, and the best we could EVER get against someone would be
circumstantial evidence. 

I'd love to find a fix for this hole. I've been burnt by it once, and I
don't think it'll go away by being quiet. I don't want to overpublicize it,
though, because it is one of those things that all the immature people in
the world (myself included, of course) would have to use, at least once, to
post something silly. And some of those could be very destructive.



Date: Sat, 27 Apr 85 16:07:37 pst
From: ihnp4!dual!fair (Erik E. Fair)
Subject: Re:  Security Mailing List, # 14 (user authentication in netnews)

This is in response to Robert LoVerso's concern about users posting
faked user names in netnews. I hate to be the one to disabuse you of
the notion that the mail and netnews systems we use daily to
communicate are in any way, shape, or form secure, but that's the
reality of the situation and I very specifically include the ARPA
INTERNET, that grand network built by the U.S. Department of Defense.

Netnews can be faked by taking an existing article on a system,
hacking it up with your favorite editor, and performing the required
uux to get it to the next USENET neighbor down the line. No need to
bother the netnews software at all, except to look at the sys file
for the proper transmission method to use to get to the next site.

Mail in bangland can be similarly faked, without getting anywhere near
the mailer program. You just have to know what the mail intermediate
formats look like.

Mail in internet land is easily faked by hacking up a proper RFC822
header to appear to come from the user you like, and then contacting
the SMTP server on the destination site, and type the proper
incantations (documented in RFC821). The main problem with faking
things on the internet is that a remote host can check your machine
address against the list of such addresses and names it keeps for the
entire internet (maintained and distributed by the Network Information
Center), and gain the correct name for your host.  However, this is
only a problem if you assume that the remote mailer will do something
with this information (e.g. add it to the header somewhere) and that
the person you are trying to fake is not on YOUR host.

There is a project going on (and an RFC has been issued) for an
internet user authentication service, but it has the same fundamental
problems of any network: who do you trust and how much do you trust
them?  In both UUCP and TCP/IP, the communication channel is itself
available to any user on an unauthenticaed basis, and therefore the
content of any message received from any remote host must be considered

Of course, the same can be said for the U.S. Postal Service, so this
situation is not without precedent. Consider: the only trace
information that you get with snail mail is a postmark which supposedly
indicates point of origin, and that can probably be faked without too
much trouble if someone was desperate enough.  It seems however, that
people live with this state of affairs without going paranoid...

        hope this doesn't cause too much insomnia,

        Erik E. Fair    ucbvax!fair     [email protected]

        [email protected]
        Dual Systems Corporation, Berkeley, California


Date: Sun, 28 Apr 85 17:30:37 cdt
From: John B. Chambers <ihnp4!ut-sally!mcc-db!jbc>
Subject: ioctl problems

Two comments.

1. Persons interested in evaluating, redesigning or enhancing the security 
   of any O/S will want to consult, among other documents, 

        DoD Trusted Computer System Evaluation Criteria (15-AUG-83)
        Library # S225,711

   available from

        DoD Computer Security Center
        9800 Savage Road
        Fort George G. Meade, MD  20755

   They also have a newsletter but I've lost the info at present.

2. I rambled briefly on the net a year ago on the subject of TIOCSTI,
   stty 0 > /dev/ttyxx, and such like. Must be time to plague a
   different audience. :-)

   I view these "holes" as symptomatic of a basic design problem. I
   claim that I/O on a device is conceptually very different from
   changing the "state" ("operating characteristics") of the device
   itself and that the two operations should be orthogonal. The fact
   that I can get a file descriptor on a device because I can read() 
   or write() it should not imply that I can ioctl() it.

   Why not, say, use the execute bits to determine ioctlability on a
   device special file? [Socket behavior should be interesting to
   define.] One might (say) check IEXEC access at copen() time for IFCHR
   or IFBLK, tinker up the file struct, and have the ioctl look at that,
   something of the sort. Or even add an explicit FIOCTL flag for
   open() [necessitating adding |FIOCTL to a lot of existing open()
   calls ... sigh.]

   This seems less ugly to me than, say, protecting terminals and making
   talk and write setuid. And programs like biff which use the execute
   bits as "dirty bits" deserve to break anyway. [Why not ~/.biff? :-)]

John B. Chambers, MCC, Austin, TX
[email protected], [email protected], ihnp4!ut-sally!mcc-db!jbc


From: [email protected]
Date:     Mon, 29 Apr 85 20:54:19 EST
Original-From:     Mike Muuss <[email protected]>
Subject:  Secure UNIX

I just heard a briefing about a Gould project to create a "secure"
version of 4.2 UNIX for their hardware.

Their claim is that they should be able to reach B1 or B2 security
3Q85, with the hopes that they will have NSA accreditation sometime
after 3Q86.  They intend to follow on to A1, with appropriate
changed to their processors.

For more information, contact a Gould salesman.


                    The UNIX security issues mail list

               Ignore the headers on this list and mail to:
           ...denelcor!security            (mail for the list).
            ...denelcor!sec-request         (administrativia).