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

Comments

Sendmail's future

[nepheles]

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

Fix this at the language level?

[ajiva]

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.

sendmail == microsoft

[autopr0n]

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.

How does an overflow work?

[jumpingfred]

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.

Re:How does an overflow work?

[barfy]

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 is not random, and you can depend on precisely what character will overwrite the code that is being executed and you write a jump statement to replace the store a char instruction into the buffer and your code starts executing... Voila, a buffer overflow exploit.

It *WAS* standard coding practice in the good old days to place the burden of correctly sized and or terminated inputs onto the code that was creating the string to be inputed. This prevented the need for excessive cycles being wasted making sure that there wasn't bad input going into the buffer. And in the good old days this was the correct thing to do. Which is why all the code was written this way, it was *good* design.

Today it turns out, that the risk of *malware*, code designed to take advantage of this behavior, for nefarious use is greater than the waste of cycles to detect bad code (which is a lot of cycles wasted). So the code needs to be rewritten to check for malware. This is the NEW good design, but it requires a massive effort to change old practices to new practices. Stuffing inputs into buffers is probably one of the most common of all operations done on computers. And changing all this code, and preventing new code written in the old way (because the code will operate correctly in the absence of malware) is a big and important effort.

Re:How does an overflow work?

[pegr__]

But you don't have to know exactly where the jmp, etc. is... Pad your exploit code with my favorite instruction, NOP (No OPeration). If you have some idea where the pointer is going to land, just start writing a few hundred/thousand/million NOP's, then your code. As long as the pointer lands in NOP-land, it will eventually get to your code.

Besides, NOP is one of the FASTEST executing instructions there is! I use them in all my programs to enhance performance...

OMFG

[lspd]

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?

difference between MS bugs and OS bugs

[Twister002]

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.

Why support MS and get spam?

[msimm]

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

Re:"Email Different"

[Stevedust]

For disposable email accounts (for site registrations etc), take a look at Mailinator. It offers automatically generated mailboxen, which are deleted after a few hours.

Yh..... fffsdfksjkldll.... WHAT?

[pr0ntab]

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

Re:Before the Microsoft defenders say it...

[Anonymous Coward]

and since that doesn't seem to help Windows NT, that means Microsoft should be DOUBLY ashamed?

Seriously, no one doubts Microsoft's technical abilities. They have a lot of smart people working there. That's why I'm baffled that they aren't blowing the doors off Linux in terms of security. It's pretty sad that a 40 billion dollars-in-the-bank thousands-of-PhD's company is "neck and neck" or maybe even behind the "geeks and high-school students".