The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: Zardoz 'Security Digest' - Archives (1989 - 1991)
DOCUMENT: Zardoz 'Security Digest' V1 #20 1989-05-08 (1 file, 7491 bytes)
SOURCE: http://securitydigest.org/exec/display?f=zardoz/archive/120.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT


Date: Mon, 8 May 89 17:02:01 PDT
Subject: Security Digest V1 #20

Security Digest Volume 1 Issue 20

subject(s):

            Security problem in Ultrix 3.0
            Login(1) security hole of Ultrix 3.0
            SERIOUS bug in 3B2/500's and above
            Followup on AT&T bug
            Computer Threat Research Association (UK)
            HDB worm
            Another Sendmail security problem
            Request for TCP/IP
            Sun386i security problem update
            the un"limit"ed sun386i
            Re: Securing the Server

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


Date: Fri, 28 Apr 89 18:18:21 EST
From: Gene Spafford <uunet!cs.purdue.edu!spaf>
Subject: Security problem in Ultrix 3.0

Well, here's another report of a security problem with the "login"
program.

Ning Zhang in Germany has reported to me that there is an option to
the Ultrix 3.0 "login" program that can be used to run arbitrary
programs (same idea as the sun 386i login problem).  Unfortunately, it
runs those programs as "root" and doesn't check for a restricted list
of programs to run.

The problem has been reported to both CERT and DEC.  In the meantime,
you should probably restrict access to "login" (make it mode 500?).
That won't fix the problem, but it helps close down some of the
vulnerability.

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

Date: Fri, 28 Apr 89 11:40:20 -0200
From: uunet!unido!zgdvda!zhang (Ning Zhang)
Subject: Login(1) security hole of Ultrix 3.0

On Ultrix 3.0, using the login(1) command, an ordinary user can create
any SET-UID program.

The login(1) command of Ultrix 3.0 has an option '-P programname' which
causes login(1) to set its standard input and output to the prompting
program <programname>, such as Xprompter(1).  Unfortunately, <programname>
will be run as a set-uid program by login(1).  And if <programname> actually
does somethings like

                /bin/cp /bin/sh /tmp/sh
                /etc/chown root /tmp/sh
                /bin/chmod 4777 /tmp/sh

a set-uid B-shell will be created by command '/usr/bin/login -P programname'!

A QUICK FIX:    remove access to login(1) from an ordinary user. i.e.

                /bin/chmod 2750 /usr/bin/login

BTW, DECwindows on Ultrix 3.0 stores user's plain-text password around
the memory, even the user has logged out. Although I reported the bug to
c.u.ultrix and c.windows.x two weeks ago and also issued a SPR to DEC,
I have not got any fix or reply at all.

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

Date: Tue, 2 May 89 13:08:30 PDT
From: neil (Neil Gorsuch)
Subject: SERIOUS bug in 3B2/500's and above

[ This was sent to me by vsi!friedl, who wanted me me to edit this
as I thought best and send it out to the security list.  The only thing
that I removed was the short little script that actually did the "hacking".
Any competant programmer can recreate it in about a minute, as Stephen says.
In general, I will leave in all required information to describe a problem
in full, especially if there is a companion fix in the submission.  I will
usually chop out the explicit "code" or "script" that does the cracking,
as long as the problem is fully described without it.  If the only way
to describe a problem is by showing the cracking method, I will usually
leave it in the submission. - neil ]

     I didn't want anything to go out automatically, and I'm not
sure how you treat things like this.  I have discovered a major
bug that will allow any user on any 3B2 computer with SCSI disk
drives (that's all 3B2/500s and above, plus the smaller models
that have added this option) to become root in about a minute if
you type slow.

    The non-setuid program /etc/prtconf will print out the
current system configuration (how much RAM, what peripherals,
etc.), and for extended busses like SCSI they use an auxillary
program (in this case, they use "/etc/prtconf.d/scsi") to query
the devices.  This presumably lets them add scsi devices or other
busses without hacking up /etc/prtconf every time.  Other
machines (i.e., the 3B15) do in fact use multiple extended
busses.

     This little scsi program is setuid root, and it
