ISS Discovers A Remote Hole In Sendmail 481
randal writes "A security vulnerability in the Sendmail Mail Transfer Agent (MTA) has
been identified by ISS. This bug can
give an attacker the ability to gain remote root access to the
targeted system. There is no known exploit code of this vulnerability in
the wild at this time, but everyone should upgrade immediately. This
issue affects all versions since 5.79. Open Source sendmail users can
get source for the newest version (8.12.8) as well as patches for 8.9,
8.11, and 8.12 from
sendmail.org.
Commercial Sendmail customers can find patches at
sendmail.com/security.
Most major OS vendors will be releasing patches immediately." Update: 03/03 19:23 GMT by T : Reader Patchlevel points out that RedHat and OpenBSD have already issued patches.Update: 03/03 20:45 GMT by T : Reader Claude Meyer links to an update from SuSE, too. Update: 03/03 22:52 GMT by T : djcatnip points out that Apple has released a software update to patch OpenSSL and Sendmail for Mac OS X 10.2.4, and the Slackware site says they have updated to 8.12.8 as well.
Since no one else will say it... (Score:2, Insightful)
Let's also not forget that it's not only Microsoft that has these problems. I expect everyone who normally bitches and moans at how awful Microsoft security it to bitch and moan just as much because of this sendmail hole.
Anything less is hypocrisy, but then again, this is Slashdot, where hypocrisy is elevated to an art form.
Open Source All (Score:2, Insightful)
Re:Since no one else will say it... (Score:2, Insightful)
Re:So what's new? (Score:3, Insightful)
Hate to break it to you, but ANY program of medium to large size will never be bug free and exploitless. It's the nature of complicated projects.
Re:OpenBSD? (Score:2, Insightful)
Re:Since no one else will say it... (Score:5, Insightful)
Apparently you didn't read the article. "Initial vendor notification: 1/13/2003." The vendor was notified a month and a half ago.
Re:Since no one else will say it... (Score:5, Insightful)
Then you haven't been looking hard enough. Not that Microsoft always gets fixes out within 24 hours, but neither does OSS. In both camps some bugs are harder to fix and verify than others.
Monoculture (Score:3, Insightful)
Now this is the obligatory "monoculture" is bad post.
Although this post is made somewhat jokingly, it is an important issue. Hopefully this won't become too much of a clich\'e.(I'm sure LWN will do an article on it. :>)
Some alternatives can be found on the Google directory [google.com]:
Re:So what's new? (Score:5, Insightful)
Find a bug in qmail that allows an outsider to do so much as change file permissions of a file he should not be allowed to. There has not ever been one, and there is cold hard cash offered.
Secure code is not impossible. However, if you start with sendmail or BIND and try to achieve security, well, good luck.
The Sendmail Remote Exploit of the Week (Score:3, Insightful)
Re:Wouldnt this... (Score:2, Insightful)
Re:Fed up with sendmail. (Score:4, Insightful)
* Shit easy to configure.
* When something does go to custard I can understand the logs.
* Stable, appears to be secure, yaddah yaddah yaddah.
Not convinced by the "plug in replacement" nature of it, I also don't know what your sendmail config does so can't comment.
It's worth a go. Debian's worth a go too.
Dave
Re:reconfig (Score:2, Insightful)
m4
You can nearly always move the
sigh (Score:3, Insightful)
What happens when a server process runs as root (Score:2, Insightful)
in it is a root vulnerability. For extra bonus insecurity points,
write it in a language that doesn't protect you from memory managment
errors, and then have a security philosophy that says, in effect,
"if the environment isn't exactly what we want it to be, any
insecurities aren't our fault".
I've been saying for months that this would happen. It will happen
again, too. It's high time to retire sendmail and adopt other
solutions.
Re:Cross Upgrade to QMail (Score:5, Insightful)
Did you fail to notice that this entire article is about yet another remote sendmail root exploit?
Other things that are wrong with sendmail:
- Horrible, horrible resource utilization issues. Fork a new copy of the whole goddamn multimegabyte
- Configuration is a bad joke. The M4 macros are a bandaid slapped on top of a sucking chest wound. The web-based configurators in the commercial sendmails are a gold star slapped on top of the bandaid. Quick: name the four different "MASQUERADE" options supported by sendmail.mc, and explain how they differ and in what situations you would use which combinations of them. Can't do it without referring to the manual? Don't feel bad, neither can I, and I used to manage sendmail for a living [mail.com].
- Incredibly crappy delivery performance. The hashed queues in recent sendmails have somewhat alleviated this, but qmail, postfix and exim still trounce sendmail for remote delivery speed.
- No VERP support.
- Last I checked (circa 8.11), SSL/TLS/ASMTP was a painful joke, requiring an incredibly fragile collection of third-party libraries to even stand a chance of working, which it usually didn't. (Compare to Courier, which includes all of the above out of the box.)
- Sendmail's monolithic design makes _any_ extensions into a bleeding nightmare. Compare to qmail or postfix, where if you don't like one component (the smtp daemon, the delivery agent, etc etc) it's a snap to swap it with one of your own.
- Bugs, bugs, bugs, bugs, bugs, bugs, bugs.
And that's just off the top of my head. Google for "sendmail problems" and see for yourself.
Re:Since no one else will say it... (Score:2, Insightful)
I would think that it would be a given nobody is running Sendmail anymore. I guess not. How many times do you need to be kicked in the nuts before you realize that you should avoid something so buggy and complex as Sendmail? If you can't read a god damn config file and understand it without a 500 page O'Reilly book then something is horribly wrong. Switch to Postfix or qmail and sleep better at night. I'd trust my Postfix or a qmail setup anyday over Sendmail for crying out loud.
Wrong. Non-root sendmail is possible. (Score:3, Insightful)
Perhaps you haven't actually looked at sendmail since 1983?
Sendmail certainly does not need to run as root for most of its operations anymore. Read the file "sendmail/SECURITY" in the source code distribution for all the details.
There are of course a few small things that any mail transport agent will need root access for, primarily for opening port 25., local mail delivery, etc. But the basic quering and mail handling operations don't require root, and neither does sendmail require root for that. Plus sendmail has separated the mail transport function from the local mail delivery/submission function too. And furthermore you can write your own custom sendmail filters (milters [milter.org]) as separate processes from sendmail and can run as any user you like. And if you don't require local delivery, there's no reason you can't chroot jail it either.
It amazes me how often people spout off about their favorite non-sendmail program being ultimately secure and sendmail being ultimately vulnerable to everything. Nothing is that black and white. True sendmail may have a long history, but it has by no means stood still. And furthermore security vunerabilities are possible in every mail program no matter how much it is evangelized as being "secure".
If you don't need the power of sendmail (and most people don't) and it intimidates you then fine use what works for you. That's a legitimate functionaility decision. But just because there is one buffer overflow bug doesn't mean that the whole of sendmail is junk. It got fixed didn't it? There are many things that sendmail does much better than any other alternative out there, especially for very large and complex sites.
Re:It won't rule for much longer... (Score:3, Insightful)
There's a reason they've gone to the current configuration, and the future changes in their product line, of requiring more cash and providing longer lifetimes for "professional" releases - maintaining 1200 packages/release is a lot of work. And if you screw something up, or you're late with a package, people bitch.
Red Hat is a company. Before they released their EOL status, they looked at what their customers are running. Hell, they've got a million points of data in the RHN database to look at. If 6.2 made up a significant amount of customers, I would imagine they would have been more lenient.
But when the bulk of your customers are running the latest or one-off release, how can you spend time and money supporting elderly releases? We're not talking about just the kernel; we're talking about ALL THE PACKAGES Red Hat puts in their distro. Someone has to sit down and do that. And that takes time away from the bulk of their business - newer releases.
I certainly hope you find someone who will package patches for you. But if you don't have the time to upgrade, how do you have the time to package everything you're running? I have the same problem with a box i work with. Users don't want downtime, now the box is so far out it needs to be taken off the network.
Can't blame Red Hat for that. It's not like they have the boundless resources of other companies. Having said that, though, there is no reason why the two dozen or so 6.2 users that are still around couldn't clammor with Red Hat to allow them to post a channel on RHN. They may not let you, but at least they'll know you're out there.
--mandi
Re:Department of Homeland (in)Security? (Score:2, Insightful)
Okay, that's probably not the best example.
Re:from 5.79 (Score:3, Insightful)
In 1988, when the Morris worm hit, you could log into many systems as guest. We telnet'd everywhere.
So if your window (sendmail) is open, someone could walk in, but mostly we had no locks on the doors.
Since then, sendmail's undergone pretty freaking major rewrites.
The last remote exploit was 1997, AFAIK. Before postfix came out.
It offers MORE security in many ways.
I can use SMTP over SSL (TLS). Ask djb about support in qmail for that qmail patch. I've seen a few good rants from him about using qmail with any patches at all. You must use it unchanged from 1997.
patch your binary, move on. Just like last summer with SSL and SSH and Apache. Just like every week with Exchange.
Re:DJB is an ass. (Score:3, Insightful)
No, that's the only reason people deal with him at all! Myself I choose to ignore him, Vietse Veenema is just as smart and a really nice guy to boot.