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 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 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 **********************