Slashdot Mirror


FreeBSD Users: Time To Patch Sendmail Again

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!"

22 of 39 comments (clear)

  1. This is the SAME HOLE as yesterday's story by dhunley · · Score: 2, Funny

    Doesn't anyone on the /. team read before posting? This is the same hole that made the front page yesterday concerning the char to int conversion. Just cause one of the BSDs finally acknowleged the issue, it deserves *another* front page story? Jeez... upgrade to sendmail 8.12.9 and get on w/ your life...

  2. Re:Of course by Rheingold · · Score: 1

    The previous poster is not a troll! His facts (#1 & #2) are correct and his opinion (#3) is shared by many.

    --
    Wil
    wiki
  3. Same hole as yesterday, fixed in Sendmail 8.12.9 by Phaid · · Score: 3, Informative

    Just in case anyone's wondering, this is the same hole reported on Slashdot yesterday and reported in this CERT advisory.

    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.

  4. Some time delay by palfreman · · Score: 1
    What is interesting to me is that there has been quite a delay - over a day, so far as I can tell, between this sendmail update going into the CVS tree, first into -CURRENT, the following very quickly into -STABLE and the various RELANG 4_x out there, and it appearing as first a FreeBSD security advisory, and being officially announced by email.

    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 myself how to use another mailserver than sendmail, as it seems to get this kind of thing quite often.

    1. Re:Some time delay by bmah · · Score: 1

      1. It takes time to prepare security advisories. The security-officer team (of which I am not a member) likes to check facts and test things before issuing them.

      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 appropriate changes to ten (count 'em, ten) different CVS branches.

  5. sendmail upgrade howto by ubiquitin · · Score: 1

    First start with the tutorial here

    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 /usr/libexec/mail.local
    chmod u+s /usr/libexec/mail.local

    --
    http://tinyurl.com/4ny52
  6. Re:Why? by RLiegh · · Score: 3, Funny

    And yet FreeBSD can run Linux apps under Linux emulation faster than Linux can. I find that pretty funny.

    I'll be amused when OpenBSD can run Linux apps in FreeBSD compatibility mode faster than FreeBSD can.
  7. Re:Of course by dhall · · Score: 1

    I can "feel good" right up until the point where I'm patching my MTA yet again.

    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.

  8. Re:How long by isorox · · Score: 1

    dont start me on windows :)

    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

  9. Exim by phaze3000 · · Score: 2, Insightful

    For those out there looking to replace sendmail, I suggest Exim.
    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.

    --
    Blaming GW Bush for the Iraq war is like blaming Ronald McDonald for the poor quality of food.
  10. Here is a good reason by Sevn · · Score: 1

    At least, the reason real admins run FreeBSD. A fanboy like yourself probably wouldn't understand.

    --
    For every annoying gentoo user, are three even more annoying anti-gentoo crybabies. Take Yosh from #Gimp for example.
    1. Re:Here is a good reason by 42forty-two42 · · Score: 1

      The Linux uptime counter rolls over after just over a year - those uptime charts will be inaccurate. For true uptime measuring, touch a file at boot.

    2. Re:Here is a good reason by someonehasmyname · · Score: 1

      so if Linux is so great, why can't they fix a stupid uptime counter?

      --
      Common sense is not so common.
    3. Re:Here is a good reason by 42forty-two42 · · Score: 1

      It would break backward compatibility with numerous applications, not to mention nvidia's binary drivers (IANAKD). It'll probably be fixed when time_t's go 64-bit.

  11. Re:Of course by cyb97 · · Score: 1
    I thought anything was secure compared to sendmail *grin*.

    I can't think of any other popular opensource project having this many security scares in so few months lately...

  12. Re:Why? by cyb97 · · Score: 1
    OpenBSD doesn't have zero-support for SMP... don't you follow kerneltrap ?
    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 their stuff from Net...

    All of these reasons kind of scare me away from Open for good as I'm more or less out of non-MP servers and OpenBSD doesn't really lend it self well to the desktop...

  13. Re:How long by cyb97 · · Score: 1
    I an even better solution would be to have sendmail revamped and fixed once for all... get rid of those pesky line-noise style configs, all the still latent buffer-overflows, all the trouble with inetd+sendmail and *real* load, and blahblahblah...

    I suddenly felt a disturbance in the force, like all my karma suddenly went away... Enough trolling for one day ;-)

  14. Re:Of course by soup4you2 · · Score: 1

    Postfix is great.. Configure Postfix + spamassasin + amavis + Qmail LDAP + Procmail And you got yourself one badass mailserver

  15. Re:Of course by bovinewasteproduct · · Score: 1

    Say what you want about Dan, his product (qmail) hasn't changed for several years.

    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

  16. Doh by TheLink · · Score: 1

    With all the changes, it wouldn't be or look like sendmail.

    Then you might as well be using qmail or postfix or some other alternative.

    --
    1. Re:Doh by cyb97 · · Score: 1

      I'm already using qmail, works like sendmail in the sense it delivers email and differs in the sense that it's not broken, borked or configfiles that look like /dev/urandom

  17. Re:Of course by TheLink · · Score: 1

    Well you only have to do it once during install if at all.

    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.

    --