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."
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
The official announcement is here.
:)
I've already downloaded and installed it. Thank goodness for Slackbuild scripts
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.
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.
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)
So are you saying it is designed with security in mind?
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
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
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:
The fact it's separate bugs is clear from the indention in the original (Fscking /. doesn't support PRE)