Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Security The Internet Technology

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 Commercial Sendmail customers can find patches at 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.
This discussion has been archived. No new comments can be posted.

ISS Discovers A Remote Hole In Sendmail

Comments Filter:
  • ISS? (Score:5, Funny)

    by europrobe ( 167359 ) <daniel AT perup DOT net> on Monday March 03, 2003 @03:23PM (#5425804) Homepage
    That has got to be a very remote hole if it took the International Space Station to find it...
    • Re:ISS? (Score:2, Funny)

      by queenb**ch ( 446380 )
      I'm still waiting for the proof of concept so that I can test this on every mail server in sight. Hmmmm.......wonder if the FBI will by later.

      Queen B
      • Re:ISS? (Score:3, Funny)

        by pebs ( 654334 )
        The proof of concept is right here [].

        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)

          by ahaning ( 108463 )

          Note the directory.. `mktg'. Sounds like marketing to me.
        • Re:ISS? (Score:5, Funny)

          by sammy baby ( 14909 ) on Monday March 03, 2003 @05:02PM (#5426669) Journal
          The flash animation is one of the lamest things I've ever seen. It's actually pretty 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!")
    • If it was found by the International Space Station, maybe it should be a remote black hole.
  • by Anonymous Coward
    Let's not forget that just because it's open source doesn't mean it's invulnerable.

    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.
    • you arent insightful i hear that everytime a open source vulnerability pops up
    • I haven't seen Microsoft having a patch ready within 24 hours of a vulnerability being announced.
      • by NickDngr ( 561211 ) on Monday March 03, 2003 @03:40PM (#5425956) Journal
        I haven't seen Microsoft having a patch ready within 24 hours of a vulnerability being announced.

        Apparently you didn't read the article. "Initial vendor notification: 1/13/2003." The vendor was notified a month and a half ago.
      • by MisterFancypants ( 615129 ) on Monday March 03, 2003 @03:40PM (#5425958)
        I haven't seen Microsoft having a patch ready within 24 hours of a vulnerability being announced.

        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.

      • 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

      • Then you haven't been looking very hard. Every vulnerability in recent memory has been accompanied by a patch at the time of disclosure, usually because MS had finished the patch before announcing the hole. This is the responsible way to report a vulnerability, as opposed to shouting out that there's a hole, then following with a patch days or weeks later.

        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)

    by Koyaanisqatsi ( 581196 ) on Monday March 03, 2003 @03:24PM (#5425816)
    Who else got confused by reading that "IIS Discovers A Remote Hole In Sendmail"?
    • Who else got confused by reading that "IIS Discovers A Remote Hole In Sendmail"?

      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)

        by moonbender ( 547943 )
        According to that logic, and with all the bugs found in Sendmail during its history, it should long ago have evolved something like a hive mind and fixed its own holes.
    • I was confused, too.

      So, it seems that I'm not the only one who's expecting it?
  • by shadwwulf ( 145057 ) on Monday March 03, 2003 @03:24PM (#5425817) Homepage
    While you're at it check out Qmail [] it's a lot more modular than sendmail and is much more secure.
    • by krog ( 25663 )
      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 []. It's far more powerful than QMail, while still being easy to set up and use.
      • by nitehorse ( 58425 ) <> on Monday March 03, 2003 @03:43PM (#5425980)
        Postfix sucks.

        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.
      • QMail is fine for a four- or five-user machine
        You're full of it. Hotmail's outgoing mail is still handled by customized qmail code.
        • You're full of it. Hotmail's outgoing mail is still handled by customized qmail code.

          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.

          • 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.

      • 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 []. 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?
      • by Doktor Memory ( 237313 ) on Monday March 03, 2003 @04:10PM (#5426183) Journal
        It's far more powerful than QMail

        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 [] and contrast [] 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.
        • by leviramsey ( 248057 ) on Monday March 03, 2003 @05:12PM (#5426736) Journal

          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.

          • 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).

            This is not necessarily true []. Qmail has officially supported tools to make it look indistinguishable from sendmail for 90% of all users. (e.g. support ".forward" files and /etc/aliases)

            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.)
            • 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.

      • "far more powerful"? I suppose there's no way to falsify that statement, since it's contentless.

        By the way, Rediffmail, which has 15 million users last time I checked, runs Linux and qmail.
    • by mosch ( 204 ) on Monday March 03, 2003 @03:33PM (#5425897) Homepage
      Or as another superior alternative, check out Weitse Venema's mailer, Postfix []. It was built from the ground up to be fast and secure, and it benefits from not being maintained by the notoriously finicky djb. (if you've never dealt with him, he's much like a Theo De Raadt, except he doesn't even have a good cause.)
    • don't forget Apache James. []
    • by secolactico ( 519805 ) on Monday March 03, 2003 @04:08PM (#5426171) Journal
      What about exim? By default it runs as non-root and it's *very* easy to set up. I gave up sendmail about a year ago for it and I have never had any trouble with it.
      • by tqbf ( 59350 ) on Monday March 03, 2003 @06:44PM (#5427743) Homepage
        Exim is not a credible secure alternative to Sendmail. It shares the same architecture that makes Sendmail a poster child for susceptability.

        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 [] in 1997, it was immediately clear to me that Exim could not make the same claim.

  • Yes! (Score:5, Funny)

    by mao che minh ( 611166 ) on Monday March 03, 2003 @03:27PM (#5425831) Journal
    Yes! I have been longing for a another security alert in an open source application for some time. Now we can enjoy the always engaging and informative debates between Microsoft clowns and open source zealots concerning security in proprietary and open source code. It is difficult to find the same measure of eloquence in posts concerning other aspects of technology.
  • by DNS-and-BIND ( 461968 ) on Monday March 03, 2003 @03:28PM (#5425845) Homepage
    I can summarize 90% of the comments in this story right now:

    • Sendmail sucks! Anything this old sucks by definition. Grep, TCP/IP, sendmail, ping all suck.
    • Switch to qmail! Qmail has no features, and it is written by a psychotic...why haven't you switched yet?
    • Switch to MS Exchange! You get calendaring, for God's sake!
    • Switch to $ANOTHER_MAILER_THAT_IS_NOT_SENDMAIL. Only sendmail has security holes! Other mailer software doesn't have holes.
    Anyone else?
  • While you're at it grab spamass-milter from , add this line to you site.config.m4:

    APPENDDEF(`conf_sendmail_ENVDEF', `-DMILTER')

    Use CPAN to install SpamAssassin:

    perl -MCPAN -e shell;
    install Mail::SpamAssassin

    Then compile spamass-milter. Add this to your 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 = ''; spam filtering. Tweak the files in /etc/spamassassin as to your liking for system wide, and in ~/spamassassin for users. Enjoy. :)
  • RedHat Network Rules (Score:5, Interesting)

    by Shane ( 3950 ) on Monday March 03, 2003 @03:29PM (#5425856) Homepage
    I was updated before I read the E-mail telling me I _WAS_ insecure.
  • OpenBSD? (Score:2, Interesting)

    by Elequin ( 137149 )
    Doesn't OpenBSD install with Sendmail active by default? I believe it does, but I don't think it listens to anything but localhost by default. If it does, this would be the second remote root exploit in OpenBSD in as many years.

    Not bad once you think about it.

    - Eric
    • Re:OpenBSD? (Score:2, Insightful)

      by Anonymous Coward
      Umm...How is it a remote root exploit if it's only listening on localhost?
      • Um, re-read parent. He said, if - contrary to what he thinks - Sendmail does listen to anything but localhost, then and only then this is a remote root exploit.
    • Re:OpenBSD? (Score:2, Funny)

      by TCaM ( 308943 )
      Yes, and I'm not going to patch mine so there. Go ahead crack me, my ip address by the way is

  • Oh no... (Score:2, Funny)

    by maxbang ( 598632 )

    Looks like it's time to add another three thousand pages to the Sendmail manual.

  • Open Source All (Score:2, Insightful)

    by Anonymous Coward
    Look at how fast open source software can patch security holes! Oh...wait, it's been almost 2 months since this has been discovered.
  • A better Fix (Score:3, Offtopic)

    by gmuslera ( 3436 ) on Monday March 03, 2003 @03:33PM (#5425894) Homepage Journal
    Postfix [].

    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.

    • by Nonesuch ( 90847 ) on Monday March 03, 2003 @03:52PM (#5426045) Homepage Journal
      I'm on hold with Cisco now, but it appears that the exploit code would make it past the PIX "protocol fixup" for SMTP. Not that I expect "fixup" on a PIX to offer much protection.

      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:

      1. Upgrade sendmail to the latest release.
      2. Make configuration changes to run sendmail as a non-root user.
      3. Investigate running sendmail 'chroot'.

      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.

      • hrm... Postfix supports RBL stuff, but maintaining 2 separate mail systems seems a bit absurd... also, depending on your installation size and what you're doing with it, postfix can be slow.

  • by LongJohnStewartMill ( 645597 ) on Monday March 03, 2003 @03:34PM (#5425909)
    Be sure to watch the animation [] of the sendmail exploit. Talk about rubbing it in. Not only did they post their discovery, but they made a cartoon about it. That takes some time to make, so they must think they'll be able to use the cartoon again. They're probably right - it's sendmail.
    • 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)

    by Anonymous Coward on Monday March 03, 2003 @03:39PM (#5425947)
    The Common Vulnerabilities and Exposures (CVE) project has assigned the name
    CAN-2002-1337 to this issue

    heh. leet.
  • by Wakko Warner ( 324 ) on Monday March 03, 2003 @03:40PM (#5425957) Homepage Journal
    So I'm planning on getting rid of it once and for all. Can someone point me toward a very simple drop-in replacement for this bloated old pile of shit that doesn't take a day to set up?

    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.
    • by WasterDave ( 20047 ) <(moc.pekdez) (ta) (pevad)> on Monday March 03, 2003 @03:57PM (#5426088)
      I use exim. I have used exim, qmail and sendmail and I like exim by far the most. It is:

      * 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.

  • Proof (Score:2, Funny)

    by skydude_20 ( 307538 )
    ISS Discovers A Remote Hole In Sendmail
    Finally, proof that the work being in space is actually accomplishing something useful for everyone
  • Slackware (Score:4, Informative)

    by Phroggy ( 441 ) <.moc.yggorhp. .ta. .3todhsals.> on Monday March 03, 2003 @03:47PM (#5426004) Homepage
    Patch available from the usual place [].
  • by billstewart ( 78916 ) on Monday March 03, 2003 @03:50PM (#5426026) Journal
    Look, how long have we known that running a mail system as root is dangerous, stupid, unnecessary, and avoidable? And how many times do we have to see root exploits in Sendmail before we get the hint? System III (predecessor to System V) was running email delivery as non-root, group- mail back in what, 1983? It just works, folks! The "let's make TCP/IP secure by making ports below 1024 root-only" strategy has its good points and its bad points, but if your operating system doesn't let you make exceptions for specific ports in the kernel, you can use a minimal wrapper for TCP services that opens port 25 and sets uid=mail, so it never processes any user input until it's Not Root.

    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.)

    • by Nonesuch ( 90847 ) on Monday March 03, 2003 @03:58PM (#5426099) Homepage Journal
      Look, how long have we known that running a mail system as root is dangerous, stupid, unnecessary, and avoidable?
      Great, so instead of getting root instantly with a single exploit, I get a shell as a non-privileged user, and have to waste another five minutes pulling over a platform-specific exploit to leverage that access to get root.

      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).

    • ^
      --- 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
    • The "let's make TCP/IP secure by making ports below 1024 root-only" strategy has its good points and its bad points

      Uhm. Remind me. What exactly are its good points?

    • 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.

      "One way to minimize the possibility of such problems [root exploits] is to install sendmail without set-user-ID root, which avoids local exploits. This configuration, which is the default starting with 8.12, ..."

      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 []) 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.

  • by msheppard ( 150231 ) on Monday March 03, 2003 @03:51PM (#5426035) Homepage Journal
    I mis-read that title as ISS (Space Station) discovers HOLE, and immediatly thought our worst fears of a problem with the space station with the shuttle fleet grounded might have happened.

    Of course the Russian Soyez could always come to the rescue.

  • by Brooks Davis ( 22303 ) on Monday March 03, 2003 @03:51PM (#5426037) Homepage
    FreeBSD the 3-STABLE (last release nearly three years ago!) , 4-STABLE, and 5-CURRENT branches, as well as the security branches for release 4.3, 4.4, 4.5, 4.6, 4.7, and 5.0 were updated immediatly follow the advisory's release.

    -- Brooks
  • Monoculture (Score:3, Insightful)

    by Anonymous Coward on Monday March 03, 2003 @03:51PM (#5426038)

    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 []:

    • many more
  • by lavalyn ( 649886 ) on Monday March 03, 2003 @03:53PM (#5426050) Homepage Journal
    Sendmail was always a good fun program to find remote exploits for, with its configuration file so incredibly cryptic and its architecture inherently unsafe. What other program treats local files like incoming mail? And has a .cf file that looks like raw /dev/random output?
  • As if slashdot didn't mistake IIS and ISS enough as it is, now another ISS for slashdot...

    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...

  • *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.

  • It's been nearly six months since the SANS/FBI "Top 20" Internet vulnerabilities list [] was updated. Looks like it's time for another update as the sendmail section contains the following line:

    Sendmail has not had a 'high' severity vulnerability in more two years

    Is this latest considered 'high' vulnerability? If you have never read this report, I highly recommend it for both Unix and MS system admins.

  • by phutureboy ( 70690 ) on Monday March 03, 2003 @05:48PM (#5427100)
    From []:

    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.
  • by kindbud ( 90044 ) on Monday March 03, 2003 @07:50PM (#5428393) Homepage
    Has anyone located specifics about this exploit? Is there a scanner or tester, or exploit code available? The ISS release says it is "readily exploitable on x86 architecture systems, and may be exploitable on
    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.

Don't tell me how hard you work. Tell me how much you get done. -- James J. Ling