Date: 17 May 1985 0034-MDT (Friday) Subject: Security Mailing List, # 16 ---------------------------------------------------------------------------- Newcomers to the list since last issue: Ross Greenberg (greenber@timeinc) Howard Weiss (hsw@tycho.arpa) Ron Schnell (ronnie@mit-eddie) Larry Philps (security@utecfa) David M. Watson, Jr. (talcott!sesame!david) Mike Heath (uoksun!mike@uokvax) ---------------------------------------------------------------------------- Date: 9 May 1985 01:14-PDT From: David Bein Subject: Re: security Re: 4.2 tty holes and other obnoxious things -- We suggest that all ioctls be protected as a function of the open modes of the tty. (This includes /dev/tty in a less obvious way since /dev/tty is rw for all on most machines). Our rational is that ALL privileged ioctls should be a function of the open modes of the open which caused the /dev/tty pointer to be produced. This way, if I am able to read a tty, it implies I can do anything to it I want. Doing all things in terms of open modes still allows legitimate use of TIOCSTI by programs whose first fd (opened by init) is opened RW. This prevents noise from using "at" with redirects. (2) TIOCSPGRP is reasonably fixed by 4.3 which we have included. Suggested ioctls which must have a readable descriptor are any which change physical hardware, state bits, and/or flags. Thus, anyone can inquire about the state of a tty, but only readers are allowed to alter its state. Root of course has all privileges for whatever devious purposes. We are running with these restrictions in place and have yet to notice any 4.2 (or 5.0 programs) which break by our restrictions on ioctls. One very important point about suggestions to ban ioctls like TIOCSTI is that these ioctls serve a useful purpose even if the original (4.1) implementations were a bit sloppy. We do not advocate disallowing them other than making them only available to readers. If anyone would like my suggested fixes for /dev/tty, please reply to me (or pyramid!security aliased to our kernel group) and I will send details. For what it is worth OSx has for a long time had no HOLEs via TIOCSTI on a real descriptor. The /dev/tty fixes have recently been implemented and will probably be released by eary summer to all Pyramid sites. We do not feel that fixes of this nature are proprietary. It is clearly in all UNIX implementations interest that HOLEs not exist. Thus we will supply this code without licensing restrictions of any sort. I would post these to generic networks except that I feel that most people are unaware of most of the tty holes and that it will cause more damage than good. --David Bein ---------------------------------------------------------------------------- Date: 13 May 85 22:07:51 +1000 (Mon) Subject: unused SLOGIN bit in proc.h in 4.2bsd From: Robert Elz This list isn't the right place for this, however it was mentioned here ... I "own" the SLOGIN bit in the 4.2bsd proc structure. Its used to mark processes which are direct descendants of init (or the other processes that fork & run login, rlogind, telnetd, etc). This is part of the MUSH stuff implemented at Melbourne, which is vaguely related to security, but much more to resource sharing. SLOGIN allows an accurate count of logins to be kept, allowing limited numbers of logins per user. Its also used to stop sh exec /bin/login otheruser and exec /bin/su otheruser (from a login shell) both of which leave utmp in the "wrong" state. (Yes, there are other fixes, this one is easy, & reliable, given that SLOGIN exists already). Robert Elz seismo!munnari!kre ---------------------------------------------------------------------------- Date: Thu, 16 May 85 15:51:16 edt From: Arnold Robbins Subject: Security fixes for the shell Lyle, I am on the lab staff here at the ICS school of Georgia Tech, and have been reading your security list through my office mate, Jeff Lee. I am getting ready to post some major mods to the Bourne shell to mod.sources, and have initially included the fix to reset the uid and gid if the shell thinks it is a login shell and the effective and real id's are not the same, before reading the /etc/profile and .profile. My question is, is it a good idea to post these changes? Or is it possible that people will figure out from them what the existing hole is, and start using it on the unprotected shells? I have also added a section about this to the man page, but left it in comments, so it doesn't get nroff'ed. I have considered just putting in a comment in the code to the effect that if I get mail from root, I will send the fixes back. Whatever advice you have to offer will be appreciated. I hope to be ready to post by next Tuesday or so, so I would appreciate an answer as soon as is reasonable. Thanks, Arnold Robbins CSNET: arnold@gatech ARPA: arnold%gatech.csnet@csnet-relay.arpa UUCP: { akgua, allegra, hplabs, ihnp4, seismo, ut-sally }!gatech!arnold ---------------------------------------------------------------------------- Subject: Re: Security fixes for the shell Date: 16 May 85 23:27:52 MST (Thu) From: denelvx!lmc In my humble opinion, I would go ahead and post 'em. You needn't call attention to the security problems, and I can go ahead and post your message to the mail list. That should, I think, cover most of the bases. In fact, I'll post both your letter and my response, inviting anyone with problems with that arrangement to write to you directly (with a carbon to denelcor!security). You might wait until later next week, to allow this to filter out and responses to come back. Lyle ---------------------------------------------------------------------------- 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).