Bugtraq mailing list archives
Re: Exploit for sendmail smtpd bug (ver. 8.7-8.8.2).
From: jimd () starshine org (Jim Dennis)
Date: Sun, 17 Nov 1996 14:28:09 -0800
Jim Dennis
On Sat, 16 Nov 1996, Leshka Zakharoff wrote:# This is exploit for sendmail smtpd bugHow many of these exploits are thwarted by setting sendmail.cf's O RunAsUser=postmaster switch, making /var/spool/mail and var/spool/mqueue 664 postmaster.mail and giving postmaster a shell of /bin/false (C version, compiled -Bstatic.) AB
AB, I doubt that Leshka's bug is affect by these measures. His bug seems to rely on the simple facts that the simple facts that sendmail is SUID root (which it needs to bind to port 25 and to "run as" (su to) any UID) and that it improperly trusts the information in it's *argv[0] for the purposes of re-exec'ing on receiving a SIGHUP. These are unrelated to the permissions on the spool files. This exploit doesn't involve the operation of sendmail after it's bound to it's port and is listening. It involves the fact that sendmail will allow normal users to exec it, as a daemon, and it will subsequently load an arbitrary piece of code, from an arbitrary location (just as long as you invoke sendmail with an *arg[0] (it's first argument) as a full path to that that code and the filename of that code is "smtpd"). Because the process is now owned by the user -- that user can now send it signals. Because sendmail's sighup() function (HUP handler) just logs and re-exec -- it will let the control when the bogus code is executed. I suspect that some implementations of Unix are not vulnerable to part of this attack --- they probably won't allow the user run process to send a signal to the already running sendmail (that one that was started by init or root). That would not be adequate protection. Many sites don't run an SMTP listener -- they just have sendmail process the queue through a cronjob. Those sites would vulnerable. I think the "right" answer looks something like this: sendmail should stat the file before it re-exec's If that file isn't owned by it's EUID (usually root) or isn't SUID (if it's EUID doesn't match its UID) it should fail. Is there a standard, portable way for a Unix program to know what file was loaded and exec'd (the true link/inode through which it was exec'd)? Is it time to revisit this idea of sendmail being user executable? Should we have one small program that runs as the listener, and another small program that serves as the local delivery agent, and another small program that serves as the smtp transport, and another small program that performs the routing and aliasing/dispatch function? Perhaps, if the Internet community *is* going to continue to rally around sendmail, it's time to review the QA process under which we release and distribute sendmail. Last night I spend about three hours looking around the news groups and web, and the sendmail docs and sources for an e-mail address of who to send a patch to or how to report a bug. Eric Allman's address isn't listed anywhere that I could find. The sendmail sources seem to indicate that Eric is still involved in maintaining sendmail -- and they didn't list any other names (exept for some specific ports). There doesn't seem to be a sendmail-bugs () cs berkeley edu or a web page explaining how to join the "sendmail security bug du jour" club. It seems like this has been going on for twenty years. In the short 3 years that I've been paying attention to bugtraq there seems to be one exploitable sendmail bog every quarter (remember the mime overflow from a couple months ago). There must be a better way. Maybe I'll look over the sources to smail...or mmdf...or mayber I'll print out and actually read the sendmail sources. The problem is that I'm not a C programmer (yet). So, while this will be a great learning experience -- it might not have a tremendous about of "net" benefit (if you'll all excuse the pun). Jim Dennis, Starshine Technical Services
Current thread:
- Re: A security issue of a different kind., (continued)
- Re: A security issue of a different kind. Piete Brooks (Nov 27)
- Major Security Vulnerabilities in Remote CD Databases David J. Meltzer (Nov 26)
- Re: Major Security Vulnerabilities in Remote CD Databases itudps (Nov 26)
- lquerypv fix Troy Bollinger (Nov 25)
- HP Bug of the Week! Aleph One (Nov 23)
- HP Bug of the Week: OFS Aleph One (Nov 23)
- Serious BIND resolver problem. Oliver Friedrichs (Nov 18)
- Re: Serious hole in Solaris 2.5[.1] gethostbyname() (exploit Alan Cox (Nov 19)
- Re: Serious hole in Solaris 2.5[.1] gethostbyname() (exploit Joe Zbiciak (Nov 19)
- Re: Serious hole in Solaris 2.5[.1] gethostbyname() (exploit Tim Newsham (Nov 20)
- Re: Exploit for sendmail smtpd bug (ver. 8.7-8.8.2). Jim Dennis (Nov 17)
- big fat gethostbyname() hole Pete Ashdown (Nov 18)