does the following when it finds a SCSI disk drive:

        system("mknod /tmp/scsidisk various_args");
        query the device somehow
        system("rm /tmp/scsidisk");

     AT&T totally blew it here, as the "rm" follows the
system $PATH.  (I suppose that mknod does too, but I like
to use rm).  To crack root, do:

[ 2 line script  and 3 lines of setup commands removed here - neil ]

Now it will run prtconf, query and report on the first SCSI disk
drive, and then call up a root shell.  When you ^D out of this
shell, the program completes normally.  Note that because the
first line of [---] actually removes the file requested plus
the scam file, it leaves minimal trash lying around.

This is really a big-time bug, because all 3B2/500s and above
have (and will have) this bug in all versions up to System V
Release 3.2.1.  AT&T takes a long time to integrate fixes into
the main release tapes, so this will be here for years.

I have reported this to the SCSI development team, and they were
most concerned (and embarrassed, I think).  They have a new
version of this little scsi program, but I don't know yet how
people will get it yet.

An alternate fix would be:

        # cd /etc/prtconf.d
        # mv scsi real.scsi
        # cat > scsi.c
        main(argc, argv)
        int     argc;
        char    *argv[];
        {
                putenv("PATH=/bin:/usr/bin:/etc");
                putenv("IFS= \t\n");
                execv("/etc/prtconf.d/real.scsi", argv);
        }
        ^D
        # cc scsi.c -o scsi
        # chmod og-s real.scsi
        # chmod u=rxs,og=x scsi

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

Date: Sun, 07 May 89 22:35:28 PDT
From: Brent Chapman <uunet!capmkt!brent>
Subject: Followup on AT&T bug

I forwarded the message about the recently revealed AT&T bug to a friend
at AT&T, and here's his response (posted with permission).

  ------- Forwarded Message

From: uunet!gorgo.ATT.COM!bsteve (on Monster Island)

I appreciate the forwarded message much. The hole is real and the problem
occurs on *ALL* 3B2s in *ALL* os releases with scsi disks and tape... I am
going to try to get the fix into the current release distrubution (which is
in beta now). I will arrange patches for customers with releases prior to
3.2.2 for v3 hardware (the one getting multiprocessor tweaking done) to be
provided by the hotline on demand... sigh. I will also post a memo regarding
this problem so that it gets appended to the functional requirements for
release 4.0 systems (though much of the extended bus stuff is being re-written
under release 4 anyway).

   ------- End of Forwarded Message

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

Date: Fri, 28 Apr 89 12:07:29 PDT
From: davidf@cs.hw.ac.uk
Subject: Computer Threat Research Association (UK)

[ Taken from usenet news group comp.risks - neil ]

For those of you interested an umbrella organisation has been established
in the UK to co-ordinate information on, and research into, all aspects of
computer security. In the first instance one of the organisation's primary
concerns will be combatting the threat posed by computer viruses by
acting as a clearing house for virus information and control software.

Below is a copy of an initial letter mailed to prospective members:

                        The Computer Threat Research Association

The computer threat research association, CoTra is a non-profit making
organisation that exists to research, analyse, publicise and find solutions
for threats to the integrity and reliability of computer systems.

The issue that caused the formation of CoTra was the rise of the computer
virus. This problem has since become surrounded by fear, uncertainty and
doubt. To the average user the computer virus and its implications are a
worry of an unknown scale. To a few unfortunates whose systems have become
a critical issue.

The key advantage of CoTra membership will be access to advice and information.
Advice will be provided through publications, an electronic conference (a
closed conference for CoTra's members has been created on the Compulink
CIX system) as well as other channels such as general postings direct to
members when a new virus is discovered.

CoTra membership will be available on a student, full or corporate member
basis. All software that is held by CoTra that enhances system reliability,
such as virus detection and removal software, will be available to all
members. It is intended to establish discounts with suppliers of reliability
tools and services. A library of virus sources and executables and other
dangerous research material will be made available to members who have a
demonstrable need.

A register of consultants who have specific skills in the systems reliability
field will be published by CoTra and reviews of reliability enhancing
software will be produced.

