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' V3 #4 1991-01-08 (1 file, 5911 bytes)
SOURCE: http://securitydigest.org/exec/display?f=zardoz/archive/304.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT


Date: Tue Jan 8 12:13:37 PST 1991
Subject: Security Digest V3 #4

Security Digest Volume 3 Issue 4

subject(s):

            Full privs under VMS 5.4 -- David Copperfield Lives
            Re: Full privs under VMS 5.4 -- David Copperfield Lives
            NFS clients can become root on NFS servers
            Re: NFS clients can become root on NFS servers
            grumble, grumble
            TTIOCONS patch on uunet
            Re: "strangers probing for security flaws"
            Re: "strangers probing for security flaws"
            Re: Suns 4.1 problems with X

The unix security mailing list is by invitation only and contains
sensitive material which SHOULD NOT BE REVEALED to non-members.
DO NOT PUT ANY LIST CONTENTS IN LOCATIONS ACCESSABLE TO NON-MEMBERS.
If you must keep copies on-line, please encrypt them at the very least.

PLEASE POST TO:                              security@uninet.cpd.com
PLEASE SEND EMERGENCY ALERTS TO:   security-emergency@uninet.cpd.com
PLEASE SEND REQUESTS TO:             security-request@uninet.cpd.com

Postings that describe security holes/fixes have a * in their subject.


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

Date: Wed, 19 Dec 90 08:59:45 EST
From: brendan@cs.widener.edu (Brendan Kehoe)
Subject: Full privs under VMS 5.4 -- David Copperfield Lives

  Perhaps some of you folks can help me out. One of our users, an alumnus of
here and a pretty good friend, has been logging out with full privs for about
3 weeks now. We just discovered it about 4 days ago. Here's the trail leading
to the smoking gun:

  Around the 3rd he started spawning subprocesses, which is one of the ways
you can convert "authorized" privs into "default" privs. Seeing him spawning
so much made me suspicious .. so I checked it out. Those subprocesses were
exiting with a privilege mask of FFFFFFFFFFFFFFFF (everything). Interesting.
  Then, a few days later, he was logging out of his *main* process
with partial privs (I don't have the list here, but they included
SETPRV [which I think he started with then added what he needed at the
time], CMKRNL, WORLD, OPER, and a bunch of others [including DETATCH,
after a *detatched* image exited]).
  Then, a few days after that, he was logging out of his main process
with a privilege mask completely masked.
  We haven't fixed the ANALIMDMP problem, for two reasons -- one, four
