Security Digest Volume 1 Issue 35 subject(s): Sendmail security bug in 4.0.3 *and* 4.0.3c Re: X Security Re: Mail weakness More info on sun3 sendmail on uunet Security Hole in SunOs 4.0.3 HP-UX (HPPA) Security Prevention Re: Sequent Symmetry Sendmail ------------------------------------------------------------------------ Date: Wed, 27 Sep 89 01:52:58 edt From: uunet!harvard.harvard.edu!thakur%cfa201 (Manavendra K. Thakur) Subject: Sendmail security bug in 4.0.3 *and* 4.0.3c I have verified that Sun Sendmail has serious problems, as described by Jyrki Kuoppala in the Security Digest V1 #34. This problem not only manifests itself on SunOS 4.0.3c (as reported by Jyrki) but also in SunOS 4.0.3. The hole in Sun Sendmail allows you to write into any file owned by any user other than root. The solution, as Jyrki recommended, is to get Berkeley Sendmail 5.61, compile it, and and use it. The Sun sendmail executables available on uunet.uu.net are dated August 31 and are based on Berkeley 5.59 Sendmail (according to the README file in the sun-fixes directory). I can't for the life of me understand why Sun is still working with 5.59 when 5.61 has been available since January. Anyway, back in April, Stan Barber sent out diffs to enable YP aliases support in Sendmail 5.61. This was under SunOS 4.0.1, but I imagine that the code should compile and work under SunOS 4.0.3 and SunOS 4.0.3c. I know that I will be installing Sendmail 5.61 and applying Stan's patches as soon as possible. I recommend that all other sites do so as well. I also vote that Jyrki's message (or at least an edited version of it) be sent out to the sun-managers and sun-nets mailing lists. We need to publicize the presence of the hole (although not necessarily how to exploit it) as much as possible. [ Do you want me to publish security hole fixes to netnews, if I can do so without giving any real clues as to how to exploit them? Please reply to security-request, and I will summarize. - neil ] ------------------------------------------------------------------------ Date: Wed, 27 Sep 89 13:15:06 EDT From: uunet!crl.dec.com!treese (Win Treese) Subject: Re: X Security The X Consortium is exploring the security issues. Contact Jim Fulton (jim@expo.lcs.mit.edu) for more information. ------------------------------------------------------------------------ Date: Wed, 27 Sep 89 17:14:44 mdt From: David Haimson Subject: Re: Mail weakness | I don't know whether this is already a known problem, but under the | current release of HP-UX on 9000/800s (3.10), and possibly previously | too, the mail spool directory /usr/spool/mqueue is world-readable and | searchable, and sendmail on this system creates temp files there which | are also world-readable. This means that anyone could run a "tap" on | all mail passing through this system simply by watching for temporary files | and taking copies. Mail is not the most secure thing in the world | anyway, but: | a) it's the medium for distribution of this list, and | b) there's no reason for this overly permissive behaviour. | [Further mumblings about too-lax permissions generally on shipped systems...] We do ship /usr/spool/mqueue world-readable/searchable, as he says. However, the configuration file we ship has always made the default queue file mode 600, plus if you don't set the default file mode at all, the default is also 600 (in previous releases, including 3.1, mode 000). If HP-UX sendmail is making the queue files world readable, it's being system-administrator-configured to do so. ------------------------------------------------------------------------ Date: Thu, 28 Sep 89 16:26:59 edt From: uunet!harvard.harvard.edu!thakur%cfa201 (Manavendra K. Thakur) Subject: More info on sun3 sendmail on uunet In a recent security digest, Jykri Kuoppala wrote: > FIX: get UCB sendmail version 5.61 or later. Also the one from uunet > (at least the MX version) seems to work, but I don't know what that's > based on so I can't be sure. [The fix that Jykri is talking about applies to the security hole in the SunOS 4.0.3 and 4.0.3c sendmail that allows you to write into any file owned by any user except root.] I tested the non-MX version of sendmail that Sun made available through uunet. It too seems to work properly (i.e, at least this security hole has been plugged). To find out more about where these versions of sendmail came from, I looked in the sun-fixes/README file on uunet. Here is what it says about the two new versions of sendmail: > sendmail.mx.sun3 > sendmail.sun3 > sendmail.mx.sun4 > sendmail.sun4 > are versions of sendmail that have various security > holes fixed. This sendmail is based on UCB 5.59, with several > security holes fixed, and performance improvements. So we know that the sendmail is derived from Berkeley's 5.59 sendmail To find out whether Sun has a version of sendmail that is derived from Berkeley 5.61, I sent mail to Bill Nowicki at Sun. Here is his reply: > Date: Wed, 27 Sep 89 13:19:04 PDT > From: nowicki@Eng.Sun.COM (Bill Nowicki) > To: thakur%cfa201@harvard > Subject: Re: Berkeley 5.61 sendmail > > All known security bugs should be fixed in the release on UUNET > (essentially from SunOS 4.1Beta linked for running on 4.0.x). If you > know of any remaining ones then please file a bug report through your > customer service channels. Most of the security holes were actually > fixed in 4.0.3. Our sendmail also has some performance enhancements, > better error messages, and bug fixes, so it is not a simple port of > Berkeley's software. I don't know how many of you have talked with Bill Nowicki before, but he's earned my respect with his helpfulness and generosity in the past. Although he didn't answer my question about the availability of a 5.61-derived sendmail, I am willing to assume that statements about the uunet sendmail are true, especially considering that the uunet sendmails seem to be free of the noxious hole that Jykri discovered. So I don't think it's necessary to make an all-out effort to compile and install Berkeley 5.61 sendmail. These uunet sendmails should do for most sites. (Of course, that's just my opinion. But you now have at your disposal all the facts that I collected, and so you can make and follow your best judgement.) ------------------------------------------------------------------------ Date: Mon, 2 Oct 89 11:57:39 CDT From: "Craig Finseth" Subject: Security Hole in SunOs 4.0.3 I just discovered a small, but important, hole. As shipped, the /etc/rc.local file explicitly sets the modes of /etc/motd to 666 each time the machine is booted. Thus, anyone can write to the file: a file which is displayed on everyone's terminal on each and every login. The fix is to edit /etc/rc.local. I am in the process of calling this into Sun, but don't hold your breath waiting for me to succeed... [ Various people that deal with Sunos security read this digest. This is an easy way to let them know of problems, and to put a little pressure on them to fix the stuff. Whether or not they will do it, who knows? - neil ] ------------------------------------------------------------------------ Date: Mon, 02 Oct 89 10:09:16 PDT From: To: uunet!zardoz!security Subject: HP-UX (HPPA) Security Prevention On HP-UX 9000/800: 1) Deny all access to at(). If this is not possible then scrutinize your /usr/lib/cron/at.{allow,deny}. There is a bug in at() that will give anyone a root shell. crontab() does have the same bug but it's not a bad idea to restrict it too. (This should be fixed by 7.0). 2) Make sure all your entries in /etc/passwd has a password and there isn't a common or group password, if you have netunam(). Remember netunam() does not execute pw_shell field! 3) If you enabled /etc/btmp (created the file) make sure it's only readable by root. A lot of passwords are caught as bad login attempts. ------------------------------------------------------------------------ Date: Tue, 26 Sep 89 22:32:04 -0400 From: Jeffrey C Honig Subject: Re: Sequent Symmetry Sendmail > We just got an S-81 on September 7. Much to my shock, the old sendmail > debug hole was there and waiting!! I got a patch from Sequent tech support, and > left teeth marks all over the salescritter, since I feel that vendors should > not be sipping "debug capable" sendmail programs at this late date. Was the security hole there, or did you just assume it was because debug mode was enabled? Debug mode is not a security hole, the ability to write to pipes (and files) as a priviledges user is a security hole. ------------------------------------------------------------------------ End of Security Digest Volume 1 Issue 35 **********************