Your support of CoTra will ensure that you have the earliest and most
accurate information about potential threats to your computer systems.

CoTra, The computer threat research association,
c/o 144 Sheerstock, Haddenham, Bucks. HP17 8EX

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

Part of the organisations aims is to establish reciprocal links with other
similar organisations worldwide, to facilitate the sharing of experience
and rapid flow of information on new threats.

To this end if you are involved in (or have contacts with) a similar
organisation in your country, please write to CoTra (or by email to me,
and I will forward your correspondence) outlining your organisation
and its aims.

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

Date: 26 Apr 89 11:36:35 CDT (Wed)
From: uunet!mcmi!denny (Denny Page)
Subject: HDB worm

>When Peter Honeyman posted "The UUCP worm" to the Usenet, I approved of his
>openness; but I also worried about the (hypothetical) brain-dead user who
>decides to actually run the thing.

Well, I've never really considered myself to be brain-dead, but if I
were, how could I tell? :-).  I did in fact set up secured pairs of
machines (ripped out all connections) and began to experiment.  I
quickly discovered two things.  First, that the version Peter posted
does not work (he refered to it as "buggy" :-), and that out of the
four different HDB versions I had access to, only one of the them
could be infected by another (untrusted) machine.  I can't really see
this one running rampant across the net.

If anyone cares, I found the following systems immune:
3B2/xxx         (As distributed with 3.1)
Towers          (As distributed with 2.01)
Arix            (As distributed with 3.1 or so)

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

Date: Mon, 1 May 89 11:18:16 PDT
From: neil (Neil Gorsuch)
Subject: Another Sendmail security problem

[ Taken from usenet news group comp.mail.sendmail - neil ]

Our Sendmail under SunOS 4.0 will apparently run "|program" recipients
with arbitrary uids.  I've been unable to duplicate this with Sendmail
5.59 running on a Vax, but this may be a vagary of configuration.

My .forward file currently includes "|cookie", where "cookie" is a
script that just records the id that it's run by.  So far I have about
a dozen different cookies, mostly from local users who have sent me
mail, several from daemon, and a few from local users who have not
sent me mail.

Watching the mail queue, mail to me gets expanded to my mailbox and
"|cookie"; the message gets dropped in my mailbox, and "|cookie" gets
queued.  The control file for the "|cookie" delivery doesn't keep the
recipient id; something arbitrary (like the sender, or the recipient
of the previous message) is used when the queue gets run.  I leave it
to sendmail experts to delve the internal state that controls this.

(The original "|cookie" was intended to be a harmless prank on someone
whose .forward file was writable by other.  It was something like
        grep -s "Cookie" || (fortune | mail -s "Cookie" `whoami`)
but then, random people started getting cookies..)

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

Date: Fri, 5 May 89 10:54:13 PDT
From: Russell Brand <uunet!lll-crg.llnl.gov!wuthel!brand>
Subject: Request for TCP/IP

Would anyone happen to have a copy of

 bellovin, s. m. (bell labs)  "Security Problems In The TCP/IP
Protocol Suite"

that I could get a copy of ?

Thanks

Russell Brand
2483 Hearst 136
berkeley, 94709

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

Date: Mon, 24 Apr 89 13:32:30 PDT
From: neil (Neil Gorsuch)
Subject: Sun386i security problem update

[ Taken from RISKS digest - neil ]

The serious security problem that was reported in Risks Volume 8, Issue 15
has been corrected by Sun.  Sun support and Sun's field offices are now able
to supply a new set of programs that will solve the problem.  We strongly
recommend contacting Sun A.S.A.P.

Until you receive the new programs from Sun,  we suggest that you change the
protection of the login program.

        chmod 2750 login

This will allow login to continue to work but removes users access to it.

Since we do not have a Sun 386i system at CERT, we were unable to test the
new programs being supplied by Sun.  Field reports indicate that the new
programs do solve the problem.

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

Date: Fri, 28 Apr 89 02:20:28 PDT
From: neil (Neil Gorsuch)
Subject: the un"limit"ed sun386i

[ Taken from usenet news - neil ]

