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

START OF DOCUMENT


Date: 24 Apr 85 00:38:51 MST (Wed)
Subject: Security Mailing List, # 14

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

Editor's corner

        Once again we dropped an issue; # 12 is null and void. Sorry to
        one and all.

Newcomers to the list since last issue:
        Cameron Carson (bu-cs!ccc@harvard)
        Robert Bond (nsc-pdc!rgb@nsc)
        Steve Kroon (nsc-pdc!root@nsc)
        Michael M. Rubenstein (root@utmbvax)
        Jeff Gillian (root@voder)
        ??????? (root@wanginst)
        Tim Rosmus (sys-secure@tikal)
        Tim Tjarks (tjarks@ihlts)

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

Date: Mon, 15 Apr 85 09:33:07 pst
From: Matt Bishop <hydra!hao!riacs!mab>
Subject: Douglas Robinson's Security Breach #2 made more vicious

   This is a "modification" to one of Douglas Robinson's security holes
that makes it even more dangerous (if you can believe it ...)

   The security hole, in brief, is this:  If a process has no controlling
tty, the first tty it opens becomes the controlling tty.  So, write a
program that opens a named tty, and uses the TIOCSTI ioctl to stuff
characters into the controlling terminal's input queue.  The system thinks
those characters were typed by the person logged in at that terminal.  If
it happens to be root, well, things can be made very interesting ... (See
newsletter #4, "Security Breach Made Easy #2 (Anomaly #12)" for a fuller
exposition.)

   To dissociate the process from its controlling tty, Douglas suggests
running this program from "at"; since "at" is started up by "cron", which
has no controlling tty, it also runs without any controlling tty, so any
jobs "at" runs also has no controlling tty.  While this will work if root
(or whoever the victim is) stays logged in, you have to wait up to the
granularity of the system "cron" before your command gets executed.  If
the victim logs off within that interval, the breach fails.

   I'd recommend using the TIOCNOTTY ioctl instead.  This ioctl is
SPECIFICALLY provided to disconnect a process from a controlling tty.
(It's used by init when getty jobs are fired up.) So, write a program that
uses this ioctl to disconnedt "/dev/tty", then open the victim's terminal
for writing.  Presto!  You can now have the system execute commands as
though your victim had typed them ...

   As far as fixes go, does anyone know why TIOCSTI was put in?  It looks
like an attempt to implement a pushback scheme, but surely it's better to
let the programmer worry about that, I searched all out 4.2 sources and
only found a couple of programs which used it -- Berkeley Mail was the
only one where it was used more than once.  Would anything break beyond
repair if this particular ioctl were deleted?

   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: Mon, 15 Apr 85 22:20:36 mst
From: allegra!mp
Subject: Re: big 4.2 vm bug

The way we got around that bug here was to recompile programs with -N,
so that they're non-sharable.  We couldn't afford to do this to uucp
and sendmail, though, because allegra's only a 2-meg machine.

Here's something from the 4bsd-bugs collection.  There's some concern here
that it has a race condition like the one Craig described.
I wonder if this is the fix that's included in 4.3...
        Mark

Date: Wed, 6 Feb 85 15:36:28 pst
>From: root@ucbopal.CC (Charlie Root)
Subject: Sharing of non-text segments
Index:  /usr/sys/sys/vm_text.c 4.2BSD

Description:
        xalloc allows shared "text" on segments that are not tagged as text
        segments. This (minimally) creates a security hole.
Repeat-By:
        Copy your favorite shell into your current directory under the
        name "x". Run "adb -w /bin/nm", :s the resulting process until
        adb reports that it is running. Now feed adb the following line:

                0?W 8fdd0000 1b 0defdd 2fb0000 0ef 0bc000000 1900780b 0 0

        (this is a short program to execl x). ^Z out of adb, and run
        /bin/nm. Note that you are now running a the shell copied into x.
Fix:
        Convince xalloc that it shouldn't use non-text segments as shared
        text. To fix the above behavior, ptrace could be modified to tag
        the written-on segment in some other way.  Both fixes might be
        appropriate.  The fix to xalloc looks like so:

*** vm_text.co  Wed Feb  6 15:19:45 1985
--- vm_text.c   Wed Feb  6 11:09:40 1985
***************
*** 75,80
                                xp1 = xp;
                        continue;
                }
                if ((xp->x_count > 0 || (xp->x_iptr->i_mode&ISVTX)) && xp->x_iptr == ip) {
                        if (xp->x_flag&XLOCK) {
                                xwait(xp);

--- 75,83 -----
                                xp1 = xp;
                        continue;
                }
+               /* If this isn't a text segment, we can't share it */
+               if ((xp->x_iptr->i_flag&ITEXT)==0)
+                       continue;
                if ((xp->x_count > 0 || (xp->x_iptr->i_mode&ISVTX)) && xp->x_iptr == ip) {
                        if (xp->x_flag&XLOCK) {
                                xwait(xp);

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

Date: Thu, 18 Apr 85 10:07:29 est
From: hao!seismo!decuac!mogwai!paul (Paul H. Mauritz)
Subject: Secure UN*X O/S

A new bunch of bytes to mull over...
        
Any ideas as to what work is going on in the field of secure operating
systems in the UN*X world.  I'd like some discussion on just what needs 
to be done to make a UN*X secure, and what - if any - work is being/has
been done in this area.  
        
Paul H. Mauritz - Digital Equipment Corporation

UUCP:   decvax!{decuac,grendel}!paul
ARPA:   {decuac,grendel}!paul@seismo.ARPA
AT&T:   (301) 474-4091
USPS:   8301 Professional Place, Landover MD USA EARTH 20785, MS-DCO/913


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

Date: Sat, 20 Apr 85 21:16:03 est
From: ihnp4!watmath!sunybcs!loverso (JOhn Robert LoVerso)
Subject: Posting `faked' news

Most people know that news uses the environment values of NAME and
ORGANIZATION when posting articles (sendmail also reads NAME).  These can
sometimes be useful.  However, inews will also use the value of USER as a
substitution for the real username; this allows any user to fake news
articles.  I didn't care too much about this until a few articles were
locally posted with false usernames.  I don't know the justification of
putting this `feature' into the distributed copy.  However, I did find
code to disable it; by defining IHCC you get a set of changes run at BTL.
All the "fix" I've listed here does is to change the #IFDEF parameter to
the local hostname.

By the way, this just prevents users at your site from generating such news;
it doesn't prevent you from receiving faked news from other sites.

I can only vouch for 4.2 sendmail and news vers B 2.10.2 (ours is from
9/5/84).

        -John

*** inews.c     Sat Apr 20 15:19:29 1985
--- inews.orig  Mon Apr  1 00:55:41 1985
***************
*** 146,152
                setuid(duid);
        }
  
! #ifndef SUNYAB
        /*
         * We force the use of 'getuser()' to prevent forgery of articles
         * by just changing $LOGNAME

--- 146,152 -----
                setuid(duid);
        }
  
! #ifndef IHCC
        /*
         * We force the use of 'getuser()' to prevent forgery of articles
         * by just changing $LOGNAME

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

                    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