of us are actively trying to figure out how to *do* it [it's been
eating our curiosity ever since it was first sent out], and we don't
have any users that know anything past compiling C programs, except
for the four of us. But this hole isn't the source, we think, because
the # of accesses on ANALIMDMP.EXE has remained at 0 for over a month.
(We were able to make sure it wasn't being cleared out.)
  So that leaves the other possibility -- we have Wallongong TCP/IP
5.0 installed (haven't decided what new version, if Wallongong or
someone else, we're gonna get yet). It has a bunch of images,
including ARP, PING, FINGER, NETSTAT, RCP, and RLOGIN installed with
CMKRNL, that beautiful doorway to heaven.
  One of them, PING, didn't run at first, so he patched it when we
installed it so it would -- after checking it out, the only difference
is that it calls SYS$IMGSTA before calling $QIO. After some research I
found out what SYS$IMGSTA does, so I discarded that possibility.
  Apparently something happened on Dec 12 for him, too -- a HUGE chunk
of the operator log is missing between 9pm Dec 12 to 4pm Dec 13. And
the printed out versions (a decwriter's hooked to the console) were
*also* missing. Suspiciously, everything after that last Dec 12 entry
was gone. We can think of a few times when he was in that he coulda
trashed them or thrown them into the recycling box.

  So! We're actively pursuing this. We'd like to be able to block the
hole without confronting or asking him anything, just to make him
wonder how the hell we knew. Anyone that can help us out, please
respond to root@cs.widener.edu. I'll provide any other information you
feel would be of use.

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

Date: Fri, 21 Dec 90 3:33:01 EST
From: brendan@cs.widener.edu
Subject: Re: Full privs under VMS 5.4 -- David Copperfield Lives

  Whelp, a little update to this .. he was just on tonight, and I snagged
an executable that was sitting in his directory. After spending the past
3 1/2 hours turning it into source, it turns out that the thing disables
(or re-enables) the accounting for his current process. Only problem is,
you have to have cmkrnl to USE it in the first place, which doesn't help
us figure out how he's getting there in the first place. Gahh!!!
  Ah well . . . the plot thickens.

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

Date: Wed, 19 Dec 90 12:27:59 CST
From: Tom Christiansen <tchrist@pixel>
Subject: NFS clients can become root on NFS servers

I've made the debatable mistake of discussing this on the net, and I was
informed that this was not well-known and that I therefore shouldn't have
done so.  Consequently, I feel it's my responsibilty to send notification
on what I preceive to be a non-trivial problem.

I've tested this on Suns, Convexes, and combinations thereof.  I
suspet it's in all NFS systems.

In a nutshell, as root@client, I can mknod devices on a server's file
system if it's mounted r/w.  I can easily find a world-writable directory
to put it in, because I can become any user/group who can write something
anywhere, even if "nobody" can't, and make this new directory
world-writable.

I choose major/minor numbers on the device so that they make sense on the
server, not the client, although it is on the client that I'm making it.
I then change the mode of the device 666 and go back over to the server
and wreak havoc.  Two good candidates are /dev/mem or any disk device.

Here's the sequence to make the device: I'm root@cthulhu, my workstation:

    cthulhu# df .
    Filesystem            kbytes    used   avail capacity  Mounted on
    globhost:/usr/spool/globdata
                          371967  280812   53958    84%    /rmt/globhost/globdata

        { ``globhost'' is another Sun, but this works with non-Sun NFS
            systems as well. }

    cthulhu# ls -lgd .
    drwxrwxrwt 43 root     bin          4096 Dec 19 11:52 ./

        { Even if it weren't world-write, I could become the owner
          and make a world-write subdir. }

    cthulhu# ls -lg /dev/mem
    crw-r-----  1 root     kmem       3,   0 May 29  1990 /dev/mem

    cthulhu# mknod mymem c 3 0

        { I actually have to choose the right major/minor number
          for the server, not the client, if it's his kernel I
          wish to crack. }

    cthulhu# ls -l  mymem
    crw-r--r--  1 -2         3,   0 Dec 19 11:49 mymem

        { See, I made it fine, and it's owned by "nobody". }

    cthulhu# chmod 666 mymem

    cthulhu# ls -l mymem
    crw-rw-rw-  1 -2         3,   0 Dec 19 11:58 mymem

Here's a way to punch my shell's uid to 0 on a Convex:

[ I left out the specific directions with offsets - neil ]

There are to my mind, three possible solutions:

    1) Export no file systems read-write.  Not feasible in
       many environments.

    2) Disallow remote mknods like that.  I suspect this would
       break something or other.

    3) Add a new option to mount like suid that says whether device files
       are to be considered valid; otherwise return ENXIO.  Normally only
       mount root this way, and never export root.  I believe this will do
       the trick.  For diskless workstations, you of course have their
       {the workstation owners} devices on your {the server} disk, and
       they can add all the devices they want to that partition, but since
       that filesystem isn't mounted with device interpretation enabled,
       it won't do them any good anyway.

I really like #3, but it will take a while for vendors to coordinate
on it.  It also solves other potential problems of stray devices.

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

Date: Wed, 19 Dec 90 12:45:57 CST
From: Tom Christiansen <tchrist@pixel>
Subject: Re: NFS clients can become root on NFS servers

My contact at Sun have unofficially reported the following to me on the
bug I just turned in to you folks:

    This appears to be fixed in SunOS 4.1.1 (I don't know whether it
    worked in previous releases or not).  The mknod (as root in a writable
    nfs mounted directory) fails with ``mknod: not owner.''  I assume that
    the nfs mknod request requires the filesystem to be mounted with root
    mapped to 0 for the request to work.

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

Date: Thu, 20 Dec 90 02:02:34 PST
From: neil (Neil Gorsuch)
Subject: grumble, grumble

[ I'll have to stop reading alt.security again pretty soon, I keep getting
  flamed there, and I can't help responding, it seems, and then it starts
  all over again.  Grumble, grumble.  - neil ]

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

Date: Thu, 20 Dec 90 13:37:10 PST
From: neil (Neil Gorsuch)
Subject: TTIOCONS patch on uunet

[ A patch for the TTIOCONS problem is available for ftp from uunet.uu.net
  under the sun-fixes directory - neil ]

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

Date: Wed, 19 Dec 90 08:57:05 PST
From: rogers@marlin.nosc.mil
Subject: Re: "strangers probing for security flaws"

Well is it better to have unauthorized users (aka hackers) be the only
ones doing the probing?

I would rather find out from a friendly source that my system has a
security hole, then to have it discovered by unauthorized users who
are sure not gonna warn me about it.

We could look at this as assistance from an "unofficial" tiger team.

Of course, I would feel better if it were USA computer people vice
the Eyetalians.... :-)

