Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×

Sendmail Hit by Data Interception Flaw 208

Posted by CowboyNeal from the bumps-in-the-night dept.
ricepudd writes "Computer Weekly reports that Internet security researchers have discovered a serious flaw in Sendmail. The flaw could allow remote attackers to take control of users' PCs. The Sendmail Consortium urged users to upgrade to version 8.13.6 of the software, which contains a fix to the problem. Computer Weekly seems to think that the fact that the Windows version isn't affected will help curtail the threat."
This discussion has been archived. No new comments can be posted.

Sendmail Hit by Data Interception Flaw More

Sendmail Hit by Data Interception Flaw

Comments Filter:

  • Reality check: (Score:4, Funny)

    by Anonymous Coward on Thursday March 23, 2006 @07:27PM (#14984682)
    Ah, the WINDOWS version is NOT affected! How ironic!

    • Re:Reality check: (Score:5, Funny)

      by Anonymous Coward on Thursday March 23, 2006 @07:36PM (#14984740)
      it's safer running the windows version of something?

      truly, it is the end times
      • Indeed. All 3 people who run the windows version of sendmail (of all things...) can rest easy.

        Am I the only one who thinks the idea of running sendmail on windows is downright strange? I've used postfix for years... I know you can come up reasons to run sendmail on windows, but jeeze... That's like finding a reason to run activex on linux.

        • Am I the only one who thinks the idea of running sendmail on windows is downright strange? I've used postfix for years...

          Running sendmail on unix is strange frankly. How many security issues have been found in it? When there are more secure alternatives like Postfix (apparently a drop-in replacement), or Qmail (zero flaws found to date), or Exim, there's really no need to keep installing the old timer.

  • Flaw seems unexploited (Score:5, Informative)

    by rg3 ( 858575 ) on Thursday March 23, 2006 @07:27PM (#14984685) Homepage
    As everyone who follows the Slackware changelog, new packages were available yesterday. It seems there is still no exploit for this flaw, and it's somehow hard to exploit. That's the impression I got from the changelog entry. I'll paste it here:

    n/sendmail-8.13.6-i486-1.tgz: Upgraded to sendmail-8.13.6.
                  This new version of sendmail contains a fix for a security problem
                  discovered by Mark Dowd of ISS X-Force. From sendmail's advisory:
                  Sendmail was notified by security researchers at ISS that, under some
                  specific timing conditions, this vulnerability may permit a specifically
                  crafted attack to take over the sendmail MTA process, allowing remote
                  attackers to execute commands and run arbitrary programs on the system
                  running the MTA, affecting email delivery, or tampering with other
                  programs and data on this system. Sendmail is not aware of any public
                  exploit code for this vulnerability. This connection-oriented
                  vulnerability does not occur in the normal course of sending and
                  receiving email. It is only triggered when specific conditions are
                  created through SMTP connection layer commands.
                  Sendmail's complete advisory may be found here:
                  http://www.sendmail.com/company/advisory/index.sht ml [sendmail.com]
                  The CVE entry for this issue may be found here:
                  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE- 2006-0058 [mitre.org]
                  (* Security fix *)

    • Re:Flaw seems unexploited (Score:5, Informative)

      by molnarcs ( 675885 ) <csabamolnar AT gmail DOT com> on Thursday March 23, 2006 @07:45PM (#14984782) Homepage Journal
      FreeBSD also has details in their security notification. [freebsd.org] Those guys are fast - if you want to have up to date info on security vulns., FreeBSD has them (usually with patches) way before the news hits slashdot ;) For those who are asking [slashdot.org] for line numbers, just take a look at the patches included. Or better, here is a kompare screenshot [unideb.hu].

      • Re:Flaw seems unexploited (Score:5, Informative)

        by cperciva ( 102828 ) on Thursday March 23, 2006 @08:57PM (#14985115) Homepage
        FreeBSD also has details in their security notification. Those guys are fast - if you want to have up to date info on security vulns., FreeBSD has them (usually with patches) way before the news hits slashdot

        We do our best. :-)

        Seriously though, CERT told us that the embargo was going to end at 16:00 UTC, so I had a shell window open with a series of "cvs commit" commands waiting for me to hit <enter>, a window with the commit messages I was going to use, a window with the advisory text waiting for me to type in the correction times, a shell window open to ftp-master.freebsd.org waiting for me to copy the patches into the right directory...

        When you have two weeks advance notice, it's easy to get advisories out soon after the embargo ends -- the hardest part of the process was making sure that I'd be awake at 8:00 AM (PST).
        • You need a secure revision control system where changes you check in can be encrypted. So you could check in the fix as soon as it's discovered, but only a small number of people who know the key could check out the new version (and make further patches, etc). Then at 16:00 the key gets published to the rest of the world and everyone can then update.

    • Re:Flaw seems unexploited (Score:5, Informative)

      by Bacon Bits ( 926911 ) on Thursday March 23, 2006 @10:30PM (#14985545)
      It seems there is still no exploit for this flaw, and it's somehow hard to exploit.
      If you read Sendmail's complete advisory, you can see that the vulnerability requires the exploitation of a race condition. You have to submit a request, and then before that one times-out submit another malformed one.
  • Can you tell us the file and line number that causes the problem and the mitigating circumstances under which it occurs. Jesus, it is open source ya know.

    • Re:Gee, Full Disclosure would be nice (Score:5, Informative)

      by LiquidCoooled ( 634315 ) on Thursday March 23, 2006 @07:53PM (#14984828) Homepage Journal
      If you knew that you would be 99% of the way to solving the bug.
      As it happens, someone already posted [slashdot.org] a screenshot of the BSD version of the fix.

      A single line of c:

      t = 0;

      Inserted between lines 147 and 148 of file fflush.c appears to be the fix (reset a mem pointer just use above).
      I don't vouch for it and haven't even bothered to look at context or even if its the actual fix required, however its not like it was hidden and you don't need to get uppity about it.

      Incidentally, its such small code modifications that can bring great amounts of money to maintainers of corporate code that the monkeys don't understand what they are paying for.

      "But you only changed 1 line"
      "Yer, but that one line makes it work now...."
      • I hark from a time when that kind of information was front and centre in the security advisory. I'm old, I have an inalienable right to get uppity.
      • Considering the size, age and complexity of the sendmail code base, there can't be too many people who know which line to patch. Sendmail is ugly and unmaintainable, and needs to be rewritten from the ground up. Just ask sendmail. [sendmail.org] (The design document reminds me strongly of postfix. And no more sendmail.mc, yay!)
      • It's kind of like the furnace repair guy story. He came to fix a furnace and gave it a whack with a hammer. The whack worked, and he submitted a bill for $100. When the incredulous homeowner complained at being charged so much for a simple hammer whack, the repair guy noted that the whack cost him only $5 - the additional $95 was for knowing where to hit the furnace.

        Same concept applies to coding.
        • I know from bitter experience that while a bug fix may involve only a small handful of lines (or even a single one), it could take literally days to work out what line is at fault.

          My favourite story is one that was related to me a couple of years ago by a coworker. A previous job he'd had was at a place that wrote software for EPOS systems - tills mainly. They received a bug report, and one of the guys was assigned to track down the fault.

          To cut a long story short, he spent six months working on it, until h
          • 5 minutes and one line of code

            The idea in this case isn't so much the time involved as the number of lines of code.

            The analogy to the furnace repairman was more of how much observable work went on and the end result. He may still have spent an hour or whatever sounds appropriate looking at the furnace before deciding where to whack it. But a single hammer whack fixed the problem, in much the same way that a change to a single line of code can sometimes fix a bug. What might be difficult, depending on how
      • A single line of c:

        t = 0;

        Inserted between lines 147 and 148 of file fflush.c appears to be the fix (reset a mem pointer just use above).

        If you bothered to check patches (available on sendmail.org), you'd see that there is more in a patch than a single line.
      • Changing one line: $5
        Knowing which line to change: $1000

  • No link to actual advisory in summary or article (Score:5, Informative)

    by doorbot.com ( 184378 ) on Thursday March 23, 2006 @07:29PM (#14984695) Journal
    I believe this is the actual advisory:

    http://www.frsirt.com/english/advisories/2006/1049 [frsirt.com]

    A critical vulnerability has been identified in Sendmail, which could be exploited by remote attackers or network worms to take complete control of an affected system. This flaw is due to errors in the "setjmp()", "longjmp()" and "sm_syslog()" functions that do not properly handle certain asynchronous signals, which could be exploited by remote unauthenticated attackers to execute arbitrary commands by sending specially crafted requests to the SMTP port.

  • can someone explain... (Score:2, Insightful)

    by Churla ( 936633 )
    The difference between "Serious" and "Highly Critical"...

    (Yes, tongue is firmly in cheek here...)

    Why would this qualify as serious if there isn't even a known way to exploit it yet? Or was there one in there I missed?

  • Ah! (Score:4, Funny)

    by O'Laochdha ( 962474 ) on Thursday March 23, 2006 @07:33PM (#14984716) Journal
    So the FBI was wiser than we thought in withholding e-mail accounts...

  • The FreeBSD mailing list is a little less alarmist (Score:5, Informative)

    by micheas ( 231635 ) on Thursday March 23, 2006 @07:34PM (#14984721) Homepage Journal
    An email I received from the FreeBSD security mailing list seems to imply to me that this might be more of a concern for multi user systems.

    From: Claus Assmann <freebsd+security@esmtp.org>
    To: freebsd-security@freebsd.org
    Subject: Re: FreeBSD Security Advisory FreeBSD-SA-06:13.sendmail
    Date: Thu, 23 Mar 2006 10:31:20 -0800

    On Thu, Mar 23, 2006, Bigby Findrake wrote:
    > Does an attacker need network access to the machine, or does the attacker

    Yes.

    > merely need to be able to get an SMTP message to the machine?

    He needs to control the timeouts (AFAICT).

    _______________________________________________
    freebsd-security@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd- security [freebsd.org]
    To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"
  • Sendmail is a mail transfer agent that would run on mail relays or servers, not typically on a desktop, particularly not in a network server configuration, which as far as I could see was the vulnerable configuration.

    That the Windows version is or isn't vulnerable doesn't enter into it. I doubt that 1 in 10000 windows boxes would run an email server. (Okay somebody do the sales of Exchange divided by total Windows boxes and show me to be wrong. ;-)

    • Re:My PC? (Score:4, Informative)

      by YU Nicks NE Way ( 129084 ) on Thursday March 23, 2006 @07:39PM (#14984760)
      Windows has shipped with an SMTP server installed since Windows 2000. It's off by default in Server 2003 and in all client versions, and, I think, in 2000 Server, but it's there.

      What do you think the spammers use on their zombie boxes? Code they wrote themselves?
      • Thank you, I had forgotten that. I sit corrected. ;-)

        What do you think the spammers use on their zombie boxes? Code they wrote themselves?
        No, but I didn't think they actually used SMTP for anything. Isn't it all IRC traffic? I've never actually seen a zombie computer, sorry.

      • Re:My PC? (Score:4, Funny)

        by Dionysus ( 12737 ) on Thursday March 23, 2006 @08:11PM (#14984902) Homepage
        What do you think the spammers use on their zombie boxes? Code they wrote themselves?

        Why would a spammer need a smtp server on a zombie box? Don't zombie boxes just send email?

        • Re:My PC? (Score:5, Funny)

          by techno-vampire ( 666512 ) on Thursday March 23, 2006 @08:20PM (#14984933) Homepage
          Why would a spammer need a smtp server on a zombie box? Don't zombie boxes just send email?

          And what protocol do they use to send it? SMTP, of course.

          This has been another D'oh! moment.

          • But they're an SMTP client, not an SMTP server.
            • Some zombies (or so I've heard) act as an SMTP server, making the box into a spam relay. Having the server software built into the OS just makes that easier.
      • Windows has shipped with an SMTP server installed since Windows 2000.

        And that matters why, exactly? This is a problem with Sendmail, not the SMTP protocol. It's like saying "This Apache bug could affect Windows 2000 boxes running IIS." Just because it's using the same protocol doesn't mean it's using the same codebase.
      • "Windows has shipped with an SMTP server installed since Windows 2000. It's off by default in Server 2003 and in all client versions, and, I think, in 2000 Server, but it's there."

        Okay, so if clients are left out, then that leaves Windows 2000 Server and Windows Server 2003. If it's off by default in 2003, that leaves 2000. If it's off by default in 2000 Server, that leaves nothing. What kind of statement was that?

        To set the record straight, server versions of Windows 2000 were the only versions of Win

    • I didn't even know there was a Win32 port of sendmail. Not that I'd use it anyways, Postfix on *nix is waaaaaaay easier to set up and administer.
    • For any system that sends alerts via email(ie, it's not acting as a mail relay), you likely want to run a local sendmail in case there is any problem sending to your real MTAs so that those alerts are queued rather than lost. This includes windows servers.
  • Yay! I've been meaning to upgrade my mail server anyway... I'll just do it with more urgency now.

  • The inevitable 'use postfix!' post.... (Score:5, Informative)

    by Malor ( 3658 ) on Thursday March 23, 2006 @07:50PM (#14984810) Journal
    Yes, I realize this is too late for those of you running Sendmail now, and please don't take this as criticism for using it.... it's a solid mail program. But it was written when the Net was a much nicer place, and it's proving, once again, that retrofitting security is either very difficult or impossible. For a long time, it seemed like practically every third exploit was for Sendmail... it got pretty frustrating.

    The two major alternatives are Qmail and Postfix; Courier is sort of an up-and-comer, but they've had quite a number of security holes in those packages. (of course, that may also be related to the fact that Courier does a lot more than just deliver mail.) Of the three, I prefer Postfix. It's exceedingly solid, very fast, and fairly easy to configure. The initial learning curve is a little steep (mostly because there's about a billion things you can set), but the config files are readable when you're done. You don't have to relearn the whole program every six months. It's also very secure... I'm only aware of two security problems in its entire history. (I don't remember the details, but I think one was minor, and the other was moderately serious.)

    QMail is also solid, fast, and secure. But the author has decided that Unix machines should be configured a particular way, with files in particular places, and he uses his code as a weapon to try to force you to do things the way he wants. So I won't run it unless I have to. I don't deny that he's a brilliant coder and forty-eight times smarter than I am, but I refuse to be dictated to.

    Postfix can take a beating.. it is Truly Great Software. It will handle any load that Sendmail will handle, it's easier to administer, and the security is better. And, of course, it's truly free... Wietse won't try to make your administration decisions for you.

    • Agreed (Score:4, Interesting)

      by waldoj ( 8229 ) <waldo&jaquith,org> on Thursday March 23, 2006 @08:38PM (#14985024) Homepage Journal
      I ignored posts like this for years, figuring it was like the Linux vs. BSD debates -- just a bunch of zealots. I was wrong.

      Years after I mastered mc files and learned the magic of m4, back around 2002, I succumbed to /. peer pressure and switched to Postfix. It's just like Sendmail, only it doesn't suck. I didn't know Sendmail sucked until I used Postfix. It's easy, it's secure, and my servers haven't once been 0wn3d because of the ubiquitous MTA flaws of Sendmail.

      Some day I'll try Qmail. Baby steps.

      -Waldo Jaquith

      • I didn't know Sendmail sucked until I used Postfix.

        You must be a massochist. I remember using sendmail and simply wanting to change my outgoing mail so the from address was me@domain.com instead of me@machine.domain.com. I delved into it like any other project, but decided it wasn't worth it when I found out I had to learn an entire language (m4 or whatever it is), then compile that into another language just to do this one stupid thing. No thanks! A friend recommened postfix, and I've never looked back
      • Some day I'll try Qmail. Baby steps.

        Back when I ran sendmail I had heaps of problems with it. I bought a book called (I think) sendmail for linux and the conclusion of the book was to run something else. I went to qmail. Since then I have got more into free software (the GNU type) and I can see why the qmail license is a really bad thing. I run netqmail which is packaged as a set of patches with the qmail tarball because Dan Bernstein won't let people extend the source.

        I won't move away from qmail yet but

      • Re:Agreed (Score:3, Informative)

        by dodobh ( 65811 )
        Don't bother. qmail is a kludge after you have used Postfix. Having to patch source to get anything done?
    • Courier is a Great idea. One mail application. Not an MTA and seperate MDAs. Just one. Unfortunately, trying to figure out how to set up just SMTP+POP3 for a single machine with multiple aliases and a few virtual users seems to require knowing how to configure everything

      (If I'm wrong, and there actually is a guide telling how to do this, someone please post a note, I'd like to finally migrate to the new server we got 1.5y ago.)
      • The guides are at www.postfix.org and at www.dovecot.org.
    • Debian and derivatives come with exim set as the default MTA. I don't understand why redhat and it's derivatives come with sendmail as the default MTA. Postfix can actually be configured by normal people unlike sendmail and it's just as performant and a lot more secure.

      Just doesn't make sense. The first thing I do any redhat system is to chuck sendmail and install postfix instead.
      • Redhat has so many stupid defaults. The stupid path setup makes it tedious to compile anything yourself. Apache, postgres, php, etc stupidly do not have many features compiled in or compiled as modules, which forces you to compile things yourself. Their libc compiles have bizarre patches applied which tend to cause hard to trade bugs that only affect Redhat users. RPM is fairly painful to work with.

        While you probably have your reasons for using or sticking with Redhat, I decided years ago to chuck i
      • Postfix is licensed under the IBM Public License v1.0. I am unsure how compatible that is with the GPL (and perhaps the primary reason for it not being included). Exim is GPL .. not quite sure why it isn't more popular among the distros (perhaps sendmail history wins out?)
      • I don't understand why redhat and it's derivatives come with sendmail as the default MTA.

        A reliable source told me it's because customers would complain if they made postfix the default. He didn't go to lengths to defend it, but:

        They do ship postfix packages, so at least it's trivial to replace sendmail.

        SuSE ships with postfix by default.

    • Re:The inevitable 'use postfix!' post.... (Score:5, Insightful)

      by ajs ( 35943 ) <{moc.sja} {ta} {sja}> on Thursday March 23, 2006 @10:53PM (#14985632) Homepage Journal
      There was a time when sendmail exploits were all the rage, but at the time, sendmail was one of a very, very small number of programs that had reached its level of maturity, breadth of features AND was network accessible, and was the only one in widespread use under Unix-like systems. Because of some high-profile bugs, many companies including Sun and later Red Hat did heavy security audits of the code, revealing and fixing more problems.

      These are all good things, and it seems to me to be a bit two-faced to say that the power of open source is that there are many eyes on the source, and then to punish the software with the most eyes on it. Sendmail has been the heart of mail on the Internet for decades, and deservedly will continue to do so for the forseeable future.

      These bugs demonstrate the old saying: where there is code, there are bugs. I'll stick with software that has already had the vast majority of its security problems shaken out.
      • Postfix was written by the noted security expert Wietse Venema [wikipedia.org] specifically so that bugs would not lead to security issues--e.g. instead of being one monolithic app which runs as root, it's broken down into several pieces, most of which run as non-privileged users.

        Unlike sendmail, it was designed to be secure. I'll take the one for which security was not an afterthought, thankyouverymuch.

    • >Postfix can take a beating..

      You said it. I run it on dodgeit.com and it hums along quite nicely.

      Postfix is awesome "out of the box" and is incredibly flexible when you get fancier and want to inject custom code into the SMTP handshakes, etc.

      Just please remember to set "mynetworks_style = host" unless you trust every machine on the same LAN with your mailserver. I've been bitten by that one in a co-lo environment.

  • Insufficient data. (Score:5, Insightful)

    by jd ( 1658 ) <<moc.oohay> <ta> <kapimi>> on Thursday March 23, 2006 @08:00PM (#14984858) Homepage Journal
    Sendmail is a big program. It also has several components. This tells me that things like selinux and other mandatory access control systems MAY prevent the attack from taking over the PC. What impact there is on such systems depends on what component the failure is in and what rights that component must have.


    There are also multiple ways of configuring sendmail when compiling it, which tells me that whilst an upgrade may be important, it may be much more important for some users than others.


    Also, saying it doesn't affect Windows is unclear. Does it not affect Windows when you use some official .exe? When you compile it yourself? When compiled/run via Cygwin? If you run under Wine, do you see the bug or not? Are all versions of Windows safe, or would the bug be exposed under certain versions?


    The report, as described, is about as useful as saying "we think we know a way by which under certain circumstances that we know, another may think they know a way by which you might have an increased chance of being struck by an asteroid". If you don't know what the way is, or what those circumstances might be, the information has little value. Sure, it has some in that they provide a bugfixed release, but we don't know how long the bug has existed and therefore have absolutely bugger all way of quantifying what the risk is that a server has already been compromised. It only prevents uncompromised servers from being attacked by this method in future.


    Just because the press release is dated XYZ does not mean that every Black Hat under the sun hasn't got a CD-ROM filled with exploits for it and a list of backdoors on cracked sites from three years back. XYZ is merely the date the rest of us know about it. You don't maintain a secure system by assuming all crackers only know the exploits you've fixed. You maintain a secure system by assuming at least one cracker has the means to discover the exploits you've neither heard of nor have patches for - ie: by assuming you're running buggy software and taking the necessary steps to limit what those bugs can do.

    • A little heavy on the linebreaks son?
    • "Sendmail is a big program."

      When my eyes grazed over your text I initially read that as "Sendmail is a big problem"

      Do you know why the "sendmail book" has a bat on the cover? ;)
    • Sendmail is a big program.

      The thing is, if you step back and squint at it, it doesn't look so big.

      It needs to listen to port 25. It needs to be able to set up sockets for relaying mail out. It needs to be able to query DNS. It needs read/write access to the spool area, and write access to the users mail files/directories. It needs to be able to verify user credentials with some service or another. It needs to be able to pipe messages through a spam/virus scanner. It needs to be able to read it's own

  • IE and sendmail flaws on the same day? (Score:5, Funny)

    by MadFarmAnimalz ( 460972 ) on Thursday March 23, 2006 @08:30PM (#14984971) Homepage
    Coincidence? I think not...

    Shared codebase? Hmm?
  • The flaw could allow remote attackers to take control of users' PCs.

    Um, unless they mean take control of end user's PCs, what about the sendmail servers that are sending and receiving the email?

    I have to wonder how far Slashdot is going with the whole "linux is da bomb for the desktop!" ccrowd.
    • Hey, this is the Slashdot way; I bet about 1,000 people submitted this story, many with nice write-ups and links to credible, respectable news sources. But, this being Slashdot, the one that gets posted on the front page contains only a terse summary of the situation and a link to some lame PC rag.
    • I have to wonder how far Slashdot is going with the whole "linux is da bomb for the desktop!" ccrowd.

      The average desktop does not run sendmail or anything other than simple mail clients that use their ISP's SMTP sever. Their ISP won't let them. There's a good chance that server will be running sendmail, so users of nicer distributions are thwarted twice by "security measures", but that's all a different issue. Yes, Exim under Debian was easy to set up and worked great for desktop users.

      In any case, Lin

  • Jack from Dyad Security just posted this link:
    http://www.rapturesecurity.org/jack/exploiting_sen dmail.html [rapturesecurity.org]

    Quoted:
    written in a rush, pardon the mess ;]

    not that ive gotten that far but here is my (confirmed by mark, thanks) attack....

    step 1)
    connect to sendmail server say something like
    helo me\r\n
    mail from: myemail@hotmail.com
    rcpt to: root
    data

    step 2)
  • How hard can it be to move mail from A to B? Speaking as someone who's never written a mail server, I didn't think it was complicated enough to have so many security holes... (Serious explanations of what it does to warrant the complexity would be appreciated~)
    • If all you're doing is "moving mail from A to B," it's not too hard. In that case you should me using postfix or qmail or whatever. If you're trying to move 50,000 messages an hour from A to B, use milter filtering, set up multiple inbound and outbound processing queues based on complex rules, and/or doing other hairy things with mail relaying, you see the situation can get quite a bit more complex.

  • A security hole? In Sendmail? Now you're just talking crazy talk.

  • talking about systems not vulnerable to this vuln...

    According to the Sun security advisory [sun.com] related to this (thanks SANS Internet Storm Center [sans.org]), Solaris 8 isn't vulnerable, although it comes with Sendmail 8.11.x or 8.12.x (depending on your patch frequency)--versions in the vulnerable range.

    I've been a Solaris admin for a long time and I find this to be a rather bizarre inconsistency. Why would Sun claim non-vulnerability when mere cursory examination of installed release shows vulnerability?

    Any /.ers with m

Slashdot Top Deals

Suggest you just sit there and wait till life gets easier.

Close