Slashdot Mirror


Buffer Overflow in Sendmail

ChiefArcher writes "On the footsteps of openssh, Sendmail 8.12.10 has just been released due to a buffer overflow in address parsing. Sendmail states this is potentially remotely exploitable. No updates on the Sendmail site yet, but the FTP site has the release notes."

26 of 478 comments (clear)

  1. Use qmail by DigitalNinja7 · · Score: 5, Informative

    That's why you should be using qmail, ya' code monkeys! Seems like this happens every couple months.

    --
    Show your love for the Hacker community
    HackerLogo.com
    1. Re:Use qmail by Dysan2k · · Score: 4, Informative

      Bah! And I'll say it again, Bah!

      Use Postfix! Ok, use either really, just stop using Sendmail. I run Qmail at work (due to legacy and converting Qmail's Maildir to Cyrus' Maildir just seems neigh impossible) and Postfix at home. Postfix is really straight-foward on setup and has TONS of documentation in the conf files.

      Qmail, on the other hand has tons of docs on the site and lists a number of different ways to perform various tasks.

      It's really a crap-shoot as to which you prefer. Just STOP USING SENDMAIL!

      --
      -What have you contributed lately?
    2. Re:Use qmail by bongoras · · Score: 5, Informative

      PLEASE PLEASE PLEASE read the fucking article...

      from the release notes:

      "Fix a potential buffer overflow in ruleset parsing. This problem
      is not exploitable in the default sendmail configuration;
      only if non-standard rulesets recipient (2), final (4), or
      mailer-specific envelope recipients rulesets are used then
      a problem may occur. "

      http://www.sendmail.org/8.12.10.html

      While I agree it's necessary to patch systems, this is hardly like the Blaster worm. I'm going to go way out on a limb here and say that 99.99% of all sendmail installations in the world don't use these rulesets. And anyone who IS using them is likely to be a sendmail weenie anyhow and they'll just take a break from writing their AI Chess program in sendmail.cf and patch it themselves.

  2. "Email Different" by Anonymous Coward · · Score: 5, Funny


    That's why you should entrust all your email services to Hotmail.

    1. Re:"Email Different" by CausticWindow · · Score: 4, Funny

      You've got a point there.

      While not as flexible as mutt on a *nix server, at least Hotmail is basicly secure.

      --
      How small a thought it takes to fill a whole life
    2. Re:"Email Different" by buffer-overflowed · · Score: 4, Funny

      No, you should entrust all your email to me... I'm a nice guy really. I'm *never* responsible for remotely exploitable holes.

      --
      The key to the enjoyment of pop music is to replace any instance of "love" with "C.H.U.D."
    3. Re:"Email Different" by rworne · · Score: 4, Insightful

      Actually it is secure, depending on your needs.

      I need a mail server for non-sensitive e-mails. If someone roots Hotmail's server, I couldn't care less about it. If someone roots my server, then it's a whole different matter. I also use it to prevent handing out my real email address to the myriad of sites that require e-mail registration and for usenet postings.

      So yes, in my case Hotmail is a very secure solution.

      --
      I tried every decent and legal way I could think of to resolve the issue w/the business before I rented the chicken suit
  3. It's on the site now by Phaid · · Score: 4, Informative

    The official announcement is here.

    I've already downloaded and installed it. Thank goodness for Slackbuild scripts :)

  4. Yay! by Greyfox · · Score: 5, Funny

    I'll have to dust off my sendmail sploit-of-the-week card and get them to punch it for me! 12 punches and you get a free MTA!

    --

    I'm trying to teach myself to set people on fire with my mind... Is it hot in here?

  5. Nice week for open source by gmuslera · · Score: 4, Insightful

    Yesterday was the day of openssh, and today for sendmail (whats next? bind? apache?). More than the usual rant about using alternatives like postfix/qmail/exim/etc instead of sendmail, I see that as a positive thing, could be a signal that more testing, auditing, and usage is being done, and by the open source nature of those tools, that this kind of things will be fixed or the programs will evolve to avoid this kind of things with (really) safer practices.

  6. Re:OpenSSH as well by CausticWindow · · Score: 4, Insightful

    It's a paradox that people who are so paranoid when it comes to security (there are no proof of concept remote exploits for either of these holes), would download patches from where ever and who ever.

    Posts like the parent ("get latest patch from me!") always get moderated up, so there must be somebody downloading and installing them. Maybe I shouldn't give people ideas.

    --
    How small a thought it takes to fill a whole life
  7. This is a really difficult one by heironymouscoward · · Score: 4, Funny

    A serious response to the story is too bleak. Ho-hum, upgrade sendmail, patch it, OK.

    Comedy is inappropriate. "Is that sendmail dead? No, it's just sleeping. Oh, I could swear it was dead! No, it's just tired, see? Sendmail gottan exploit, sendmail gottan exploit!"

    Irony is difficult. To be honest, I can't even be sure which ironic form I would employ in this case. Forget irony.

    Sarcasm? "Sendmail, yeah, like we're still using that dinosaur!" What, we are? Dang. Why? "Cause it was there?" What kind of an excuse is that?!

    Nihilism... "yes, another day, another exploit. ssh, now sendmail. I can just see the future, one long bitter trail of unpatched software, server after server to upgrade. brain the size of a planet, and here I am, patching sendmail. what's the use, I ask you...?"

    Slashdotisms? All your sendmail overlords are 1-2-3 profit to us? Imagine? In Russia? No, no, no.

    SCO! SCO! "It's not an exploit, it's a snippet!!!" Worth a try.

    Damn you to the deepest depths of hell, Slsadhot edirots, this story has so little karma leverage it hurts.

    --
    Ceci n'est pas une signature
  8. Re:Patch delivery mechanism by Anonymous Coward · · Score: 5, Funny

    > Does Linux have an Auto-update mechanism similar to
    > windows that indicates when new patches are available
    > for download?

    Yup. it's called "slashdot"

  9. Re:I use... by 1010011010 · · Score: 4, Funny


    If you can edit a .cf file by hand, you've earned the right to run it. :) And the punishment of running it.

    --
    Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
  10. Re:Sendmail's future by blate · · Score: 4, Insightful

    I'm not sure that "insecure by design" is quite fair to the hard-working folks who developed this near-ubiquitous MTA.

    A fairer assessment is that, when sendmail was designed, security was not as big an issue as it has become today. And in their defense, they do seem quite good about notifying people when vunerabilities arise and releasing fixes as quickly as possible.

    That being said, sendmail is a pain in the ass. You have to remember that when sendmail was developed, there were many different mail protocols (besides SMTP), and sendmail had to support all of them -- this is why sendmail config files are so darned complex and unreadable. The vast majority of those have faded into obscurity, so subsequent products, like Postfix, can be much simpler and less complex and, thus, more likely to be secure. For a long time, sendmail was the only choice for a real MTA, but I think Postfix has proven itself a worthy successor.

  11. Re:How does an overflow work? by Second_Derivative · · Score: 4, Informative

    Stack grows downward, buffers on stack grow upward. Overflow a buffer and sooner or later you run into a return pointer on the buffer. Now, if you overflow it in such a way that the function corresponding to that stackgrame doesn't cause a segfault before it returns, the CPU will read in a return address you supplied, which could point to the buffer. CPU then executes the code you put in the buffer. I believe it's traditional to execve /bin/sh at this point.

    Google for "Smashing the stack for fun and profit". I don't know too much of the specifics -- I'm not a script kiddie.

  12. Re:Sendmail's future by Fizzlewhiff · · Score: 4, Funny

    I agree and am migrating to Exchange as I type this. Hopefully it, and Outlook will be more secure for my users.

    --

    'Same speed C but faster'
  13. Re:Patch delivery mechanism by mopslik · · Score: 5, Insightful

    ...you must give Microsoft credit. When an exploit is made public, they already have the patch ready.

    You mean when Microsoft publicly discloses the exploit, usually weeks after it was first reported across the Internet?

  14. Re:What Sendmail security problem? by __past__ · · Score: 4, Insightful

    I'm a happy postfix user myself, but it should be noted for fairness reasons that the last postfix-related advisories are about two weeks old... Face it, some software may be better than others, but no matter what you are running, you'll always have to keep your systems up to date. Looking down on others because the software they run is oh so insecure and yours is perfect is the first step to being rooted.

  15. Re:OpenSSH as well by lone_marauder · · Score: 5, Funny

    What?? You don't trust software compiled by flying butt monkeys?

    --
    who are those slashdot people? they swept over like Mongol-Tartars.
  16. Re:How does an overflow work? by Waffle+Iron · · Score: 4, Informative
    During C procedure calls, the return addresses are placed on the stack in predictable locations. Often, people use fixed-size buffers allocated on the stack in their procedures. For example:

    void foo() {
    char buf[100];
    gets(buf);
    --- do stuff ---
    }

    By feeding in a string longer than 100 characters, you go up the stack and can overwrite the return address to the call to 'foo'. You might replace the address with a pointer to code you've embedded in the oversized string. When the call returns, it jumps into your code rather than the calling procedure.

  17. This is getting silly by jd · · Score: 5, Informative
    Sendmail badly needs a severe audit. Maybe Stanford can run their validating compiler over it, or something. Either way, you shouldn't be seeing such basic, fundamental flaws in software that has been around for a long time.


    Especially software that is semi-commercial. They're getting paid to check for these issues, after all.


    Ok, credit given where credit is due. The problem has been recognised within a short time of being detected. That's better than Hotmail's "check the password? what for?" bug, that persisted for six or seven months, and remained in effect for several days after the media ran the story.


    But that's where the credit ends. It shows that the program isn't being routinely tested and verified with overflow detectors, or (if it is), that the testing procedure is inadequate.


    It shows why rival MTAs (eg: Postfix) are gaining popularity, when Sendmail could have kept absolute control of the market, merely by being the best.

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
  18. Re:Sendmail's future by Nevyn · · Score: 4, Informative
    I'm not sure that "insecure by design" is quite fair to the hard-working folks who developed this near-ubiquitous MTA.

    So are you saying it is designed with security in mind?

    A fairer assessment is that, when sendmail was designed, security was not as big an issue as it has become today.

    So you saying (agreeing) it is designed without security in mind.

    It's been years since the internet operated where everyone allowed relaying to help everyone else out. And go look at the code, they still use NIL terminated char *'s all over the place. Mostly with limited length APIs like strlcpy(), but even a few strcpy()s.

    Now go look at postfix or qmail, but have fully dynamic string APIs and use them everywhere. And supprise supprise neither has had a buffer overflow.

    --
    ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
  19. Re:Before the Microsoft defenders say it... by TheNetAvenger · · Score: 4, Informative

    But there is another kind of security problem for which Microsoft is deservedly bashed. The problem Microsoft is bashed for having poor security is when their system is insecure in its design. (It may not have been a design goal.)

    Although you have good motives in this post, you have no idea what you are talking about in regard to Microsoft's OS architectural security and its history.

    Sure Win9x and Win3.x and DOS are INHERENTLY insecure, as they were designed with a closed system architecture in mind and an evolution of a closed system OS. Just like Mac System software has almost no inherent underlying security. (i.e. they were not designed for security or rigid network security since many of the networking concepts that are common today were not available or widely used when they were originally designed in the 80s. As most home users concepts of networks were CompuServe and BBSes.)

    However, the NT architecture and security model that it was designed upon had security as a main priority from its original designs. In fact the Object Oriented/Token based security model that is in the NT base (and the original NT 3.1) are not only conceptually more advanced than the *nix security model, but they also have been successfully implemented to be one of the most secure OS designs in history.

    The designers of the NT security model took 'conceptual' ideas of the 'ideal' methodologies for a robust and strong underlying security structure and designed these into the OS from day one.

    This is why people like Dave Cutler and other 'respected' Unix and OS engineers at the time that were hired by Microsoft ABANDONED the *nix security models to build an OS using the new theories of OS security and implement them in the NT kernel architecture.

    As for backing my claims, I suggest an original text like "Inside Windows NT" - The original 1993 release and the recent updated releases that cover the newer NT code bases - Windows 2000, XP, and 2003.

    The OS designers at Microsoft had full control to make NT based upon *nix concepts and technologies if that was what they thought was the most advanced conceptual OS engineering; however, they rejected taking the *nix route and instead went for OS architectural concepts that were on the forefront of technological theory and hadn't even been implemented in a real OS to the extent they were in NT.

    As you can see from many of my posts here, I am not a hard core Microsoft or NT zealot, but when I see people just dismiss technologies because they take the popular misconceptions I feel the need to respond.

    Even if you hate NT and Microsoft, I truly do hope you will explore what TRULY is in NT in terms of security and its security model for your own knowledge.

    Especially considering any information you or someone else reading this post gain from it might be compelled to use some of the Microsoft NT concepts in other OS coding and designs to create richer OS environments for everyone, whether it be MacOSX, Linux, or BeOS.

    Even if you take odds and dismiss the intellectuals that designed NT, there is always the chance the Microsoft team did do something innovative or right that can also benefit future OS architectural models.

    Take Care,
    TheNetAvenger

  20. Why support MS and get spam? by msimm · · Score: 4, Interesting

    Instead of use bluebottle.com? They have free 10 meg accounts without MS bs or advertising and use a TMDA like system for anti-spam verification. I'll never understand why technical people would use a hotmail account (bluebottle *will* also check your hotmail account for you).

    --
    Quack, quack.
  21. There are *TWO* bugs by V.+Mole · · Score: 4, Informative

    Actuall, more than two: the changelog includes several fixes. Right above the fix you quote, there's one that *is* exploitable, which is why they've gone ahead and released it:

    8.12.10/8.12.10 2003/09/24
    SECURITY: Fix a buffer overflow in address parsing. Problem
    detected by Michal Zalewski, patch from Todd C. Miller
    of Courtesan Consulting.

    The fact it's separate bugs is clear from the indention in the original (Fscking /. doesn't support PRE)