Only One man's opinion!

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

Date: Fri, 21 Dec 90 13:11:14 -0800
From: gnu@toad.com
Subject: Re: "strangers probing for security flaws"

Given the existing state of computer security (i.e. it requires
excessive care by a system administrator to make a system more than
nominally secure), I think that whatever automation we can bring to bear
on security testing is welcome.

Suppose there was a free program, available in source code and scrutinized
by wizards all over the net, that you could run to test your security.
If you had the time, you might run it and fix up the things it found.
If you didn't have the time, those things would probably go unfixed.

If someone at a remote site (Italy?) volunteers to run such a program
and mail you the results as they pertain to your site, are they
performing you a service or a disservice?  I don't know about you, but
when a stranger knocks at my door to tell me that I left my garage
door gaping wide open and the neighborhood hoods are eyeing my
bicycles, I usually thank her rather than knocking her down and
calling the police.  Then I go and fix the garage door.

If the stranger had taken a few bicycles before coming and telling me
about the problem, that would be different.  But even that is preferable
to their stealing the bicycles and not even telling me I had a problem.

Sites all over the Internet *are* being probed by people who want to
do them harm.  We know this as a fact.  I would prefer if we had some
volunteer "cop on the beat"s who would walk by periodically and rattle
the door to make sure it's locked.

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

Date: Fri, 21 Dec 90 15:29:17 PST
From: neil (Neil Gorsuch)
Subject: Re: Suns 4.1 problems with X

[ This article posted on comp.windows.x re-posted on alt.security - neil ]

There is a security problem with certain X clients running under SunOS
4.1.  The problem only affects setuid programs that have been linked
with relative -L shared library paths.  xterm and xload are possible
candidates, from the core MIT X distribution.  IF you are using shared
X libraries, AND you have installed xterm and/or xload as setuid
programs, then please do one of the following:

Option 1. Relink the program statically (using -Bstatic).  For example, in
          the R4 xterm Imakefile, change the line

NormalProgramTarget(xterm,$(OBJS1),$(DEPLIBS1),XawClientLibs,$(TERMCAPLIB) $(PTYLIB))

          to

NormalProgramTarget(xterm,$(OBJS1),$(DEPLIBS1),-Bstatic XawClientLibs -Bdynamic,$(TERMCAPLIB) $(PTYLIB))

          and in the R4 xload Imakefile, change the line

LOCAL_LIBRARIES = XawClientLibs

          to

LOCAL_LIBRARIES = -Bstatic XawClientLibs -Bdynamic

Option 2. Make the program non-setuid.  You should consult your system
          administrator concerning protection of resources (e.g. ptys and
          /dev/kmem) used by these programs, to make sure that you do not
          create additional security problems at your site.

There is a third option, which is to link the programs only with absolute
library paths.  This only works if reasonable versions of the libraries are
already installed at the time that you link the program.  Since this option
introduces possibilities of link errors (depending on your environment), and
it is poor build practice to forcibly install libraries except during an
install phase, I am not providing Imakefiles details for this option, but
you may want to consider this option (given that Option 1 has a performance
penalty) if you do not feel comfortable with the consequences of Option 2.

If you have questions about how to correct this problem at your site, please
feel free to send me mail about it, and I will try to answer as best I can.
We will try to correct this problem in the R5 build procedures (although
personally, I think Sun made a big mistake in creating this hole, and the
correct fix is to patch SunOS 4.1).

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

        End of Security Digest Volume 3 Issue 4
        **********************

END OF DOCUMENT