|
|
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
| ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved. |