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

START OF DOCUMENT


Date: 26 Jul 85 18:00:52 MST (Fri)
Subject: Security Mailing List, # 18

----------------------------------------------------------------------------

Newcomers to the list since last issue:
        Eric McRae (amc!eric@tikal)
        Roger Long (bytebug@pertec)
        David Parter (david@wivax)
        Joe Buck (epicen!security@dual)
        Bill Stewart (ho95c!wcs@ihnp4)
        Doug Hosking (hosking@convex)
        Pierre-Alain Michel (hpbbse!pam@hpfcla)
        Dave Fiedler (infopro!dave@harpo)
        Jyrki Yli-Nokari (jty@tut)
        Robin Cutshaw (medstar!robin@gatech)
        Donn S. Fishbein (neurad!donn@seismo)
        Ron Saad (ron1!ron@cmcl2)
        Jon Eichelberger (root@nadc.arpa)
        Dave Benco (root@riccb)
        Ian F. Darwin (root@utcs)
        Wade Stebbings (rosevax!wade@ihnp4)
        Tom Christiansen (tom@uwvax)
        Doug Orr (umich!textset!doug@ihnp4)
        Clyde Hoover (unix-security@ut-ngp)
        Peter Wolfe (winston!wolfe@ubc-vision)
        Peter Yee (yee@ucbvax)

----------------------------------------------------------------------------

Date: Thu, 13 Jun 85 09:36:25 -0200
From: hao!seismo!mcvax!enea!tut!root (Operator)
Subject: UNIX* security

Dear Lyle

The Finnish Unix Users Group (FUUG) has decided to collect
known problems and share them with system adminstrators.

 We are most interested in problems you know.
 Can you share them with us?

Personally, I think I know only the `ordinary' problems
(Mostly being *very* careful with setuid root things)
Also we encountered one with rogue(6) which was setuid root.
If you save your game to `/etc/passwd', rogue(6) is more than happy
to do that and even chowns the damn file to you!

...mcvax!tut!jty

Jyrki Yli-Nokari
N 61 26' E 23 50'
+358 31 162590, home +358 31 178833

----------------------------------------------------------------------------

Date: Thu, 18 Jul 85 20:51:26 mdt
From: Tom Truscott <hao!MCNC!hplabs!rti-sel!trt>
Subject: Security and Pseudo-Ttys

        Are pseudo-ttys a security hole?
In 4.2 BSD, to snag a pty one opens the master side (e.g. /dev/ttyp0).
The master side of ptys are guaranteed mutually exclusive access,
so even though they are mode 666 there is no security problem.
Then the program opens the slave side (e.g. /dev/ptyp0),
which is conventionally owned by root mode 666,
and a forked child dups the slave descriptors into (0,1,2)
and execs a shell (or whatever).
One nuisance is that rlogin chowns the slave ptys to the uid logging in,
mode 622, so a crash leaves that slave pty unusable by others.
(The fix, which is to chmod the ptys in /etc/rc, was mentioned on Usenet.)
In other words, we want idle slave ptys to be mode 666.
Slave pty access protection is, of course, exactly that of normal ttys.

In other words, by convention SLAVE PTYS ARE SECURITY HOLES!
Here is an example:
        user A types 'script' and types 'tty' to get his pty # (e.g. ttyp0).
        user A types 'sleep 60'
        user B types `cat -u /dev/ttyp0' (or whatever pty A got).
        user A types a line of input
        .... It appears on B's terminal!! ...

What can be done about this?
Well, when the master side is opened the kernel could
chown the slave pty to the program's effective uid/gid,
chmod it to 0600, and 'vhangup' anything currently connected.
That starts the pty off in a safe state, and the program can
then do as it pleases.
It's a hack but not all that horrible
as it makes unnecessary the chown/chmod hacks to rlogin and /etc/rc.
        Tom Truscott

----------------------------------------------------------------------------

                    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