This article is more than 1 year old
Sendmail and secure design
Ancient code base and long vuln history
Ultimately, new code, or old code that continues to change drastically, becomes less secure. And if an application isn't written with a secure design, this can have a far-reaching effect on its security. But, let’s get back to Sendmail.
A security track record
So, if Sendmail is such an old program, why are people still finding vulnerabilities in it? I've touched on it in another article which looked at trusting open-source software. An application's security track record is often closely tied to its future. If you look at the track record for Sendmail, you'll find a lot of problems with it, especially in earlier versions.
Both the type and quantity of the bugs discovered in a product can be indicative of its quality. Although vulnerabilities are unavoidable, when auditing software, simple bugs are likely to be found first. The discovery of obscure and circumstantial vulnerabilities later on may indicate that past auditing has been thorough, and that the software is devoid of the basic and embarrassing bugs that can affect poorly written software. If a project has recently been plagued by basic buffer overflow or format string vulnerabilities, this might be a pretty good indication that the underlying code wasn't written with any sort of security in mind.
Secure by design
Perhaps one of the biggest problems with Sendmail is that, by default, it is parsing all sorts of remote, untrusted input as root. There's no excuse for that. It's turning a significant vulnerability into a vulnerability capable of remote root, and for no good reason.
Sendmail might be a relatively old application, but it wasn't designed with the ultimate goal of security in mind. Sendmail's liberal use of root access exacerbates these problems. It's been audited by a lot of very talented people, and problems continue to be found with it. However, they do continue to be more obscure, and one has to wonder how many show stopper issues could possibly remain undiscovered Personally, I'm not banking on this being the last one - especially given that the underlying problem with ISS's recent Sendmail bug was already documented.
Besides, there's just too much code that runs as root by default When choosing software, one should look for applications with a good security track record and a solid design that mitigates the impact from the vulnerabilities that do manage to get into the code. While, I don't have personal experience with Postfix, but I've heard good things about it. And of course, there's always qmail, which I've written about before as being "almost" a model for security.
Ultimately, you've got to trust some applications. Make sure you trust the right ones.
This article was first published at SecurityFocus