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."
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
it's safer running the windows version of something?
truly, it is the end times
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
Coincidence? I think not...
Shared codebase? Hmm?
Blearf. Blearf, I say.
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.