Slashdot Mirror
Sendmail Hit by Data Interception Flaw
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."
Ah, the WINDOWS version is NOT affected! How ironic!
As everyone who follows the Slackware changelog, new packages were available yesterday. It seems there is still no exploit for this flaw, and it's somehow hard to exploit. That's the impression I got from the changelog entry. I'll paste it here:
t ml- 2006-0058
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 *)
http://www.frsirt.com/english/advisories/2006/104
The difference between "Serious" and "Highly Critical"...
(Yes, tongue is firmly in cheek here...)
Why would this qualify as serious if there isn't even a known way to exploit it yet? Or was there one in there I missed?
I'm a fiscal conservative, it's a pity we don't have a political party anymore
So the FBI was wiser than we thought in withholding e-mail accounts...
An email I received from the FreeBSD security mailing list seems to imply to me that this might be more of a concern for multi user systems.
- security
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"
Work bio at MMWD
Windows has shipped with an SMTP server installed since Windows 2000. It's off by default in Server 2003 and in all client versions, and, I think, in 2000 Server, but it's there.
What do you think the spammers use on their zombie boxes? Code they wrote themselves?
Further info of this security advisory available on CVE-2006-0058 and from Security Focus
Just don't create a file called -rf.
Yes, I realize this is too late for those of you running Sendmail now, and please don't take this as criticism for using it.... it's a solid mail program. But it was written when the Net was a much nicer place, and it's proving, once again, that retrofitting security is either very difficult or impossible. For a long time, it seemed like practically every third exploit was for Sendmail... it got pretty frustrating.
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.
If you knew that you would be 99% of the way to solving the bug.
As it happens, someone already posted 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...."
liqbase
I hark from a time when that kind of information was front and centre in the security advisory. I'm old, I have an inalienable right to get uppity.
How we know is more important than what we know.
There are also multiple ways of configuring sendmail when compiling it, which tells me that whilst an upgrade may be important, it may be much more important for some users than others.
Also, saying it doesn't affect Windows is unclear. Does it not affect Windows when you use some official
The report, as described, is about as useful as saying "we think we know a way by which under certain circumstances that we know, another may think they know a way by which you might have an increased chance of being struck by an asteroid". If you don't know what the way is, or what those circumstances might be, the information has little value. Sure, it has some in that they provide a bugfixed release, but we don't know how long the bug has existed and therefore have absolutely bugger all way of quantifying what the risk is that a server has already been compromised. It only prevents uncompromised servers from being attacked by this method in future.
Just because the press release is dated XYZ does not mean that every Black Hat under the sun hasn't got a CD-ROM filled with exploits for it and a list of backdoors on cracked sites from three years back. XYZ is merely the date the rest of us know about it. You don't maintain a secure system by assuming all crackers only know the exploits you've fixed. You maintain a secure system by assuming at least one cracker has the means to discover the exploits you've neither heard of nor have patches for - ie: by assuming you're running buggy software and taking the necessary steps to limit what those bugs can do.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
What do you think the spammers use on their zombie boxes? Code they wrote themselves?
Why would a spammer need a smtp server on a zombie box? Don't zombie boxes just send email?
Je ne parle pas francais.
And what protocol do they use to send it? SMTP, of course.
This has been another D'oh! moment.
Good, inexpensive web hosting
Coincidence? I think not...
Shared codebase? Hmm?
Blearf. Blearf, I say.
I ignored posts like this for years, figuring it was like the Linux vs. BSD debates -- just a bunch of zealots. I was wrong.
/. peer pressure and switched to Postfix. It's just like Sendmail, only it doesn't suck. I didn't know Sendmail sucked until I used Postfix. It's easy, it's secure, and my servers haven't once been 0wn3d because of the ubiquitous MTA flaws of Sendmail.
Years after I mastered mc files and learned the magic of m4, back around 2002, I succumbed to
Some day I'll try Qmail. Baby steps.
-Waldo Jaquith
But they're an SMTP client, not an SMTP server.
Do you even lift?
These aren't the 'roids you're looking for.
Using sendmail is anomalous to asking for trouble.
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.
Results 1 - 10 of about 18,000,000 for linux exploit.
We've been struggling with Linux exploits since its birth, too. Shall we "drop the turkey" every time a new Linux exploit pops up, too, or should we acknowledge that it's a complicated piece of software whose security generally improves as it matures? I thought so.
Oh, and just for good measure...
Results 1 - 10 of about 203,000 for qmail exploit.
Results 1 - 10 of about 283,000 for postfix exploit.
I note that those queries generate about 1/3 and about 1/2 as many results, respectively, for products that have existed for about 1/10 as long as sendmail. By your ridiculously flawed "Google logic", qmail and postfix are far more dangerous "turkeys" than sendmail.
HELO verification as far as verifying HELO matching fqdn or ptr record or something is a highly dangerous thing to do and will lead to tons of false positives. Ever notice how many MSexChange servers are running out there declaring "IAMASTUPIDEXCHANGESERVER.LOCAL" or something?
...
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?)
"Oh my God! The dead have risen! And they're voting Republican!" - Bart Simpson
There has never been a remotely or locally exploitable vulnerability in qmail, regardless of what your Google query tells you.
Oddly, this is the first security fix I can remember for Sendmail in about two years. Just to check my memory, I looked at Secunia's report and they only list 5 vulnerabilities since January 2003.
2 in March 2003
1 in August 2003
1 in September 2003
1 in March 2006
2.5 years between vulnerabilities? Not too shabby, IMHO.
There is, however, one unpatched vulnerability, though the worst it can do is hide details from the log.
We've been struggling with Linux exploits since its birth, too. Shall we "drop the turkey" every time a new Linux exploit pops up, too, or should we acknowledge that it's a complicated piece of software whose security generally improves as it matures? I thought so.
/. community does advocate dropping it. Is it not equally complex?
We've been struggling with Windows exploits since its birth, too, and most of the
And now watch my karma vanish in an instant.
When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl
There has never been a remotely or locally exploitable vulnerability in qmail, regardless of what your Google query tells you.
...which was exactly my point. Googling for a product name followed by "exploit" does not yield results which accurately measure a products actual exploitability, as the original poster suggests.
Jack from Dyad Security just posted this link:n dmail.html
;]
h ingy.tar.gz
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
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
Basically Sendmail was written in the age when moving mail from place A to B actually was difficult
No. Sendmail was written when moving mail was easy- they just thought it was going to get harder so they overengineered it.
The whole message rewriting header/scrambling thing has NEVER been needed to transfer to/from uucp hosts, the 7bit fantasy network, or other messaging networks- it was ALWAYS performed in the gateways to those other networks.
Source routes should never have existed- There should never have been a reason why the person sending the message might know more about the messaging server than the server itself.
There's no reason a user should ever send mail to a program- users only ever sent mail to addresses, and by exposing programs as "a special kind of address" - they made it possible to yes, use UUCP without the mail administrators' permission, but they also opened the whole slew of bugs in sendmail that popularized the mid '90s.
Sendmail _never_ had to be this complicated. They did it this way because of equal parts stupidity and hubris, and pretending it was anything else means it'll happen again (see IPV6 for more details).
By the way, I've had zero difficulty getting qmail- which itself doesn't understand how to send mail over uucp, Fido or Citnet, to actually transfer mail bidirectionally with all of these networks. Love or hate qmail, if the naive mailbox-to-user approach was good enough for all these networks, it would've worked for sendmail.