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' #13 1985-04-13 (1 file, 3557 bytes)
NOTICE: recognises the rights of all third-party works.


Date: 13 Apr 1985 2031-MST (Saturday)
Subject: Security Mailing List, # 13


Newcomers to the list since last issue:
        Angel Casado (adrvax!angel@ihnp4)
        George (geo@brl-bmd)
        Howard (howard@brl-bmd)
        Karl A. Nyberg (karl@vrdxhq)
        Seth Zirin (megad!seth@sbcs)
        Mark Smith (mjs@uvacs)
        Gene Lege (ots!gene@rice)
        Marty Schoff (schoff@cadtroy)
        John McDermott (secure@unmvax)
        Sid Shapiro (ss@wanginst)
        Doug Tygar (tygar@harvard)


Date: Wed, 27 Mar 85 14:30:36 mst
From: boulder!andy (Andrew M. Rudoff)
Subject: Annoying Anomalies

Here is a strangeness I have found with /bin/csh.  This probably is not
a "security problem", but it falls into the same catagory as the script

        while 1
                mkdir x
                cd x

before quotas.  Back when we were running 4.1, we had a "free" account
which we had to remove because someone would always pull a stunt like
the above script.  True, it doesn't give one "root", but it caused a
great deal of grief when the file system filled up.  Now, under 4.2, I
found another such annoying thing:

first, notice that when you type

        eval \!!

to csh, you get an infinite loop echoing "eval !!" to your screen.  Now
take that command and pipe it to "logout":

        eval \!! | logout

What happens is the shell forks four or five subshells (executing the
same commands!?!) and then logs out.  You very quickly get a load
average of about 30, and you cannot kill the shells because they do not
stick around long enough!  There is no parent to kill; it logged out
first!  When I first tried it, we had to reboot the machine.  We then
tried it on a Pyramid which could handle the load a lot better than a
VAX, and found a way to stop it:

Since every time the shell "logs out" it executes ~/.logout, just put
something like "sleep 10000" in the .logout file, wait a few minutes,
do a "ps x", and kill all of the processes doing "sleep 10000".
Incidently, when you give the "eval..." command, you are logged out
right away (so if you must test this, log back on SOON and fix up the
.logout file). On the average VAX 11/780, it takes 5-10 minutes for the
machine to become useless.

There are a bunch of other strange things I have found with the csh, but
they are definitely not security problems.  Interested people can send me

Here is a strangeness I found with /bin/login.  It requires that you know
the passwd to some other login.  We have plenty of logins with no passwd
(who, sync, etc.) and it took me one guess to figure out the passwd for
uucp.  I will use uucp in my example:

 % sh                   # get into a subshell
 $ login uucp           # (use /bin/login)
 Password:              # guess!
 Shere                  # this is uucp saying "hello".  wait for timeout.
                        # if I did this with "who", I would just wait until
                        # the "who" finished.
 % whoami               # back to original shell
 andy                   # with original UID
 % who am i             # but look at the utmp entry (could use "u", or "who")
 boulder!uucp     ttyd0   Mar 27 13:09

Now I can send mail from "uucp", hide from question askers (it doesn't
look like "andy" is logged in anymore)...  I tried to use this against
sendmail (uucp is a "trusted user") but I couldn't get anything interesting
to happen.


Andrew M. Rudoff                        (andy@boulder)
University of Colorado at Boulder

  {ucbvax!hplabs | allegra!nbires | decvax!kpno | harpo!seismo | ihnp4!kpno}


Date: 12 Apr 85 10:26:28 EST (Fri)
From: Craig Partridge <loki!hao!seismo!craig>
Subject: big 4.2 vm bug

        Here is a major 4.2 security hole we've now learned about from
three different sources.  It is particularly nasty since it doesn't
require anything more than a knowledge of adb to exercise, and we have
yet to get a satisfactory fix.  My apologies to some people who have asked
I not talk about this bug -- in quietly trying to find the fix, I have
concluded that the bug is becoming known to more than just system
administrators, and we need a proper fix.

    THE PROBLEM:  The 4.2 virtual memory code allows you to share code
even if the code has been altered by ptrace.  (This bug appears in standard
4.2, and ULTRIX.  It may exist on SUNs, I haven't had a chance to check.
It is fixed in 4.3).  A good way to illustrate the bug is:

% adb su

/* change the code to ignore the password check */

% su
Password: /* type anything */

    WHY IT HAPPENS:  Apparently the ITEXT bit which is turned off when a
text page is muddied isn't checked properly.  But there is more to
it than that.  We put in code in xalloc() to refuse to share
pages in which the ITEXT bit is turned off and it fixed the problem
but caused a bad race condition.  There is a second bug that has to
be fixed to make this fix work, and none of the wizards here has been
able to find the time to trace it.

    THE FIX:  We ain't got it.  The best we've seen is the one from
dave@riacs, and it is appended below.  But it forces you to be the
owner of a binary to debug it -- a restriction we weren't happy with.
People at Berkeley have suggested they have a correct fix, but never
responded to requests to send it to us.  If anyone has the "proper"
fix, could you please distribute it?


Craig Partridge
craig@bbn-loki (ARPA)
craig%loki@csnet-relay (CSNET)
{bbncca,ihnp4,wjh12}!bbncca!craig (USENET)

Below is he context diffs for a two line
fix which eliminates this hole.  As is typical, the line numbers will
probably be off, but with the context, you should be able to repair the
flaw.  I added a little to the front of the old versions context to aid
in the fixing.  This is to be found in procxmt(), in

*** 136,146

        /* 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 (xp->x_count!=1 || xp->x_iptr->i_mode&ISVTX)
                                goto error;
                        xp->x_iptr->i_flag &= ~ITEXT;

--- 141,148 -----
                 * 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;



Subject: a couple of questions
Date: 13 Apr 85 09:15:30 MST (Sat)
From: denelvx!lmc

As long as everything is so quiet, I though I might ask a few questions:

        Are there any known security problems with honey-danber?

        Suppose I were running 4.2 fixed according to the articles that
                we have already seen here, with honey-danber and the
                new message handler (5); how secure is mail on such a
                system? Any better than before? Or is the primary problem
                with mail the ability to get superuser status itself?



                    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).