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

can someone explain...

[Churla]

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?

Insufficient data.

[jd]

Sendmail is a big program. It also has several components. This tells me that things like selinux and other mandatory access control systems MAY prevent the attack from taking over the PC. What impact there is on such systems depends on what component the failure is in and what rights that component must have.

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 .exe? When you compile it yourself? When compiled/run via Cygwin? If you run under Wine, do you see the bug or not? Are all versions of Windows safe, or would the bug be exposed under certain versions?

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.

Re:Sendmail - now in its third decade of exploits

[Radak]

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.

Re:Who the hell still uses sendmail?

[Anonymous Coward]

Oh only almost every major corporation in the whole world.

Go back to your mom's basement.

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

[ajs]

There was a time when sendmail exploits were all the rage, but at the time, sendmail was one of a very, very small number of programs that had reached its level of maturity, breadth of features AND was network accessible, and was the only one in widespread use under Unix-like systems. Because of some high-profile bugs, many companies including Sun and later Red Hat did heavy security audits of the code, revealing and fixing more problems.

These are all good things, and it seems to me to be a bit two-faced to say that the power of open source is that there are many eyes on the source, and then to punish the software with the most eyes on it. Sendmail has been the heart of mail on the Internet for decades, and deservedly will continue to do so for the forseeable future.

These bugs demonstrate the old saying: where there is code, there are bugs. I'll stick with software that has already had the vast majority of its security problems shaken out.

First in two years

[Kelson]

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 [secunia.com] 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.

Re:Sendmail - now in its third decade of exploits

[raoul666]

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.

We've been struggling with Windows exploits since its birth, too, and most of the /. community does advocate dropping it. Is it not equally complex?

And now watch my karma vanish in an instant.

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

[Bob Uhl]

Postfix was written by the noted security expert Wietse Venema [wikipedia.org] specifically so that bugs would not lead to security issues--e.g. instead of being one monolithic app which runs as root, it's broken down into several pieces, most of which run as non-privileged users.

Unlike sendmail, it was designed to be secure. I'll take the one for which security was not an afterthought, thankyouverymuch.