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 (decuac!avolio@decvax) David L. Parnas (denelcor!hao!seismo!nrl-css.arpa!vax-populi!security) Daniel Flickinger (flkvax!flick@trwrb) Rocke Verser (rcv@hplvla) Rick Hester (rick@hplvla) Steve Bellovin (smb@kalypso) Charlie Perkins (v1!charliep@philabs) ---------------------------------------------------------------------------- Date: Mon, 22 Apr 85 16:59:05 pst From: John Bruner 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 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 mab@riacs.arpa ...!ihnp4!ames!riacs!mab ...!decvax!decwrl!riacs!mab ---------------------------------------------------------------------------- Date: Thu, 25 Apr 85 18:47:29 EST From: Ron Natalie 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. -Ron ---------------------------------------------------------------------------- Date: Thu, 25 Apr 85 18:49:24 EST From: Ron Natalie 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. -Ron ---------------------------------------------------------------------------- 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 alternative. 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. chuq ---------------------------------------------------------------------------- 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 suspect. 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 fair@ucb-arpa.ARPA dual!fair@BERKELEY.ARPA {ihnp4,ucbvax,cbosgd,hplabs,decwrl,unisoft,fortune,sun,nsc}!dual!fair Dual Systems Corporation, Berkeley, California ---------------------------------------------------------------------------- Date: Sun, 28 Apr 85 17:30:37 cdt From: John B. Chambers 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) CSC-STD-001-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 chambers@mcc.arpa, jbc@ut-sally.arpa, ihnp4!ut-sally!mcc-db!jbc ---------------------------------------------------------------------------- From: denelcor!brl!mike@brl.arpa Date: Mon, 29 Apr 85 20:54:19 EST Original-From: Mike Muuss 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. -Mike ---------------------------------------------------------------------------- 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).