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

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