Sendmail Hit by Data Interception Flaw 208
ricepudd writes "Computer Weekly reports that Internet security researchers have discovered a serious flaw in Sendmail. The flaw could allow remote attackers to take control of users' PCs. The Sendmail Consortium urged users to upgrade to version 8.13.6 of the software, which contains a fix to the problem. Computer Weekly seems to think that the fact that the Windows version isn't affected will help curtail the threat."
Flaw seems unexploited (Score:5, Informative)
n/sendmail-8.13.6-i486-1.tgz: Upgraded to sendmail-8.13.6.
This new version of sendmail contains a fix for a security problem
discovered by Mark Dowd of ISS X-Force. From sendmail's advisory:
Sendmail was notified by security researchers at ISS that, under some
specific timing conditions, this vulnerability may permit a specifically
crafted attack to take over the sendmail MTA process, allowing remote
attackers to execute commands and run arbitrary programs on the system
running the MTA, affecting email delivery, or tampering with other
programs and data on this system. Sendmail is not aware of any public
exploit code for this vulnerability. This connection-oriented
vulnerability does not occur in the normal course of sending and
receiving email. It is only triggered when specific conditions are
created through SMTP connection layer commands.
Sendmail's complete advisory may be found here:
http://www.sendmail.com/company/advisory/index.sh
The CVE entry for this issue may be found here:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE
(* Security fix *)
No link to actual advisory in summary or article (Score:5, Informative)
http://www.frsirt.com/english/advisories/2006/104
The FreeBSD mailing list is a little less alarmist (Score:5, Informative)
From: Claus Assmann <freebsd+security@esmtp.org>
To: freebsd-security@freebsd.org
Subject: Re: FreeBSD Security Advisory FreeBSD-SA-06:13.sendmail
Date: Thu, 23 Mar 2006 10:31:20 -0800
On Thu, Mar 23, 2006, Bigby Findrake wrote:
> Does an attacker need network access to the machine, or does the attacker
Yes.
> merely need to be able to get an SMTP message to the machine?
He needs to control the timeouts (AFAICT).
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd
To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"
Re:My PC? (Score:4, Informative)
What do you think the spammers use on their zombie boxes? Code they wrote themselves?
Re:Flaw seems unexploited (Score:5, Informative)
Re:No link to actual advisory in summary or articl (Score:3, Informative)
The inevitable 'use postfix!' post.... (Score:5, Informative)
The two major alternatives are Qmail and Postfix; Courier is sort of an up-and-comer, but they've had quite a number of security holes in those packages. (of course, that may also be related to the fact that Courier does a lot more than just deliver mail.) Of the three, I prefer Postfix. It's exceedingly solid, very fast, and fairly easy to configure. The initial learning curve is a little steep (mostly because there's about a billion things you can set), but the config files are readable when you're done. You don't have to relearn the whole program every six months. It's also very secure... I'm only aware of two security problems in its entire history. (I don't remember the details, but I think one was minor, and the other was moderately serious.)
QMail is also solid, fast, and secure. But the author has decided that Unix machines should be configured a particular way, with files in particular places, and he uses his code as a weapon to try to force you to do things the way he wants. So I won't run it unless I have to. I don't deny that he's a brilliant coder and forty-eight times smarter than I am, but I refuse to be dictated to.
Postfix can take a beating.. it is Truly Great Software. It will handle any load that Sendmail will handle, it's easier to administer, and the security is better. And, of course, it's truly free... Wietse won't try to make your administration decisions for you.
Re:Gee, Full Disclosure would be nice (Score:5, Informative)
As it happens, someone already posted [slashdot.org] a screenshot of the BSD version of the fix.
A single line of c:
t = 0;
Inserted between lines 147 and 148 of file fflush.c appears to be the fix (reset a mem pointer just use above).
I don't vouch for it and haven't even bothered to look at context or even if its the actual fix required, however its not like it was hidden and you don't need to get uppity about it.
Incidentally, its such small code modifications that can bring great amounts of money to maintainers of corporate code that the monkeys don't understand what they are paying for.
"But you only changed 1 line"
"Yer, but that one line makes it work now...."
Re:Flaw seems unexploited (Score:5, Informative)
We do our best.
Seriously though, CERT told us that the embargo was going to end at 16:00 UTC, so I had a shell window open with a series of "cvs commit" commands waiting for me to hit <enter>, a window with the commit messages I was going to use, a window with the advisory text waiting for me to type in the correction times, a shell window open to ftp-master.freebsd.org waiting for me to copy the patches into the right directory...
When you have two weeks advance notice, it's easy to get advisories out soon after the embargo ends -- the hardest part of the process was making sure that I'd be awake at 8:00 AM (PST).
Re:Who the hell still uses sendmail? (Score:5, Informative)
This sentence alone shows what an idiot you are. Go look up anomalous and then come back.
Back? Okay, good. Let's move on.
We still use sendmail because it meets our needs and because to those of us who actually know how to use it, it is less of a pain in the ass than your "better" alternatives. Sendmail had a whole slew of security problems many years ago before alternatives were even available, but in recent years, it has really not notably more security issues than any of the other options.
Face the facts here. Qmail and Postfix certainly have their uses, and are both excellent MTAs, but neither is "way better" than Sendmail for all installations. We each have our own requirements, and Sendmail meets those requirements for a lot of my installations.
Re:Flaw seems unexploited (Score:5, Informative)
Re:My PC? (Score:2, Informative)
I see an awful lot of this on any given day
@400000004422e50b06a4b4dc Accept::RCPT::Rcpthosts_Rcptto: S:63.145.94.241:unknown H:ms1.remax.local F: T:xxxx@xxxxx
@400000004422e514391f8af4 Accept::RCPT::Rcpthosts_Rcptto: S:65.218.62.86:unknown H:wolf-server.WolfRealty.local F:xxxx@xxxx T:xxxx@xxxx
@400000004422e5340cc927bc Accept::RCPT::Rcpthosts_Rcptto: S:70.89.50.73:unknown H:apollo.kwlansdale.local F:xxxx@xxxxx T:xxxx@xxxx
@400000004422e53a3ae2842c Accept::RCPT::Rcpthosts_Rcptto: S:67.43.168.74:unknown H:bilbo.idcdomain.local F:xxxx@xxxx T:xxxx@xxxx
@400000004422e56c2bf424d4 Accept::RCPT::Rcpthosts_Rcptto: S:71.4.51.66:unknown H:cmsacsvr01.comstock.local F:xxxx@xxxx T:xxxx@xxxx
Like it or not, and whether the rfc's require it or not, there are an awful lot of people out there using mail servers setup by people completely and utterly unqualified to maintain them. And you bet your ass your users are going to complain (loudly) when they can't get emails from their customers/clients/aunt betty/whatever.
Same for requiring reverse dns, spf records, etc. Use any of these for hard rejection, and you're nuts. (Hear me AOL?)
Re:Sendmail - now in its third decade of exploits (Score:3, Informative)
Re:Sendmail - now in its third decade of exploits (Score:3, Informative)
More detailed information on how to exploit bug... (Score:2, Informative)
http://www.rapturesecurity.org/jack/exploiting_se
Quoted:
written in a rush, pardon the mess
not that ive gotten that far but here is my (confirmed by mark, thanks) attack....
step 1)
connect to sendmail server say something like
helo me\r\n
mail from: myemail@hotmail.com
rcpt to: root
data
step 2)
wait for server to say go ahead
send about 32767 characters inside a header
note what time it is
step 3)
wait until you get:
451 4.4.1 timeout waiting for input during message collect
step 4)
note what time it was when that message happened
step 5)
youll be dropped back into smtp command mode, now there is a static pointer inside sm_syslog thats your attack vector, youll need to recreate the collect timeout and race into sm_syslog
resend the helo crap
step 6)
wait for server to say go ahead
send about 32767 characters inside a header
and wait the time delta from the earlier 2 measurements
step7)
send more header data (so that its now greater than 32768 bytes)
hopefully sendmail will now race and crash inside sm_syslog because:
a) we just sent sendmail into sm_syslog due to the fact that we sent > the max amount of header data
b) we have a timeout (SIGALARM, longjmp thingy) that should be pending about the same exact time that
we entered sm_syslog
Also posted is a PoC to test if you are vulnerable. This needs a lot more work, and is not an exploit, but is a start:
http://rapturesecurity.org/jack/sendmail_tester_t
Re:Agreed (Score:3, Informative)
Re:Flaw seems unexploited (Score:3, Informative)
Re:My PC? (Score:3, Informative)
I think it is you who need to fix your broken MTA:
"An SMTP server MAY verify that the domain name parameter in the EHLO command actually corresponds to the IP address of the client. However, the server MUST NOT refuse to accept a message for this reason if the verification fails: the information about verification failure is for logging and tracing only."
Note the "MUST NOT". Rejecting an email because the host has no reverse DNS or incorrect host name is prohibited by RFC2821
Re:Agreed (Score:3, Informative)
Re:The inevitable 'use postfix!' post.... (Score:4, Informative)
The two main configuration files are master.cf and main.cf. Master is the configuration for how the daemons work and talk with one another, and it's used to add in other programs for weird delivery arrangements. For 'normal' mailservers, you probably won't have to mess with that too much. Main.cf, on the other hand, is where you'll do almost all the configuration work... virtually everything goes there.
Stuff that requires lookups, like virtual addresses (the 'virtual' file) or transports (the 'transport' file), is set up in child files, flat text. The 'postmap' program compiles the text files into
You should probably expect to spend a day or two setting up a server the very first time you use it. Nothing is that hard, but it can be a little frustrating figuring out where to look for a given feature. Everything is easy, there's just a lot of it.
Once you have it running, the configuration becomes practically self-documenting, so it's *really* easy to make changes. Sendmail is write-only... you can get it working, come back a week later, and have _no_ idea what you're looking at. Postfix isn't like that... if it works, it will generally be pretty obvious how and why it works. (and it will usually be pretty clear about why things AREN'T working, too.)
If it has a weak point, it's probably that the documentation is rather scattered... expect to do a lot of googling while setting up.
It's really worth the effort. It's one of the best pieces of free software out there. And it's one-time only effort, unlike sendmail.
Re:The inevitable 'use postfix!' post.... (Score:3, Informative)
Most of the other tests use external
Some of the possible tests are:
A check_helo_access clause points at a file with one or more SMTP HELO tests. On my server, for instance, anyone that says they're in my domain, or that they're any of my IP addresses, or that they're 127.0.0.1, get immediately bounced. This file is formatted as source and REJECT or OK.
check_recipient_access lets you specify a list where particular recipients will be accepted or rejected; most sites accept postmaster mail unconditionally, as an example. Again source and REJECT or OK.
check_client_access points at a list of IP addresses, with REJECT or OK.
(there are several more possibilities as well, I won't talk about all of them.)
Postfix goes through all the tests listed in its smtpd_recipient_restrictions clause, looking for an OK or a REJECT. If it gets either, it stops further testing, and immediately processes the mail. If it gets no response from any of its tests, it accepts the mail. You could put an explicit deny rule last, if you wanted to reverse that behavior.
I haven't used sendmail in a very long time, so I'm not sure what local-host-names does. If that's 'who can relay through me', that's usually done by setting the my_networks argument, and then using a permit_mynetworks clause in smtpd_recipient_restrictions. That's not normally done through a file lookup, although you could if you wanted.
Aliases and virtual domains are done through
If the source is just a naked word, it's assumed to be a user, and you can redirect mail from one user account to another this way. If the source is user@domain, then only exact address matches will be redirected to the target. And if the source is @domain, it redirects everything from that domain to a specific place.
Some examples:
root useraccount -- redirects from root to that user
test@example.com useraccount -- sends only mail to test@example.com to useraccount. Other addresses are rejected.
@example.com useraccount -- send all mail for example.com that isn't matched by someone else to useraccount. Can be used as a catchall.
Postfix has two concepts for domains.. the main one it serves, and all the rest, which are virtual. If you have a user 'joe', and someone sends mail to 'joe@example.com', joe will only get the mail if that's your primary domain. If it's virtual, joe@example.com will bounce, unless you explicitly set up a redirect.
I suspect the access table is just handled through the tests I