Buffer Overflow in Sendmail 478
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."
Sendmail's future (Score:4, Interesting)
Fix this at the language level? (Score:3, Interesting)
sendmail == microsoft (Score:2, Interesting)
How does an overflow work? (Score:2, Interesting)
OMFG (Score:4, Interesting)
difference between MS bugs and OS bugs (Score:4, Interesting)
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.
Re:How does an overflow work? (Score:3, Interesting)
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? (Score:2, Interesting)
Besides, NOP is one of the FASTEST executing instructions there is! I use them in all my programs to enhance performance...
Why support MS and get spam? (Score:5, Interesting)
Re:"Email Different" (Score:3, Interesting)
Yh..... fffsdfksjkldll.... WHAT? (Score:4, Interesting)
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... (Score:1, Interesting)
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".