Sendmail Bug Tests US Dept Homeland Security

yanestra writes "CNET reports that the reported Sendmail bug has been a test for the US Department of Homeland Security which seems to have managed information flow in this case."

Comments

Wow

[unterderbrucke]

And it's taken them this long to set up a system like this. I'm glad Bush got his act together and appointed someone to the administration who actually cared about information technology, otherwise this may have taken much longer.

Dept. of Homeland Security

[Ivan Raikov]

Speaking of the Dept. of Homeland Security, here's an link to an article with some suggestions to Tom Ridge on how to improve his department, so that it actually keeps the citizenry well-informed and aware of possible terrorist threats and how to handle them (as opposed to keeping them scared and in an information blackout).

Showcase for open source

[arvindn]

The article reads like a showcase of the OS security model. Basically Sendmail Inc. made available a patch before news of the vulnerability leaked and exploits could be created. Classic case of the good guys spotting the bug before the bad ones.

Quote:

"Working with the private sector, we alerted key owners of the vulnerable software and got them talking," said David Wray, spokesman for the IAIP Directorate. "We think this is a great example of how this should, and does, work."

The Department of Homeland Security got high marks from the security community for giving companies the necessary time to create the patch and for synchronizing its release.

"This is the model for what you do if you want to find a vulnerability," said Alan Paller, director of research for the SysAdmin, Audit, Network and Security (SANS) Institute

Re:bleh

[embo]

And I'm talking in terms of a couple days. If the affected parties hit the snooze button and two weeks roll by, then yes, release the info and make fun of them for the havoc it causes. ;)

FYI, this flaw was actually found in December and just reported yesterday, roughly two months later.

Re:I'm a bit confused ...

[Zemran]

You are confused. Sendmail is a server and Outlook is a client. The 2 statements do not contradict each other in any way.

Re:Where does this leave CERT?

[Monofilament]

I was thinking the same thing you were at first with CERT being cut out of the picture. CERT is an independent organization.. and they rely on people telling them stuff. It seems in this case.. as far as patching and notification of the initial vulnerability.. but they weren't cut out of what they do best, which is Archiving all of the notifications and making it easy to get patch info, once it comes available. Its not like CERT actually makes they patch. As you can see HERE CERT has a notification about this one.. seems CNET left out that LinkCERT I think, at least now with this development, works much more like Slashdot.. in that they get notified of the news and they post it all on their site. Of course if its the first time anybody has heard of it they notify affecting people first, so as not to create unneeded havoc, with hackers getting to the vulnerability first.

So CERT will still go on. In this case all the people involved cut out CERT voluntarily, ISS,SANS, FedCIRC and the like. I'm sure of course CERT (in that they have a notification about it) wasn't really cut out.. then again.. they didn't neccessarily do all the coordination work.. they're proabably happy about that one. They can worry about other stuff. My opinion everybody should be this involved in fixing security issues.

YHBT, was Re:I'm a bit confused ...

[JCholewa]

> Outlook isn't an e-mail server, its a client. Get a clue.

The original poster was rather obviously going for a +5, Funny.

Re:Encouraging

[Overt Coward]

I thought it's supposed to be duct tape... if you can't fix it with duct tape, then it's *BROKEN*.

Not that bad a security hole

[iabervon]

In order for this to be exploitable, the compiler has to arrange the data segment such that there is a structure containing pointers shortly after the buffer that can be overrun. As it turns out, most builds of sendmail, including all of the Red Hat precompiled binaries tested and all of the commercial UNIX ones tested, are not directly exploitable (that is, it might be possible to get them to misbehave somehow, but not to crash in any predictable way). The exploits also depend on knowing what structure you've hit, which is only possible if you have access to the particular binary, and the exploits will only work for a particular binary.

So this is not a good candidate for a worm or automated exploit, and only useful for a direct attack if you happen to be relatively unlucky and the attacker knows it.

Re:Not that bad

[TequilaMonster]

So, they had to patch a ton of different versions, and you don't necessarily want them issuing a shitty patch. So if you blame anyone, blame those sendmail monkeys for the delay. ;)

Sun just delays - We're looking at probably 3-4 weeks yet before they roll out a patch for the Cobalt range. That's pretty much been the pattern up to now - 4-6 weeks for really critical patches, and god knows how long for less important stuff.

Excuse me if I sound bitter.

Re:Why does sendmail still in use?

[jeremyp]

If you look closely, you'll find that there are quite a number of completely different programs now that are called "sendmail".

No there aren't. There is one program called sendmail that you can obtain from sendmail.org. It's an open source program that has suffered from source code forks in the past. But there is pretty much only one source tree that counts now.

It has been widely understood that the original sendmail program was an overly-complex beast that tried to do everything for everyone, and was probably not fixable in any general sense.

It hasn't been a serious security risk for at least five years. Yes it's a complex piece of software, but providing the full functionality required of modern SMTP MTA is a complex task.

Because there has been so much software installed that knows how to talk to the original sendmail, it has been common to make new mailers present the same UI to the world. This way, a new mailer can just be dropped in as a replacement for sendmail, and everything works.

Providing a sendmail compatible command line interface does not make an MTA sendmail. Do not call other MTAs "sendmail" or the sendmail consortium lawyers may sue you. In fact to be a true drop in replacement a program would have to understand the sendmail config file. Since most replacements have tried to get away from using the config file aka programming language used by sendmail, I'd be surprised if any of them could be described as a true drop in.

In effect, "sendmail" is now just a description of a set of command-line options used in the rc and cron scripts.

No it isn't.

If a mail daemon implements these, it can be dropped in as a replacement for whatever "sendmail" is there, and it'll do the job required on your system.

Do you even know what the job of sendmail (or another MTA) is?

On several systems, I've replaced sendmail with a small (100-200 lines) perl script that mimics all the functionality in use there. This has given me a large number of geek points among non-perl-hackers. I just grin and say something like "That's trivial for a true perl guru." They don't have to know that it doesn't take a perl guru to do such a job.

I haven't seen your code, but I'm guessing you have just replaced the command line functionality that allows you to inject a text file as an SMTP message into port 25 of a real MTA. You probably haven't implemented proper queuing, background delivery, prioritisation, alias handling, masquerading, routing, TLS, SMTP AUTH, LDAP routing etc etc etc.

This does bring up a significant question about this news item. When they talk about a "sendmail flaw", which sendmail are they talking about? Presumably it only effects one of the N sendmails that are in use.

They are talking about sendmail. It apparently affects several releases of that package, see sendmail.org for more details.

Of course, one interpretation of the push to install a "patch" is that this purported patch is merely a way of getting one specific sendmail clone installed as widely as possible. I'd guess that this "patch" is not, say, a set of source diffs, but is a binary. When you install it, you are replacing your current sendmail with a completely different program. Since the article refers to the Sendmail Consortium, this "patch" is probably a version of the original, sendmail. When you install it, you have reverted to a version of the old, bloated sendmail, which probably now has zillions of security holes waiting to be discovered.

There are so many inaccurate statements in this paragraph, I almost don't know where to begin. The only true statement in it is: "Since the article refers to the Sendmail Consortium, this "patch" is probably a version of the original, sendmail" The article is only a news story about the way the flaw has been reported. If you want information on the patch go to sendmail.org where you will find a description of the problem and a patch in source diff format and sendmail 8.12.8 which is the new release with the patch applied. Note that they only distribute it in source code format.

Please get a clue before your next post.