Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Bug

Buffer Overflow in Sendmail 478

Posted by CmdrTaco from the put-on-your-hardhat-and-rebuild dept.
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."
This discussion has been archived. No new comments can be posted.

Buffer Overflow in Sendmail More

Buffer Overflow in Sendmail

Comments Filter:

  • Use qmail (Score:5, Informative)

    by DigitalNinja7 ( 684261 ) * on Wednesday September 17, 2003 @02:10PM (#6987412) Homepage
    That's why you should be using qmail [cr.yp.to], ya' code monkeys! Seems like this happens every couple months.

    • Re:Use qmail (Score:5, Informative)

      by Dysan2k ( 126022 ) on Wednesday September 17, 2003 @03:00PM (#6987919) Homepage
      Bah! And I'll say it again, Bah!

      Use Postfix [postfix.org]! 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!

      • Re:Use qmail (Score:3, Informative)

        by Pointer80 ( 38430 )
        I used perl with Mail::IMAPClient to convert from Maildir (Sendmail/Procmail w/modified qmail-pop3d) to Cyrus.

        Here [mikecathey.com] is the most relevant part of the perl module I wrote to handle the migration.

        Please not that there are several system dependent settings in this function. Our spool was hashed to depth two. I will probably end up rewriting this module to proxy for the user, authenticating as cyrus, which would be much cleaner.

        We've been using Postfix/Cyrus in production for a while now and we're really ha

    • Re:Use qmail (Score:5, Informative)

      by bongoras ( 632709 ) * on Wednesday September 17, 2003 @03:03PM (#6987948) Homepage
      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.

      • There are *TWO* bugs (Score:5, Informative)

        by V. Mole ( 9567 ) on Wednesday September 17, 2003 @05:44PM (#6989373) Homepage

        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)

    • Re:Use qmail (Score:3, Informative)

      by ChaosDiscord ( 4913 )

      That's why you should be using

      qmail [cr.yp.to], ya' code monkeys!

      Great idea! I'll just download a package from my favorite distribution that's tuned qmail to mesh nicely with how my system is configured.

      Hmm, they don't supply packages for qmail. Why not? They're not allowed to [cr.yp.to]. If I take the time to make up such a package, I'm not allowed to give it to my friend.

      Quoth Bernstein:

      But that's a decision for the Apache maintainers, not the UNIX integrators!

      Darn those pesky integrators, attempting to make thei

    • Here is a HOWTO [linuxvds.com] and a tarball [linuxvds.com] containing all of the files necessary to replace sendmail with qmail on an RPM based system.

  • "Email Different" (Score:5, Funny)

    by Anonymous Coward on Wednesday September 17, 2003 @02:12PM (#6987433)

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

  • It's on the site now (Score:5, Informative)

    by Phaid ( 938 ) on Wednesday September 17, 2003 @02:13PM (#6987447) Homepage
    The official announcement is here [sendmail.org].

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

  • *cough* (Score:2, Flamebait)

    by interiot ( 50685 )
    Everyone who complained that Microsoft is so evil for the lack in quality of code they put out, raise your hand so we can heckle you.

    Mistakes happen to everyone, and microsoft code isn't necessarily even the most important part of the internet.

    • Re:*cough* (Score:3, Insightful)

      by adamruck ( 638131 )
      *raises hand*

      The difference is that Microsofts patches take forever to come out and introduce more holes than anything else.

      In linux patches come out the same day... and are well documented.

      • Re:*cough* (Score:3, Insightful)

        by koreth ( 409849 ) *
        The difference is that Microsofts patches take forever to come out and introduce more holes than anything else.

        Really? What holes were introduced by, say, the Blaster worm patch? Or any other patches you care to name?

        Can't argue about the speed of patches, exactly, but I'd point out that MS almost always releases a patch before the bug in question is widely exploited -- the problem with the last few worms/viruses was more with unpatched systems than lack of responsiveness on MS's part. MS could come out

    • It's possible that Microsoft and Sendmail are both bad at security. Sendmail is a horrible piece of software anyway.

    • Re:*cough* (Score:3, Insightful)

      by bluGill ( 862 )

      Sendmail has never had a good reputation for code quality. MS doesn't either. Whats your point?

    • Re:*cough* (Score:2, Insightful)

      by Anonymous Coward
      The difference is that not only is the news of the bug breaking now, nor that it's exploitable, but that IT'S ALREADY FIXED
    • It was me who complained, yes, beloved, it was meeee, all meeee.

      Heckle, I command thee.

      And yet, strangely, I feel compelled to agree with you that Microsoft code is not the most important part of the Internet. Very true. In fact, if the only code out there was Microsoft's there would be no Internet.

      OK, you can heckle now, I'm mentally prepared.
    • Everyone who complained that Microsoft is so evil for the lack in quality of code they put out, raise your hand so we can heckle you.

      Microsoft is closed source - so we never get to see their code. And even though they keep it under wraps - it's still more exploitable on average than most Open Source code.

      Microsoft still is on the "patch all stck overflows" ramp that most open source software fixed a few years ago.

      Most bugs in Open Source, now, tend to be really obscure ones.

  • Sendmail's future (Score:4, Interesting)

    by nepheles ( 642829 ) on Wednesday September 17, 2003 @02:15PM (#6987466) Homepage
    Is it perhaps time for a code rewrite in Sendmail, or maybe a quiet, dignified retirement? It appears, from empirical evidence, that Sendmail is insecure by design. And that's not a good idea for a mail server, in today's world of spam

    • Re:Sendmail's future (Score:3, Informative)

      by bourne ( 539955 )

      Is it perhaps time for a code rewrite in Sendmail...

      IIRC 8.9 was the code rewrite.

      maybe a quiet, dignified retirement?

      At this point, I'd settle for a noisy drag-it-out-back-and-shoot-it.

      Secure alternatives exist - Postfix [postfix.org], qmail [qmail.org]. Other alternatives with better security track records and lower target profiles exist - Exim [exim.org], Courier [sourceforge.net].

      Time and past time to move. How many holes is it going to take?

    • Re:Sendmail's future (Score:5, Insightful)

      by blate ( 532322 ) on Wednesday September 17, 2003 @02:26PM (#6987616)
      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.

      • Re:Sendmail's future (Score:3, Insightful)

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

        Absolutely. In sendmail's heyday, the internet was a collection of several hundred .edu and .mil organizations, with a few .com technology companies thrown in, notably IBM and DEC. The few hundred thousand people on the net tended to be researchers and faculty in technical fields and their students. Security was very lax because it was a relatively small, closed, professional society. Peop

      • Re:Sendmail's future (Score:4, Informative)

        by Nevyn ( 5505 ) on Wednesday September 17, 2003 @03:24PM (#6988174) Homepage Journal
        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 [and.org] 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.org] and use them everywhere. And supprise supprise neither has had a buffer overflow.

    • Someone should write a sendmail.cf interpreter for Postfix or Qmail so that old config files can still be read (if that's even worth doing). Anyone who still writes new sendmail config files is a masochist. Sendmail should definitely be retired.

    • Re:Sendmail's future (Score:5, Funny)

      by Fizzlewhiff ( 256410 ) <jeffshannon@nosPAm.hotmail.com> on Wednesday September 17, 2003 @02:30PM (#6987669) Homepage
      I agree and am migrating to Exchange as I type this. Hopefully it, and Outlook will be more secure for my users.

    • Is it perhaps time for a code rewrite in Sendmail, or maybe a quiet, dignified retirement?

      As with most legacy software, there is a large investment in the expertise people have built up in learning how to use/configure it. So retirement won't get rid of it. Rewriting it may just lead to creation of new security flaws (for example, openssh, is a far more modern code which is far more motivated to be secure from the get go, but as recent advisories/exploits have shown that doesn't make it magically bug-fre

  • Yay! (Score:5, Funny)

    by Greyfox ( 87712 ) on Wednesday September 17, 2003 @02:15PM (#6987470) Homepage Journal
    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!

  • Lazy Story Submitter (Score:4, Informative)

    by Peridriga ( 308995 ) on Wednesday September 17, 2003 @02:16PM (#6987474)
    Just point to the ftp site?
    Aight... I'll fill in the blanks

    ftp://ftp.sendmail.org/pub/sendmail/RELEASE_NOTE S

    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.
    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. Problem noted by Timo Sirainen.
    Accept 0 (and 0/0) as valid input for set MaxMimeHeaderLength.
    Problem noted by Thomas Schulz.
    Add several checks to avoid (theoretical) buffer over/underflows.
    Properly count message size when performing 7->8 or 8->7 bit MIME
    conversions. Problem noted by Werner Wiethege.
    Properly compute message priority based on size of entire message,
    not just header. Problem noted by Axel Holscher.
    Reset SevenBitInput to its configured value between SMTP
    transactions for broken clients which do not properly
    announce 8 bit data. Problem noted by Stefan Roehrich.
    Set {addr_type} during queue runs when processing recipients.
    Based on patch from Arne Jansen.
    Better error handling in case of (very unlikely) queue-id conflicts.
    Perform better error recovery for address parsing, e.g., when
    encountering a comment that is too long. Problem noted by
    Tanel Kokk, Union Bank of Estonia.
    Add ':' to the allowed character list for bogus HELO/EHLO
    checking. It is used for IPv6 domain literals. Patch from
    Iwaizako Takahiro of FreeBit Co., Ltd.
    Reset SASL connection context after a failed authentication attempt.
    Based on patch from Rob Siemborski of CMU.
    Check Berkeley DB compile time version against run time version
    to make sure they match.
    Do not attempt AAAA (IPv6) DNS lookups if IPv6 is not enabled
    in the kernel.
    When a milter adds recipients and one of them causes an error,
    do not ignore the other recipients. Problem noted by
    Bart Duchesne.
    CONFIG: Use specified SMTP error code in mailertable entries which
    lack a DSN, i.e., "error:### Text". Problem noted by
    Craig Hunt.
    CONFIG: Call Local_trust_auth with the correct argument. Patch
    from Jerome Borsboom.
    CONTRIB: Better handling of temporary filenames for doublebounce.pl
    and expn.pl to avoid file overwrites, etc. Patches from
    Richard A. Nelson of Debian and Paul Szabo.
    MAIL.LOCAL: Fix obscure race condition that could lead to an
    improper mailbox truncation if close() fails after the
    mailbox is fsync()'ed and a new message is delivered
    after the close() and before the truncate().
    MAIL.LOCAL: If mail delivery fails, do not leave behind a
    stale lockfile (which is ignored after the lock timeout).
    Patch from Oleg Bulyzhin of Cronyx Plus LLC.
    Portability:
    Port for AIX 5.2. Thanks to Steve Hubert of University
    of Washington for providing access to a computer
    with AIX 5.2.
    setreuid(2) works on OpenBSD 3.3. Patch from
    Todd C. Miller of Courtesan Consulting.
    Allow for custom definition of SMRSH_CMDDIR and SMRSH_PATH
    on all operating systems. Patch from Robert Harker
    of Harker Systems.
    Use strerror(3) on Linux. If this causes a problem on
    your Linux distribution, compile with
    -DHASSTRERROR=0 and tell sendmail.org about it.
    Added Files:
    devtools/OS/AIX.5.2

  • Fix this at the language level? (Score:3, Interesting)

    by ajiva ( 156759 ) on Wednesday September 17, 2003 @02:16PM (#6987476)
    You'd think that it would be easy to fix this at the language level. It can't be that hard to create a string library that automatically ignores everything past the end of the string.
    • Yes, in order to make sendmail even more convoluted, I recommend it be rewritten in perl. Or maybe javascript, that would work too.
    • If you go out of bounds on an array, you get an exception. In fact it it's possible to compile C and C++ apps to prevent this. For example, Microsoft's C++ debug-mode compiler creates buffers around each freshly allocated memory space and checks them after each time you allocate more memory. It's not a perfect solution, but it helps a little bit. I would think these overflow 'sploits come from pre-allocated memory though (otherwise you wouldn't theoretically know where the code was going to be in memory.

  • sendmail == microsoft (Score:2, Interesting)

    by autopr0n ( 534291 )
    Seriously, it seems like these guys have about as many security holes per line of code as MS (but obviously MS has a lot more code). Anyway, why does anyone use sendmail anymore? The difference between configuring sendmail and configuring postfix is like the difference between banging your head on the wall and having sex with the most beautiful woman on earth [google.com].
    • The difference between configuring sendmail and configuring postfix is like the difference between banging your head on the wall and having sex with the most beautiful woman on earth.

      Somebody will pay you to bang your head on the wall?

      BTW, no way [stuffmagazine.com].

  • Nice week for open source (Score:5, Insightful)

    by gmuslera ( 3436 ) * on Wednesday September 17, 2003 @02:17PM (#6987489) Homepage Journal
    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.
  • Does anyone have a good explanation of how a buffer overflow allows you to execute arbitrary code? It seems to me that the memory that gets overwritten is some what random. It is either the stack or some memory in dynamic store. It seems like each time you sent in the overflow data it will be writing a different area of memory so you don't know if you code will get executed or not. Since you have to start executing at the right place you would almost never be able to execute your code.
    • It's all about offsets. If you know how far the 'jump' is to the next executing line, you can overflow the buffer by just the right amount to put your code there rather than theirs.

      At least, that's the senior-level CS major explanation...

    • Re:How does an overflow work? (Score:4, Informative)

      by Second_Derivative ( 257815 ) on Wednesday September 17, 2003 @02:30PM (#6987664)
      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.
    • because of the addressing scheme used in Intel processors, and the standard ways of creating buffers in C and how they get executed.

      When you create a buffer it tends to use *short* addressing, which means the buffer location is NEAR the code that is being executed. Generally something like,

      Store a char
      Increment buffer pointer by one,
      am I done?
      No repeat

      The problem is that if the buffer "overflows" it wraps the addressing to back over the instructions being executed.

      And it turns out that this behavior i

      • Yh..... fffsdfksjkldll.... WHAT? (Score:4, Interesting)

        by pr0ntab ( 632466 ) <pr0ntab.gmail@com> on Wednesday September 17, 2003 @09:34PM (#6990885) Journal
        What are you talking about? Can you name a single network operating system since the late 80s that doesn't use virtual memory with 32-bit or larger pointers?!

        Who modded this up?

        There is no way in hell you'll cause a pointer to wrap around and come back up since if you write to the page mmaped at 0 on essentially every OS out there you get a page fault (and the OS kills the program, Null pointer exception). And before that you walk all over the pages that are between the break and stack, unallocated, or maybe all over the read-only shared libs, and they all will cause page faults and SIGSEGV your ass into next Tuesday.

        Here's krog. Krog allocate automatic variable on stack. Stack grow downward. Data fills from lower to upper address (opposite stack growingness). Krog no check length of input. Krog overwrite stack not belonging to his stack frame (previous call). Ooomba, clever hacker, he know offset to return address in leaky function. OOmba, he sendum nasty input Krog no check length on that overwrite return address. When function return, it jump back into buffer instead of last function. Buffer gottem nasty root shell code, not data.

        Krog sad.

        Ooomba does happy dance.

        Yes. Check your inputs.

        YES DONT ASSUME YOU KNOW ANYTHING ABOUT HOW LARGE A BUFFER IS

        YES, FOR GODS SAKE PEOPLE, NEVER ALLOCATE BUFFERS AS AUTOMATIC VARIABLES ON THE STACK!!! ARE YOU INSANE!!!!!!!!>?>>>>>>>

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

  • Gasp!

    Why, this is totally unprecedented!

    This hasn't happened since...uhm...well...for at least about 15 minutes now.

  • Before the Microsoft defenders say it... (Score:3, Insightful)

    by ReelOddeeo ( 115880 ) on Wednesday September 17, 2003 @02:21PM (#6987558)
    Before all the Microsoft apologists jump in and point out that any system can have vulnerabilities, and Linux users should not bash Microsoft.

    It is true that any system can have unintentional bugs that lead to security vulnerabilities. This is true of any system and not just Microsoft. Therefore, Microsoft should not be unfairly bashed due to these kinds of bugs, any more than any other system.

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

    Examples would include, running a webserver under the System or Administrator account so that once it is compromised, the system is rooted. Installing and activating services by default. These problems are all caused by security having a low priority in the past, and Microsoft is deservedly bashed for these. Nimbda or Slammer may be buffer overflows which could happen to anyone, but there is some deserved criticism as to why it was such a huge problem.

    No doubt, sendmail also deserves some criticism.

    I wonder how many Linux/Apache systems get web pages defaced via. SQL injection or other PHP related attacks, but do not lead to the box being rooted? Any numbers?

    • Re:Before the Microsoft defenders say it... (Score:5, Informative)

      by TheNetAvenger ( 624455 ) on Wednesday September 17, 2003 @03:48PM (#6988420)
      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
  • I experience daily buffer overflows receiving mail.
  • Anytime a MS product and a competing product go head to head, everyone talks about the Anti-MS product working better...

    Well, why is Sendmail's Overflow more "Buff" than Exchange's???

    Will its "Buffer" Overflow run on a 64bit processor? Did it get "Buffer" legally, or like so many from the Open Source movement, is it on drugs of some kind that just make it SEEM "Buffer"?

    Why would you want your Overflow to be "Buffer" anyways? We should be saving resources as much as possible and overflow is wasteful so

  • I didn't realize Microsoft wrote sendmail! (Score:3, Funny)

    by Junks Jerzey ( 54586 ) on Wednesday September 17, 2003 @02:25PM (#6987608)
    But they must have, because there are no bugs in any software that runs under Linux. There never have been, and there never will be.

  • Who cares? (Score:2, Informative)

    by Kevin DeGraaf ( 220791 )
    Who cares? Sendmail is obsolete.

    qmail [cr.yp.to]
    postfix [postfix.org]
    exim [exim.org]

  • This was mentioned on bugtraq (Score:2, Informative)

    by Anonymous Coward
    Sendmail 8.12.9 prescan bug [securityfocus.com]

    attack details:

    Local exploitation on little endian Linux is confirmed to be trivial
    via recipient.c and sendtolist(), with a pointer overwrite leading to a
    neat case of free() on user-supplied data, i.e.:

    eip = 0x40178ae2
    edx = 0x41414141
    esi = 0x61616161

    SEGV in chunk_free (ar_ptr=0x4022a160, p=0x81337e0) at malloc.c:3242

    0x40178ae2 : mov %esi,0xc(%edx)
    0x40178ae5 : mov %edx,0x8(%esi)

    Remote attack is believed to be possible.
    It also seems tha
  • I feel like my week isn't complete without patching Sendmail at least once. Ahhh... return to normalcy. I feel better.

  • OMFG (Score:4, Interesting)

    by lspd ( 566786 ) on Wednesday September 17, 2003 @02:36PM (#6987727) Journal
    When did everyone decide the standard way of fixing security bugs was no longer worth the effort. You don't release a new version with a security bug fixed until all the distros have been contacted and the fix has been backported. Why have Sendmail and OpenSSH decided this no longer applies to them? Is Apache next? Are they going to force an upgrade to Apache 2 by rolling security fixes into beta versions and not bothering to tell anyone before they are released?

  • Look I know (Score:3, Funny)

    by IWantMoreSpamPlease ( 571972 ) on Wednesday September 17, 2003 @02:37PM (#6987747) Homepage Journal
    that many in the Open Source Community are content to imitate Microsoft's latest offerings, but copy exploits is, in my opinion, going too far! ;-)

  • difference between MS bugs and OS bugs (Score:4, Interesting)

    by Twister002 ( 537605 ) on Wednesday September 17, 2003 @02:44PM (#6987797) Homepage
    The big difference between bugs found in MS products and bugs found in Open Source products seems to be: Bugs in Open Source products seem to make the /. front page the same day a patch is released. MS product bugs are posted about days before a patch comes out.

    Of course that could be because the OS projects fix their bugs as soon as they find them rather than having to wait for the red tape to clear up.

  • I suspect this story is fradulent (Score:3, Funny)

    by RLiegh ( 247921 ) on Wednesday September 17, 2003 @02:51PM (#6987856) Homepage Journal
    as I cannot believe that sendmail would have an exploit (remote or otherwise) given its' history.

  • Why sendmail anyway? (Score:3, Informative)

    by ArchAngelQ ( 35053 ) on Wednesday September 17, 2003 @02:55PM (#6987875) Homepage Journal

    Sendmail has remote exploits every couple of months at best. Why is anyone suprised any more? It's not as if it's easy to set up, administrate or is horribly high performance. It's about as middle of the road as you get. As many have pointed out before I'm sure, this is exactly why we complain about software from microsoft (and I mean just the software, not it's licences nor the biz tactics associated with it).

    So why not look for alternatives, all you sysadmins out here? I for one prefer qmail [cr.yp.to]. There are plenty of others.

    I know it's hard to switch to a new system when you've gotten profficent in configuring something well, especially when you are so busy using it that you don't have time to play with something new to see if can work for your setup. But I can't see that running a frequently exploited mail server will cause anything but more work.

  • This is getting silly (Score:5, Informative)

    by jd ( 1658 ) <imipak@ y a hoo.com> on Wednesday September 17, 2003 @02:57PM (#6987892) Homepage Journal
    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.

  • Perpetual newpaper (Score:3, Funny)

    by perp ( 114928 ) on Wednesday September 17, 2003 @05:14PM (#6989150)
    There was a Dilbert strip where Dogbert tried to sell Dilbert a "perpetual newspaper"; only a thousand dollars and you'll never need to buy another newspaper!

    The headlines were like "Pope Denounces Violence" and "Real Estate Values Rise" and "Unrest in the Middle East". I think that "Buffer Overflow Found in Sendmail" would have been a worthy addition to the Tech Pages.

  • Sendmail 5th on the list (Score:3)

    by twoslice ( 457793 ) on Wednesday September 17, 2003 @05:42PM (#6989360)
    Buffer Overflows in Sendmail rank 5th on this list.

    Vulnerability list [orthus.com]

Slashdot Top Deals

THEGODDESSOFTHENETHASTWISTINGFINGERSANDHERVOICEISLIKEAJAVELININTHENIGHTDUDE

Close