info-vax@ucbvax.ARPA (09/22/84)
From: *Hobbit* <AWalker@RUTGERS.ARPA> Some of you probably know all about this one already, so skip to the question. If you have the binary distribution of the Eunice tools, on a VMS system, you very likely have a big raggedy security hole. On our system at least, sys_tools:sh is installed with detach privs, presumably to handle background [&] processes right so they stay around when you log out the top level. Given correct procedure, sh would snarf up your UIC and start the process using that, simply allowing the detached process [and presumably *not* passing the detach priv to that process!]. But, I found, it is not loaded with /notrace, so you can go into DBG> on it. It's then fairly easy to load in a little program to do a $creprc with UIC [1,4] or something -- and from there, you head straight for the UAF. We don't have sources for any of this stuff [well, we have something strange called .W files that look kinda like C sources but with funny other things in them], so if sh is to stay extant and work properly, the hole must remain. [On our instructional 780, no one, including the system manager, really knows enough to understand how it works anyways!] It would probably be good to look around and check all your privileged images with run/debug. Even ones with OPER can be dangerous, if you have smart terminals in system offices that can send lines ... We've all heard about that one, right? Well, okay, this is all well and good, but I still can't get sh to work properly. If I do something like foo.com & [which I assume would do foo.com in a detached process], it complains about not being able to find the shell image. What logical names does it want so it can find its interpretation of /bin/sh or whatever and start it up?? _H* -------
info-vax@ucbvax.ARPA (09/24/84)
From: (Dave Martin [stug]) dpm@lbl-csam As a non-EUNICE user I can't be certain, but it sounds to me like what you have is not EUNICE but rather an obsolete LBL/Hughes Software Tools ssystem. We haven't used the logical name sys_tools for a couple of years so I suspect your system is at least that old. The ".w" files you mention are probably archived RATFOR (not C) sources. Let me suggest that you obtain a recent Software Tools tape from either DECUS (VAX SIG tapes) or the Software Tools Users Group. We have closed some of the security holes you mention. If what you really want is EUNICE, it is available from the Wollongong Group in the Bay area. Having too many UN*X and UN*X-like systems lying around on the same machine can be a bit confusing, eh?
rcb@rti-sel.UUCP (09/24/84)
There is one grungy solution to the security problem with Eunice. Edit the executable to remove the debug start address. Randy Buckland ...!mcnc!rti!rcb
info-vax@ucbvax.ARPA (10/07/84)
From: *Hobbit* <AWalker@RUTGERS.ARPA> Yep -- you were all right, it's the LBL tools VOS package, not Eunice. It was apparently built under Eunice, hence the heavy references to that... And yes, it's *old*.. we had this stuff under 2.x or something. The system in question is such that even if security holes are present and *known*, the guy responsible doesn't fix them. I think I've flamed in the past about this fellow.... _H* -------