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.
ISS? (Score:5, Funny)
Re:ISS? (Score:2, Funny)
Queen B
Re:ISS? (Score:3, Funny)
It's a Flash animation that demonstrates how to exploit the sendmail vulnerability. They went through all this trouble to make a flash animation just because they found a vulnerability? They must not find vulnerabilities very often and this is a big deal. Or maybe they just have an overstaffed graphics/web design department with too much time on their hands.
Re:ISS? (Score:2, Interesting)
Note the directory.. `mktg'. Sounds like marketing to me.
Re:ISS? (Score:5, Funny)
The vulnerability arises from a classic buffer overflow condition. Instead of illustrating how the different components of the Sendmail package interact, or what a buffer overflow is, the illustration shows an "evil e-mail" traveling across the wire to the poor defenseless server, which is then rendered helpless to the predations of the evil hacker dude. Other than the fact that hackers have desktop backgrounds with skulls on them, what is anyone going to learn from that?
(note: the author does get bonus points for using the canonical subject line, "owned!", although he could have gained more if he'd used proper L337-5p3@k and said "0wnz0rED!")
Re:ISS? (Score:2)
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.
Re:Since no one else will say it... (Score:2)
Re:Since no one else will say it... (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.
Re:Since no one else will say it... (Score:2)
With Microsoft you could have trouble if you announce the vulnerability to the public before to Microsoft (as with most vendors). The "normal" MS vulnerability announce is when they finally do the fixes, so is within 0 hours of being announced .)
That should be right now the trend on when announce problems, but last apache vulnerability, if I remember well, was announced before apache had a fix because it was not adviced the right people, if I remember well, but anyway, even with this, the fix was out a few hours later
Re:Since no one else will say it... (Score:3, Interesting)
Microsoft hasn't always been good about doing this, though, and has sometimes relied upon security via obscurity. But every single mass vulnerability exploited in the past year (especially things like Slammer) has made use of holes that were patched months or even YEARS ago. Pitiful admins are the ones to blame in these instances, not MS.
What? (Score:3, Funny)
Re:What? (Score:2)
You didn't think that with all those viruses running around and combining in there that IIS WOULDN'T become sentient, did you?
Re:What? (Score:3, Funny)
Re:What? (Score:2)
So, it seems that I'm not the only one who's expecting it?
Cross Upgrade to QMail (Score:4, Informative)
Re:Cross Upgrade to QMail (Score:2, Informative)
Re:Cross Upgrade to QMail (Score:5, Interesting)
I can't set up per-user mail filtering with different tools (some of my users like maildrop, some still have working procmailrc recipes that they don't want to ever have to touch again, and that means not converting to maildrop), the MySQL backend is shitty and doesn't support per-user procmailrc files anyway (for vhosting setups, which is the only place it's really useful).
qmail really is the shit. It's a bit more finicky to install, yes, but the documentation for installation is good, and I've never had to touch a running qmail server except for the rare occasion when it ran out of disk space. qmail is very much a 'set-up and forget' technology; I have qmail servers that I haven't needed to patch for ANY sort of exploits for years.
Postfix is only slightly more flexible in some ways (for example, the MySQL backend) but those ways aren't difficult to integrate into qmail; it's just that nobody's bothered to do it yet. Also, djb's daemontools suite makes running Courier bearable.
Re:Cross Upgrade to QMail (Score:2, Informative)
I'm really confused about what you mean by this? Although I've never set it up like this, why can't you simply put maildrop in UserA's .forward and procmail in UserB's .forward?
Re:Cross Upgrade to QMail (Score:4, Informative)
Re:Cross Upgrade to QMail (Score:2)
Re:Cross Upgrade to QMail (Score:2)
Isn't that kind of like saying that Tony Stewart won the Nascar championship using a customized Chevy?
I mean, if you customize, it just naturally follows that it can do anything.
Re:Cross Upgrade to QMail (Score:2)
I mean, if you customize, it just naturally follows that it can do anything.
Microsoft certainly has enough resources to modify their own mailserver software to any degree imaginable yet still run a modified qmail on FreeBSD(IIRC)... and Balmer still says "We eat our own dogfood." Lying pig.
Re:Cross Upgrade to QMail (Score:3, Interesting)
QMail is fine for a four- or five-user machine, but the installations who currently require Sendmail's power for their mail service needs would likely be happier with Postfix [postfix.org]. It's far more powerful than QMail, while still being easy to set up and use.
My 40000 users qmail servers are running very well. Never been down once in 6 month and currently serving 100k messages a day. And thats on only two mail servers. So what is so technicaly wrong with qmail?
Re:Cross Upgrade to QMail (Score:5, Funny)
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:Cross Upgrade to QMail (Score:3, Interesting)
Sendmail is version 8.12.8, released last month. qmail is version 1.03, and has been for well over four YEARS.
What's technically wrong with sendmail? Apparently, a whole BUNCH of stuff.
Re:Cross Upgrade to QMail (Score:4, Informative)
Excuse me, but what the hell are you talking about? Would you care to support this statement in some fashion?
Moderators, shame on you for giving points to this unsupported drivel.
Unbiased readers: compare [cr.yp.to] and contrast [postfix.org] for yourself. Qmail and Postfix are basically feature-equivilant, have roughly comperable performance, and both have stellar security histories. Both have plenty of 3rd-party tools to automate stuff like virtual domains, catch-all users and the like; both integrate nicely into a number of webmail and pop/imap servers.
Deciding between the two is largely a matter of taste: qmail's many small config files versus postfix's few large ones; different methods of handling aliases; etc etc etc.
Re:Cross Upgrade to QMail (Score:5, Informative)
One advantage of Postfix over qmail is that Postfix, from the outside, looks a lot more like Sendmail (which, if you're migrating, is a good thing).
There's also a moral angle. Qmail is not Free Software (as djb does not allow publication of modified versions), while Postfix is Free (though GPL-incompatible) Software. Also, Wietse Venema is a better human being (aka not a hypocrite) like djb. For those reasons, I will never use qmail, and I advise all others to not use qmail.
Re:Cross Upgrade to QMail (Score:3, Interesting)
This is not necessarily true [cr.yp.to]. Qmail has officially supported tools to make it look indistinguishable from sendmail for 90% of all users. (e.g. support ".forward" files and
Qmail is not Free Software
This is true. Personally I think it's idiotic to consider that to be a "moral" issue, but whatever: assess your needs and choose the appropriate tool.
Wietse Venema is a better human being (aka not a hypocrite) like djb. For those reasons, I will never use qmail, and I advise all others to not use qmail.
This is stupid.
Eric Allman is a nicer guy than Wietse and Dan put together. Hell, probably nicer than the product of Dan's congeniality to the power of Wietse's social skills. I've hung out with him at Usenix conferences, and if I lived in the same area I'd probably invite him to parties.
I still wouldn't run sendmail on a bet.
DJB is an abrasive asshole. I've called him a sociopath directly on at least one occasion. I wouldn't want to be trapped at a cocktail party with him, and if I had a daughter I wouldn't want to date her.
I still ran qmail at companies that I had actual money invested in, because the code is that good.
Cutting off your nose to spite your face is stupid when you're the person who'll get called at 3 in the morning when your box gets rooted. Pick software based on quality and utility, not personality.
(I'd call qmail and postfix to be about equally matched for quality, so it comes down to a question of features and style preference for me.)
Re:Cross Upgrade to QMail (Score:3, Interesting)
I should have been more clear. Postfix and qmail are (as you note) basically equivalent (there are edge cases where one is significantly better). Thus, when deciding which to use, I consider (among other things) which one I'd rather give the satisfaction of having his software be used. That person is Wietse.
Re:Cross Upgrade to QMail (Score:2)
By the way, Rediffmail, which has 15 million users last time I checked, runs Linux and qmail.
-russ
Re:Cross Upgrade to QMail (Score:5, Informative)
Re:Cross Upgrade to QMail (Score:5, Funny)
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.
Re:Cross Upgrade to QMail (Score:2)
Re:Cross Upgrade to QMail (Score:5, Interesting)
Re: Exim as alternative to Sendmail (Score:5, Informative)
The two credible alternatives are Postfix and qmail. Both Postfix and qmail seperate the mail system into a number of fine-grained roles, each with a seperate UID and control over a specific set of resources. Regardless of what vulnerabilities are harbored by the Postfix or qmail code, a bug in either is very unlikely to leave an attacker with root access, or even control over the mail system.
In addition to a coherent architecture that addresses security, both Postfix and qmail were implemented from the ground up to resist textbook attacks like file races, buffer overflows, and metacharacter problems. When I briefly audited Exim [google.com] in 1997, it was immediately clear to me that Exim could not make the same claim.
Yes! (Score:5, Funny)
Re:Yes! QWZX (Score:3, Funny)
Re:Yes! QWZX (Score:3)
Haters come out! (Score:5, Funny)
Re:Haters come out! (Score:2)
Switch to Postfix !
Re:Haters come out! (Score:5, Funny)
Re:Haters come out! (Score:3, Funny)
Use Mail. You know
Between the terrorists and Bill Gates
Re:Haters come out! (Score:3, Funny)
(Pssst. poor as it may be, this is humor)
-JungleBoy
Recompiling now....while you're at it... (Score:5, Informative)
APPENDDEF(`conf_sendmail_ENVDEF', `-DMILTER')
Use CPAN to install SpamAssassin:
perl -MCPAN -e shell;
install Mail::SpamAssassin
quit
Then compile spamass-milter. Add this to your sendmail.mc file:
INPUT_MAIL_FILTER(`spamass-milter', `S=local:/var/run/spamass-milter.sock,F=')
Make sure that spamd, spamc, and spamass are all running as daemon processes, and if spamd fails add this to the beginning of the script:
$Sys::Hostname::host = 'my.hostname.com';
Ah...auto spam filtering. Tweak the files in
Is spamass-milter ready for prime time yet? (Score:2)
RedHat Network Rules (Score:5, Interesting)
Re:It won't rule for much longer... (Score:3)
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
An up2date server clone... (Score:3, Interesting)
...is under development here [tigris.org].
OpenBSD? (Score:2, Interesting)
Not bad once you think about it.
- Eric
Re:OpenBSD? (Score:2, Insightful)
Re:OpenBSD? (Score:2)
Re:OpenBSD? (Score:2, Funny)
Oh no... (Score:2, Funny)
Looks like it's time to add another three thousand pages to the Sendmail manual.
Open Source All (Score:2, Insightful)
A better Fix (Score:3, Offtopic)
A remote root exploit for the maybe more used mail server in the planet, one that can bypass firewalls if connection with the smtp server is possible, or even with smtp proxies in the middle, is a nasty one. Specially when as it is so widely deployed, even with the months "needed" to make a worm of it, a big amount of vulnerable server will remain.
At least it cold be used as an opportunity to fix mail servers which have administrators that don't care and are used as open relays.
Bypasses _some_ SMTP proxies (Score:5, Informative)
However, there are a number of SMTP proxy applications which do "deeper" checking of the message, and which would serve to protect vulnerable servers. Most of these are expensive, and slow.
Realistically, my solution for my servers is as follows:
My problem right now is that the company-accepted standard for spam filtering is milter based, and can only run under Sendmail. If I "hide" the sendmail listener behind another MTA that directly faces the Internet, then my spam filter is ineffective, as I would lose all of the benefit of being able to reject senders and messages based on the remote IP (RBL) and other checks.
The worst drawback of putting the anti-spam Sendmail filter "inside" is that since the message has already been accepted by one of our mail servers, if the spam filter chooses to reject the message, it needs to generate and deliver a "bounce" message, just in case the reject was a "false-positive", to notify the sender.
If the spam filter is on the outermost edge and can talk directly to the sending host, it can return a 5xx "reject" SMTP result code, and it's up to the sending host to generate and deliver the bounce.
Re:Bypasses _some_ SMTP proxies (Score:2)
$0.02USD,
-l
Salt in the wound (Score:5, Funny)
Re:Salt in the wound (Score:2)
Talk about rubbing it in.
I think they are just focusing their multimedia marketing to the scale of the problem. Think of the animation requirements of doing this for the SQL slammer. You'd go from one to 80 bazillion moving objects in less than 2 seconds.
I'm sure that eventually multimedia presentation software will catch up with the visualization requirements of the security problems in other platforms.
1337 (Score:5, Funny)
CAN-2002-1337 to this issue
heh. leet.
Fed up with sendmail. (Score:3)
I'd like something I can have up and running and doing EVERYTHING my sendmail config does in a few hours, at most.
Does something like this even exist, or am I stuck wasting a day either reinstalling sendmail or installing some other bloated, shitty, difficult-to-configure MTA?
- A.P.
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
sigh (Score:3, Insightful)
Proof (Score:2, Funny)
Finally, proof that the work being in space is actually accomplishing something useful for everyone
Slackware (Score:4, Informative)
Running Mail As Root Long Considered Harmful (Score:5, Interesting)
Leave aside the issues of whether it's safe to run a massive program written in C with annually discovered buffer overflow exports, or the usual sendmail-basher fun about the need for Turing-machine-complete config files. If you don't want to get rooted, don't run stuff as root. Bad enough that it's possible to get rooted by non-privileged processes that leave trojans around where root can be tricked into running them, or use non-root processes to read files that maybe they shouldn't be reading (e.g. tricking a group-mail MTA into reading people's mailboxes.)
Re:Running Mail As Root Long Considered Harmful (Score:5, Interesting)
Why not take the SecureOS approach, and run the SMTP listener in a restricted capabilities role, where all your SMTPd can do is "accept()" TCP sessions on port 25, request DNS lookups, and queue messages to disk?
Most of my machines are on a non-capability-enabled OS, so I run qmail-smtpd in a chroot environment as a non-root UID. I've tried to take the same approach with Sendmail, but it requires considerably more effort and more system resources (launching new 'sendmail' instances from tcpserver is one culprit).
Re:Running Mail As Root Long Considered Harmful (Score:2)
|
--- This one has apparently been drawn into her madness.
"Do not get involved with sendmail. She is an exotic lover, whispering delicious promises in your ear, flashing her dark eyes at you. But she is insane, and will draw you down in to her madness."
-Andrew Molitor
Re:Running Mail As Root Long Considered Harmful (Score:3, Funny)
Uhm. Remind me. What exactly are its good points?
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.
Read as ISS discovers Hole... (Score:5, Funny)
Of course the Russian Soyez could always come to the rescue.
M@
FreeBSD also patched. (Score:3, Informative)
-- Brooks
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]:
The Sendmail Remote Exploit of the Week (Score:3, Insightful)
Great... (Score:2)
All that aside, I have but one thing to say, I'm glad I use postfix.
Is it inherently more secure? Maybe, who knows. Is it more obscure and presents a smaller profile to attackers? Is it less used so a worm would targetted at postfix would have a poor propogation environment?
This is the good thing about having a good size set of nearly equivalent applications to perform the same function. If systems made use of a more diverse set of operating systems, then any particular Windows, IIS, Apache, Sendmail, etc. worm wouldn't be so catastrophic..
Of course, on the flip side, if you were running IIS when a massive IIS worm hits the net, people at least understand the problem, if your postfix mail server gets hit with a postfix attack, people corresponding with you won't see a front-page cnn article talking about it like they do IIS worms, so they will be less understanding...
At the risk of sounding a bit negative... (Score:2)
*yawn*. What else did you expect from sendmail? With the viable (usually BETTER) alternatives out there, anybody still using sendmail kind of gets what they deserve.
steve
FBI top 20 list still applies (Score:2)
It's been nearly six months since the SANS/FBI "Top 20" Internet vulnerabilities list [sans.org] was updated. Looks like it's time for another update as the sendmail section contains the following line:
Is this latest considered 'high' vulnerability? If you have never read this report, I highly recommend it for both Unix and MS system admins.
Department of Homeland Security? (Score:5, Interesting)
THE FLAW WAS ACTUALLY found in late December, but not revealed until today. That gave the Department of Homeland Security time to organize efforts that would protect against possible attacks, said Alan Paller, director of security research firm SANS.
[...]
Paller also said the Department of Homeland Security has become more proactive in dealing with critical software flaws that might impact national security or the critical functions of the Internet. "The government got involved in Code Red not when the vendor announced the vulnerability, but when the worm hit. That's the wrong time for the government to get involved," he said. "The right time is now, and to use the bully pulpit so a larger percentage of machines get the fix.
Does the open-source world really need the assistance or oversight of the Department of Homeland Security? That's just sort of... creepy.
Specifics on the exploit? (Score:3, Interesting)
others as well."
Sounds to me like they only tested on x86, and assume that it's exploitable on other platforms (a reasonable assumption, but an assumption nonetheless). I run one of the "others" and want to know if my installation is vulnerable, since it is a significant effort to build, test and install an upgrade so quickly. Furthermore, I want to know if the update removes the vulnerability. It is not possible for me to do any of this without sample exploit code, or a utility to scan/test for it.
Can anyone provide me with information about this? Posters to Bugtraq have been reluctant to provide this information, but I require it.
Re:why do people still use sendmail? (Score:3, Informative)
Have you ever try to run 2 instances of qmail on
one machine for exampe?
qmail is very rigid and unfriendly to make configuration tricks and connections to anything
not usual.
Re:why do people still use sendmail? (Score:2)
-russ
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: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.
Re:So what's new? (Score:2)
Since your statement cannot be disproved, it falls outside the realm of science, and goes into faith. So, did your god or gods tell you that? Or have you simply never run across a bug-free and exploitless program? Perhaps you should install qmail, if there's a dearth of well-written software in your life.
-russ
Re:Wouldnt this... (Score:2, Insightful)
Actually no... (Score:5, Informative)
Re:Wouldnt this... (Score:2, Informative)
Most recent large/popular distributions of *nix with an MTA installed tend to only listen by DEFAULT to the localhost for connections.
So NO as per OpenBSD's claim "Only one remote hole in the default install, in more than 7 years!" see "http://www.openbsd.org/" there is not a "remote root hole for OpenBSD users" in the default install.
If you have opened up Sendmail to the outside world it's YOUR responsibility to make sure its kept up to date and secure.
.
Re:Wouldnt this... (Score:2)
This vulnerability wouldn't be a remote hole in the default install.
Re:Wouldnt this... (Score:2)
Re:Just when they made me take down qmail... (Score:2)
-russ
C programmers already pay, except when they forget (Score:2)
> And despite popular opinion, the magic can be implemented without significant loss of efficiency. Imagine that. It's like
> free money.
Indeed, the checks that compilers for such languages (say, O'Caml) insert automatically are precisely the ones that these master C programmers say you must insert yourself -- array bounds checks, overflow checks, etc.
Of course, I second your sarcasm; programmers who can write large-scale buffer-overflow-free source code are indeed few in number. If anyone disagrees, can he explain why so much popular software written by our most heralded programmers has contained known buffer overflows in the past (and probably still to this day?) (ie, Linux kernel, OpenSSH, Quake I, II, III, Half-Life, Perl,
Re:OS X (Score:3, Informative)
(You'll have to hit ^c to exit back to the shell; invoking sendmail with -d causes it to wait for a message on stdin to process.)
Re:OS X (Score:4, Informative)
Apple also mentions it on their security updates [apple.com] page.
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.