Sun-Spots Digest, v6n130
William LeFebvre
Sun-Spots-Request at RICE.EDU
Wed Jul 6 11:27:36 AEST 1988
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 at rice.edu
Send subscription add/delete requests to: sun-spots-request at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at sally.utexas.edu.
------------------------------
Date: Wed, 22 Jun 88 14:26:50 +0200
From: mcvax!ecn!wim at 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 at 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 at buffalo.csnet
uucp: ..!{nike|watmath,alegra,decvax}!sunybcs!ugptucha
bitnet: ugptucha at sunybcs.bitnet <-OR-> acscray at ubvmsc.bitnet
------------------------------
Date: Thu, 23 Jun 88 13:06:11 CDT
From: "Joseph P. Thomas" <jpt at 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 at uc.msc.umn.edu
------------------------------
Date: Thu, 23 Jun 88 15:58:21 EDT
From: csrobe at 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 at icase.arpa
1105 London Company Way BITNET: $csrobe at 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
***********************
More information about the Comp.sys.sun
mailing list