Sun-Spots-Request@RICE.EDU (William LeFebvre) (07/06/88)
SUN-SPOTS DIGEST Tuesday, 5 July 1988 Volume 6 : Issue 130 Today's Topics: Major security hole in RPC/REX software! (2) Re: Ethernet transceiver connector slide-locks Re: Sun 3/50 eyestrain (really accommodation) Need help installing Xylogics 753 What means "-From hostname (sendmail)" in the process status? Running TeX on a Sun/4: undump? Centronics Parallel Ports? How to do variable watching? Send contributions to: sun-spots@rice.edu Send subscription add/delete requests to: sun-spots-request@rice.edu Bitnet readers can subscribe directly with the CMS command: TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name Recent backissues are available via anonymous FTP from "titan.rice.edu". For volume X, issue Y, "get sun-spots/vXnY". They are also accessible through the archive server: mail the request "send sun-spots vXnY" to "archive-server@rice.edu" or mail the word "help" to the same address for more information. ---------------------------------------------------------------------- Date: Wed, 1 Jun 88 13:07:19 EDT From: purtilo@flubber.cs.umd.edu (Jim Purtilo) Subject: Major security hole in RPC/REX software! (1) [[ This message was sent to me some time ago. I had originally intended to wait before placing it in a digest so that I could contact the original author of the software for his reaction. However, this information is now widespread on the Usenet (and in other places) and I have gotten the impression from others that Sun's reaction to this problem is "it's fixed in 4.0". For those of you who are running the Remote Procedure Call package, READ THIS NOTE! There are unscrupulous individuals who know how to exploit this security hole and have done so already on certain systems. I would recommend only using the package on a completely isolated and trusted network. --wnl ]] We at UMCP have just discovered (the hard way) that there is a major security hole in a program called "rpc.rexd" on sun workstations. This program is intended to facilitate a form of remote execution between appropriate workstations; the front-end program which is used to request the remote execution is called simply "on". Unfortunately, "rpc.rexd" fails (miserably) in its check of whether the requesters should have the permission to do what they ask for. Because of the way on/rexd works, anyone who wishes can, given root access to his own machine, become any uid he wants on any other machine running rex *anywhere on the Internet*. (Luckily, root appears to be the only exception to this rule, if that is some small consolation.) The authentication test in the Sun3.2 rex daemon appears to proceed as: get the remote user id out of Unix-flavored authentication if it's zero, then deny access if getpwuid(remoteuid) is not NULL then grant access else deny access In other words, any non-zero user identifier which happens to correspond to a valid user on the target machine can be used to gain the privileges of that user. There is no check to see whether that user has granted "trusted" status to the originating user and host (normally done via a file called ".rhosts" in many networked Unix systems), nor is there any check to see whether a system administrator has generically granted such a trusted status to the originating machine. If you're running rexd and you're connected to a network, and if there are people or places on your net whom you don't trust, then we suggest not running rexd. To see if you are running it now, look in your /etc/servers table. If the "rpc.rexd" line is missing or commented out, you're OK. Sun does not enable this daemon in the /etc/servers you read off the installation tapes. There are several ways that this problem seems relevent to the risks forum. The most obvious is the risk of blindly trusting a vendor to ship you software that performs at least `reasonable' security checks. We will not belabor that point here. Instead, we provide yet another testimony to how closely we must all watch what goes on our machines: innocent intentions can still lead to big headaches. Most of the Suns in our network ran version 3.0 of the Sun OS, served by a large central fileserver. Rex daemons were not readily available for this version, and there was no hole. However, many individual research groups have suns of their own. One day, a guru running one of these individual Suns decided to be the first on his block to upgrade to release 3.2. He was not a staff member in our department, but was in fact trusted with superuser access to the fileserver. A well-intentioned chap, as he upgraded his owner's machine, he also installed the new, cute looking goodies from the distribution on the department fileserver so that all might benefit from his efforts. Hence, the normal scrutiny we would subject a new piece of software to was bypassed. Whether or not we would have found the hole when doing our normal installation of this software is unclear, to be sure, but we would at least liked to have had a shot at finding it. You can only speculate at where we have hidden the body of the late, otherwise well-intentioned, guru who installed the rex daemon. Pete Cottrell, Steve Miller, Jim Purtilo, Chris Torek ------------------------------ Date: Thu, 23 Jun 88 11:14:01 PDT From: Doug Moran <moran@ai.sri.com> Subject: Major security hole in RPC/REX software! (2) [[ Doug Moran has added some comments of his own: --wnl ]] To amplify on the threat posed by REX: --even though root is prohibited using REX, REXD permits the remote user to perform "privileged" operations on the local host. In my experiments with REX, I was able to become root on the target system in less than 30 seconds. --randomizing user ids is NOT an effective strategy for slowing down a cracker using REX: all suns have standard set of users with known user ids (e.g., nobody, daemon, ...) that can be used to gain a toehold. I discovered this security problem last year and reported it to Sun. Sun's response has been "Release 4.0 fixes a lot of the security problems. Wait for 4.0 and see if it is still a problem." (The decision on whether or not to post information on existing security problems in public forums is a very difficult one. My group's policy is "when in doubt, don't post" and we could not make a strong enough case to justify posting. However, now that the problem is in the open...) Global issues (some flaming): I am very concerned about Sun's cavalier attitude towards network security. While I am aware that Release 4.0 claims to provides improved security and I have seen descriptions, Sun's past history makes me skeptical that there aren't major security holes in it and that Sun will continue to be slow to acknowledge existence of such problems and to fix them. For those of you not familiar with this history: --To my knowledge, Sun has not only never issued a bug-fix release to eliminate an identified security problem, but security problems that had been reported to them were not fixed in normal bug-fix releases. The clear implication is that security is a low priority. An example: the tftpboot security problem in Release 3.0 was identified during the beta-test (and broadcast to Unix-Wizards), but Sun neither supplied a fix or even a warning in the official release. The fix was trivial: in less than 1 hour, we produced a patch (essentially the tftpboot of 3.2) and packaged it for distribution to, and easy installation, by other groups. --The software distribution comes with most of the security features (tftpboot instead of tftp, IP address checking on NFS, ...) turned off. It is left to the system administrator to hunt down the sections in the manual describing how to turn those features on. --We heard the Friday-the-13th Sun software time bomb rumor, and we checked with the Tech Support Engineers in our sales office to see what Sun knew about it. They checked with Sun Engineering and told us that Sun knew nothing of the rumor. This was 4pm PDT and subsequent published reports state that Sun became aware of the rumor about 12N PDT. Was it bad communications or stone-walling? In my dealings with Sun about the Release 3.0 tftpboot security problem, the attitude expressed by a to-remain-unnamed member of Sun's engineering staff was that if I had any concern about network security, I shouldn't be using UNIX (granted this was two years ago, but that person is still an influence within Sun and still seems to regard security as "a bother"). Doug Moran ------------------------------ Date: 20 Jun 88 21:49:04 GMT From: sdcrdcf!sdcsmb!samsun!darrelj@hplabs.hp.com (Darrel VanBuer) Subject: Re: Ethernet transceiver connector slide-locks [[ This message was forwarded from the "tcp-ip" list. --wnl ]] Slide locks are not perfect, but when correctly implemented do not cause much trouble. Sun's violation of the 802.3 spec (and the more implicit specs in the orginal Ethernet document -- where you have to read the connector manufacturers' catalogs to get all the rules for correct adjustment) is a major headache. By putting a chassis between the connector flange and the slide, they steal about 1.5 mm of pin insertion out of a total of 3 mm pin insertion, leaving the connector quite wobbly. At one time, we dealt with this by modifying the drop cable to remove two washers which the spec says SHOULD be between the lock posts and the connector flange, resulting in a cable end which complements the Sun error, and gets a good fit. Of course this cable now fails to properly fit a conforming computer or extension cable :-(. When properly fit, a slide lock is quite strong. With poor QC or design, they are abysmal. ------------------------------ Date: Thu, 23 Jun 88 12:07:57 cdt From: Brain in Neutral <bin@rhesus.primate.wisc.edu> Subject: Re: Sun 3/50 eyestrain (really accommodation) The common myth is that the resting point of accommodation is optical infinity. This is false. The 20 feet mentioned above is closer, but still wrong. The resting point of accommodation is about the same place your hand is if you extend your arm. (RPA is the distance at which your eyes focus when you are in the dark and thus provide your accommodative system with nothing to focus on). Video monitors are not, therefore, at a distance which is tremendously discrepant with your RPA, although there may be some accommodative effort required to focus on a screen which is 20 inches away, of course. You can relieve this some by moving the monitor farther away. That may make it harder to read, unfortunately. I would guess that a larger source of eyestrain is introduced if you use windows or backgrounds that are white instead of gray or black. This is because the human visual system has a higher sensitivity to flicker at higher light intensities than at lower intensities. This is easy to get around by using a gray background, white on black in terminal emulator windows, etc. Using white on black emulator windows introduces another problem, though, if you are constantly switching your eyes from the screen to a sheet of paper writting in black on white (e.g., as happens when transcribing a hand-written letter to a file, or when entering your source code from your scrawled notes on paper). This is because the accommodative constrast is constantly switching from white on black to black on white. ------------------------------ Date: Thu, 23 Jun 88 17:46:38 CDT From: natinst!brian@cs.utexas.edu (Brian H. Powell) Subject: Need help installing Xylogics 753 We've just received a Xylogics 753 controller for our Sun 3/160 running SunOS 3.2. We've already got a Xylogics 450/451 controller driving two hard disks, and we'll be adding a third disk with the new controller. The Xylogics instructions for using their boot tape (full of the device drivers, a new diag, etc.) explain only how to work with the controller to create a brand new kernel. That's not what we want; we've already got a perfectly fine kernel thank you very much. Basically, I just want to know how to get the device drivers (and whatever else I need) off the tape so I can just reconfigure a new kernel without having to install a new OS on the new drive. E-Mail replies preferred. Brian H. Powell National Instruments Corp. brian@natinst.uucp 12109 Technology Blvd. ut-sally!cs.utexas.edu!natinst!brian Austin, Texas 78727-6204 AppleLink:D0351 (512) 250-9119 x832 or if that doesn't work, you can use brian@sally.utexas.edu. ------------------------------ Date: Wed, 22 Jun 88 14:26:50 +0200 From: mcvax!ecn!wim@uunet.uu.net (Wim Rijnsburger) Subject: What means "-From hostname (sendmail)" in the process status? At our institute, we have a network of 18 SUN's, mostly 3/50 systems with a shoebox. In response to "ps -ax" on our mailhost I always see a lot of processes related to sendmail: ... 26243 ? IW 0:00 -From gibson (sendmail) 26244 ? IW 0:00 mail -r MAILER-DAEMON -d gaby 27195 ? IW 0:00 -From lotus (sendmail) 27201 ? IW 0:00 mail -r MAILER-DAEMON -d marcel ... I'm wondering: - what does it mean? - is it normal? - where can I read about it? I have not found anything in the manuals. Is there anyone who can help me? Thanks in advance. Wim Rijnsburger (...!mcvax!ecn!wim) Netherlands Energy Research Foundation, ECN Petten, Holland. [[ These are informative messages that sendmail places in its argument list (so that "ps" will display them). I don't know if they are documented anywhere. --wnl ]] ------------------------------ Date: Thu, 23 Jun 88 14:02:58 EDT From: ugptucha@cs.buffalo.edu (Ray Ptucha) Subject: Running TeX on a Sun/4: undump? I recently installed TeX on one of the new Sun4/110's here running Sunos4.0. TeX works fine- but is lacking the handy undump program that is so useful on the Sun2/3's and on the VAX's running UNIX. Does anyone out there have an undump program for the Sun4's? Right now I am stuck with aliasing tex to "virtex \\&plain", but if I don't have to preload the fonts everytime I use TeX I would rather not. Thanks for the help... Ray Ptucha, SUNY/Buffalo Computing Center, UCS Consultant: csnet: ugptucha@buffalo.csnet uucp: ..!{nike|watmath,alegra,decvax}!sunybcs!ugptucha bitnet: ugptucha@sunybcs.bitnet <-OR-> acscray@ubvmsc.bitnet ------------------------------ Date: Thu, 23 Jun 88 13:06:11 CDT From: "Joseph P. Thomas" <jpt@uc.msc.umn.edu> Subject: Centronics Parallel Ports? We currently support two centronics parallel ports on Vaxen. One drives a QMS laser printer, the other, a Data Products laser printer. We are looking to phase the Vaxen out, and need to replace this service on a Sun 3/180 or 280. Does anyone have any experience, favorably or not, recomendations, comments on writing ( or supplied ?? ) devices drivers, etc ??? Comments and such can be sent to me, and if I get enough interest/respones, I'll submit a follow up note. Thanks. -Joseph Thomas -Minnesota Supercomputer Center -jpt@uc.msc.umn.edu ------------------------------ Date: Thu, 23 Jun 88 15:58:21 EDT From: csrobe@icase.arpa (Charles S. Roberson) Subject: How to do variable watching? i have a variable in a C program that I would like to watch (more particularly, i would like to watch the address which contains that variable). i seem to remember being able to do this on a (er? ahmm) VMS system, does anybody know how to make dbx(tool) do this? I have scanned the documentation and help (plus a few friends) but to no avail. thanks, -chip ps: DISCLAIMER: I only used VMS once -- that doesn't mean I like it! Chip Roberson ARPANET: csrobe@icase.arpa 1105 London Company Way BITNET: $csrobe@wmmvs.bitnet Williamsburg, VA 23185 UUCP: ...!uunet!pyrdc!gmu90x!wmcs!csrobe [[ How about "trace variable_name"? Don't know how to watch a specific memory location, but I suppose it is possible. Tracing does tend to slow down execution of the program being debugged quite a bit. --wnl ]] ------------------------------ End of SUN-Spots Digest ***********************