Hi -- You may already know about this one, but if not, here's another
quick way to crash a sun-386i:

        {csh:1} unlimit datasize
        {csh:2} unlimit stacksize
        {csh:3} ls

Even the commands:

        {csh:1} limit stacksize 4m
        {csh:2} sync

which should be legal (from "limit -h"), doesnt work.  '4m' is parsed
wrong (?), and yields a 4 Gigabyte (not megabyte) limit, so the sync
dies....

(4.0.1, Sun 386i/250, 8 Meg, 2*300M drives, 1 cartridge tape,
1 proteon, Friday evening, humidity 70%, 80' elevation, barometer 39.25 and
rising).

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

Date: Thu, 27 Apr 89 10:39:50 PDT
From: neil (Neil Gorsuch)
Subject: Re: Securing the Server

[ This article is the last article in the digest, with an attached
program.  It was taken from comp.sys.sun. - neil ]

(The original poster wanted a way to keep some users from rlogging into
the fileserver, with various other limitations)

I don't know if there's a more elegant solution; this one's kind of tricky
and something of a kludge, but I'm doing something similar and it works
fine for us.

I also don't know if this will meet all your requirements; I assume it's
okay if users are unable to login at the server's console, as well as
being unable to login through telnet or rlogin?

The idea is that when a user logs in, instead of starting his/her normal
login shell, you call an authorization checker.  If the user is logging in
on any machine *except* the server, control is passed to the shell...but
if the user tries to login on the server, s/he must pass an authorization
test.

I've included a piece of code in which the user must be a member of a
special group (in this case, group number 15) in order to log into the
machine which has a hostname of "servername".  If the user is accepted,
s/he begins executing the specified shell.

If you have some users who prefer a different login shell - sh or ksh or
tcsh, you'll need a separate version of this program for each shell you
intend to support (there are ways around this.  hint: use argv[0])

You'll need to add a line to your /etc/group file which lists all users
who are privileged to login to the server.  The group name is irrelevant,
as long as the group number matches the #defined constant "MAGIC".

------------------cut here------------------------------------------------------
/*
 * Copyright (c) 1989 Michael J. Maciolek
 *
 *  Permission is granted to anyone to make or distribute verbatim copies
 *  of this document as received, in any medium, provided that the copyright
 *  notice and permission notice are preserved, and that the distributor
 *  grants the recipient permission for further redistribution as permitted
 *  by this notice.
 *
 */

/*
 * Disclaimer
 *
 *  The recipient accepts full responsibility for determining the suitability
 *  of this software for his/her particular application, and for any damages
 *  arising from the use of said software.  The recipient shall in no event
 *  hold Michael J. Maciolek or the Massachusetts Institute of Technology or
 *  MIT/Lincoln Laboratory liable for any damages arising from the use of
 *  this software.
 *
 */

/*
 * That ought to keep the lawyers happy!  :-)
 */

#include <sys/param.h>
#include <errno.h>

#define MAGIC 15
#define SERVER "servername"
#define SHELL "/bin/csh"

main(argc,argv,envp)

int     argc;
char    *argv[],*envp[];

{
        int     rv,i,glist[NGROUPS],hostname[MAXHOSTNAMELEN];

/* what is my hostname? */

        rv = gethostname(hostname,MAXHOSTNAMELEN);
        if (rv < 0) {
                perror("gethostname");
                exit(errno);
        }

/* of which groups am I a member? */

        rv = getgroups(NGROUPS,glist);
        if (rv < 0) {
                perror("getgroups");
                exit(errno);
        }

/* See if one of my groups is the MAGIC group */

        for (i=0; i<rv; i++)
                if (glist[i] == MAGIC)
                        break;
/*
 * If this is not the server, or if I am in the privileged group, permit
 * the login to proceed.  Else, reject the login attempt.
 */
        if ((strcmp(SERVER,hostname)!=0) || (i<rv)) {
                rv = execve(SHELL,argv,envp);
                perror("execve");
        } else {
                printf("You are not authorized to login to this machine\n");
        }
}
/*---------------------cut here--------------------------------------------*/

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


        End of Security Digest Volume 1 Issue 20
        **********************

END OF DOCUMENT