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."

Comments

Flaw seems unexploited

[rg3]

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:

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.sht ml
              The CVE entry for this issue may be found here:
              http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE- 2006-0058
              (* Security fix *)

Re:Flaw seems unexploited

[molnarcs]

FreeBSD also has details in their security notification. Those guys are fast - if you want to have up to date info on security vulns., FreeBSD has them (usually with patches) way before the news hits slashdot ;) For those who are asking for line numbers, just take a look at the patches included. Or better, here is a kompare screenshot.

Re:Flaw seems unexploited

[cperciva]

FreeBSD also has details in their security notification. Those guys are fast - if you want to have up to date info on security vulns., FreeBSD has them (usually with patches) way before the news hits slashdot

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:Flaw seems unexploited

[Bacon Bits]

It seems there is still no exploit for this flaw, and it's somehow hard to exploit.

If you read Sendmail's complete advisory, you can see that the vulnerability requires the exploitation of a race condition. You have to submit a request, and then before that one times-out submit another malformed one.

Re:Flaw seems unexploited

[Ed Avis]

You need a secure revision control system where changes you check in can be encrypted. So you could check in the fix as soon as it's discovered, but only a small number of people who know the key could check out the new version (and make further patches, etc). Then at 16:00 the key gets published to the rest of the world and everyone can then update.

No link to actual advisory in summary or article

[doorbot.com]

I believe this is the actual advisory:

http://www.frsirt.com/english/advisories/2006/1049

A critical vulnerability has been identified in Sendmail, which could be exploited by remote attackers or network worms to take complete control of an affected system. This flaw is due to errors in the "setjmp()", "longjmp()" and "sm_syslog()" functions that do not properly handle certain asynchronous signals, which could be exploited by remote unauthenticated attackers to execute arbitrary commands by sending specially crafted requests to the SMTP port.

The FreeBSD mailing list is a little less alarmist

[micheas]

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.

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- security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"

Re:My PC?

[YU Nicks NE Way]

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?

Re:No link to actual advisory in summary or articl

[pneumatus]

Further info of this security advisory available on CVE-2006-0058 and from Security Focus

The inevitable 'use postfix!' post....

[Malor]

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.

Re:The inevitable 'use postfix!' post....

[Malor]

It's not a drop-in replacement, in the sense that it doesn't use the same config files. (You can read postfix files :) ) Unless you have an _extremely_ complex environment, though, it usually won't take very long to write the postfix equivalents to do what you need.

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 .db format, which lets Postfix do fast queries on them.

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....

[Malor]

Sendmail is awkward in this area, because the new features/tables have been added over time. Postfix abstracts deciding whether to accept mail a little bit. You use smtpd_recipient_restrictions in your main.cf, which lists a series of tests to be done on each mail. RBLs are listed individually, one per line. An example would be reject_rbl_client relays.ordb.org. You can list as many as you like; I have six.

Most of the other tests use external .db files for speed. These are flat text lists of two arguments each; source and either destination or action, and are compiled into a binary lookup file with the postmap command. (you have to run postmap on a file every time you change it.) How the two arguments are parsed depends on the context in which you call it. They all have the same basic format... argument1 argument2.

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 /etc/aliases (same format as sendmail, for compatibility), and the virtual file. The virtual file can list as many domains as you like. Each line, like all other database lookup files, is a source/target pairing, interpreted a bit differently than the files above.

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. /etc/aliases is used only for the primary domain. I believe if you point 'joe@example.com', through the virtual file, at the 'jane' account, and /etc/aliases redirects 'jane' to 'bob', bob will get the mail. (test this to be sure... and this is a bad way to do it anyway, you really only want to alias once.)

I suspect the access table is just handled through the tests I

Re:Gee, Full Disclosure would be nice

[LiquidCoooled]

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...."

Re:Who the hell still uses sendmail?

[Radak]

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.

Re:My PC?

[Batou]

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?)

Re:Sendmail - now in its third decade of exploits

[tqbf]

There has never been a remotely or locally exploitable vulnerability in qmail, regardless of what your Google query tells you.

Re:Sendmail - now in its third decade of exploits

[Radak]

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.

More detailed information on how to exploit bug...

[jrl]

Jack from Dyad Security just posted this link:
http://www.rapturesecurity.org/jack/exploiting_sen dmail.html

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_th ingy.tar.gz

Re:Agreed

[dodobh]

Don't bother. qmail is a kludge after you have used Postfix. Having to patch source to get anything done?

Re:My PC?

[blane.bramble]

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

[Malor]

I haven't worked with it much (and milter not at all), but the Postfix equivalent is the 'policy daemon interface'. It's not identical, but quite similar, from what I've read.