jkp@sauna.hut.fi (Jyrki Kuoppala) (10/06/89)
Security problems come back haunting us again. Nothing much new here, but
seems that the old bugs haven't been fixed and more ways to use them have
surfaced because of this. If you thought that sendmail was fixed in
4.0.3, you were wrong. Use Berkeley's 5.61 or get the binary from
uunet.uu.net; it should work, although it's based on 5.59 from Berkeley
when the current version is 5.61.
Here's some sad facts about the default configuration of a Sparcstation
running SunOS 4.0.3c, in some kind of order of seriousness:
1. The sendmail in 4.0.3c and 4.0.3 is still buggy. Anyone who can access
the sendmail daemon (connect to the smtp port) can write to any existing
file writable by any user other than root. It's easy to get access to any
user's account for example by writing into her .rhosts file. I won't
include an example here but it's got to do with the old problem of
specifying the same recipient twice, just use your imagination to repeat
it. Also, it might well be possible to exploit the bug by mailing
directly to programs.
FIX: get UCB sendmail version 5.61 or later. Also the one from uunet (at
least the MX version) seems to work and I have not heard any problems with
it, so it might be easier to install it.
2. /usr/bin/uudecode is not suid anything, and there's the mail alias
`decode' which is translated to `|/usr/bin/uudecode'. This way, anybody
who can send mail to your machine can write to any daemon-writable file
and worse yet, anybody who can connect to your machine via smtp (the
sendmail daemon) can write any file writable by any other user than root.
FIX: delete the `decode' alias
3. /etc/hosts.equiv contains +, so anyone from the network can access the
machine.
FIX: delete the /etc/hosts.equiv file or edit to to be sensible
4. /.cshrc's `set path' command has dot as the first component of path.
FIX: edit /.cshrc to remove . from the path
5. /etc/utmp is world-writable. This was one of the original causes ogf
the rwall / wall / tftp hole, and probably takes part in other not yet
surfaced security holes.
FIX : chmod og-w /etc/utmp
Problem with the fix: Suntools does not handle /etc/utmp right; it assumes
that utmp is writable by any user. We don't use Suntools, so it's not a
problem with us; I've been told that Suntools works reasonably well even
with utmp protected, but some problems arise.
5. rpc.rexd still exists with no mention about the fact that enabling it
(without the -s option) on a networked Sun is the equivalent of leaving
the machine without the root password. Further, the hint to that effect
from the manual page (talk about an understatement !) has been removed:
BUGS
Should be better access control.
Worse yet, the manual page mentions the -s option but THAT'S NOT
IMPLEMENTED YET. So the user is lead to believe that rexd uses secure rpc
when in fact it does not.
FIX: Don't use rexd
6. uucp's home directory is /var/spool/uucppublic and it's login shell is
/bin/sh (the login shell is omitted which defaults to /bin/sh).
/var/spool/uucppublic is world-writable. Any user on the system can do:
cat > x
myhost myname
^D
uucp x ~uucp/.rhosts
rsh myhost -l uucp sh -i
I don't know that much about uucp, but it's probably harmful to let any
user get access to the uucp if uucp is used, and it might well be possible
to use uucp to put the .rhosts file in ~uucp and then log in via the
network.
FIX: change the login shell of uucp to /nonexistent or some such.
On the bright side: now rshd and rlogind won't accept connections from
ports <= 512. It took quite a long time to get fixed, but so's life.
In my opinion the abovementioned bugs are unforgivable, as they've been
publicized a long time ago. 3, 4 and 6 are just plain bad manners and 5
seems like an evil trap for customers and other vendors using SunRPC (I
know of one vendor who has the rexd service turned on by default). Also,
Sun is just asking for trouble using their own version of sendmail based
on an old version (5.59 for the one on uunet, earlier still for the one
distributed with 4.0.3?) when 5.61 from Berkeley is out and available for
anyone to use.
To make security holes disappear in general, I see no other way than to
publicize the holes widely enough, after first giving the vendors time to
develope a bug-fix and distribute it to their customers via ordinary
support channels and also channels like mailing-lists and archive server
so people without services contracts won't be left out in the cold.
Since these bugs have been widely publicized before and solutions are
easy, I decided to publish this message.
I have communicated the problems with Sun and they are aware of the
problems. I hear that some of the problems will be fixed in 4.1, others
(the utmp stuff) when SVR4 comes out and that the Sun people are working
on the issues to which no clean fix is yet available.
Sun tells me that they can't fix bugs unless a formal bug-report is filed.
I feel bad about that with serious security bugs like these, but it seems
that bureaucracy has its ways of creeping to us from all directions. I'll
be filing the formal bug reports for the ones not already reported when I
have the time.
//Jyrki
Jyrki Kuoppala Helsinki University of Technology, Finland.
Room U249, Otakaari 1, 02150 Espoo, Finland, tel. + 358 0 451 4316
Internet : jkp@cs.hut.fi [128.214.3.119]
BITNET : jkp@fingate.bitnet Gravity is a myth, the Earth sucks!