FreeBSD Users: Time To Patch Sendmail Again 39
Barrett Lyon writes "The FreeBSD Project just submitted this security advisory out to the masses: "FreeBSD-SA-03:07.sendmail, a second sendmail header parsing buffer overflow." It seems that the overflow is not limited to FreeBSD and that there is currently no workaround "other than not using sendmail." Yet another good reason to run Qmail!"
Re:Of course (Score:1)
Re:Of course (Score:1)
Say what you want about Dan, his product (qmail) hasn't changed for several years.
For something as "simple" as a MTA, there's no reason to recompile a fix every few months due to "yet another" buffer overflow. In the corporate world, this becomes doubly important.
Postfix is relatively secure, compared to sendmail.
Re:Of course (Score:2)
I can't think of any other popular opensource project having this many security scares in so few months lately...
Re:Of course (Score:2)
And that is part of the problem and one of the reasons why I still run Sendmail.
To get any decent function (outside of bare SMTP service) you have to add 3rd party patches and hope you get them in the right order...:(
BWP
Re:Of course (Score:2)
Just make sure you remember the right order for the next time you do it.
Or keep the results for reuse, or make a script to do the patches.
I'd personally avoid most 3rd party patches - since few people code as rigorously as DJB.
Re:Of course (Score:1)
Re:Why? (Score:1, Offtopic)
Of the BSD's you have mentioned, OpenBSD cannot run Mozilla, and has zero support for SMP. In many people's opinion, that makes it 'stale'.
Re:Why? (Score:4, Funny)
I'll be amused when OpenBSD can run Linux apps in FreeBSD compatibility mode faster than FreeBSD can.
Re:Why? (Score:2)
The SMP team just managed to get OpenBSD to spin up the second CPU the other day, the fact that it doesn't do any work yet is not important...
Or an even bigger set back for SMP under Open is that the SMP-branch is about a year out of sync with the rest of the project. When they eventually get around to implementing SMP they've still to deal with all the problems that NetBSD has (big kernel lock anybody?) as they've copied most of
Here is a good reason (Score:1)
Re:Here is a good reason (Score:2)
Re:Here is a good reason (Score:1)
Re:Here is a good reason (Score:2)
Re:How long (Score:1, Redundant)
Re:How long (Score:2)
Oooh I love posting in the bsd and apple sections. Unless you profess your undying love for the respective system, and refuse to say that feature F is not perfect, and could be improoved slightly, you'll be -1 trolled.
It really is so funny
Re:How long (Score:2)
I suddenly felt a disturbance in the force, like all my karma suddenly went away... Enough trolling for one day ;-)
Doh (Score:2)
Then you might as well be using qmail or postfix or some other alternative.
Re:Doh (Score:2)
This is the SAME HOLE as yesterday's story (Score:2, Funny)
Same hole as yesterday, fixed in Sendmail 8.12.9 (Score:4, Informative)
I mention this because the FreeBSD posting doesn't explicitly mention which version of Sendmail this affects, but it does link to the CERT article.
Some time delay (Score:2)
From my point of view, it was a day without email anyway while I moved up main machines several -pX releases. Not a real problem, but yet another reason to teach
Re:Some time delay (Score:1)
2. Note that this happened over a weekend.
3. The timing of events was largely driven by public disclosure of a vulnerability.
From where I stand (release engineering team) the security-officer (Jacques Vidrine) and his team did a pretty darned good job under the circumstances. Greg Shapiro of Sendmail, Inc. helped by committing the appropriat
sendmail upgrade howto (Score:2)
There is only one change needed: after getting sendmail built and installed, and my sendmail.cf set up from the bsd-4.4 default cm file with M4, local delivery wouldn't work, and gave this error:
stat=Deferred: local mailer (/usr/libexec/mail.local) exited with EX_TEMPFAIL
You fix this problem with:
chown root
chmod u+s
Exim (Score:3, Insightful)
It's extremely stable (we've been running it on our mail cluster for 326 days now with 0 seconds of downtime) and unlike sendmail it doesn't have a config file that looks like line noise.