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' #16 1985-05-17 (1 file, 2841 bytes)
SOURCE: http://securitydigest.org/exec/display?f=unix/archive/016.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT


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 <hao!seismo!allegra!pyramid!pyrps5.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 <ihnp4!seismo!munnari!kre>

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 <ihnp4!gatech!arnold>
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).

END OF DOCUMENT