BTW: it would be nice if your process of creating a candidate for inclusion in the CVE list makes sure that the security contact for the software is informed, so we don’t have to rely on some 3rd party to hear about this “DoS” for the software that we maintain. http://www.sendmail.org/security/
Yes, because the VDBs can maintain a list of vendors and think to mail each and every one regarding the 30 – 60 vulnerabilities disclosed each day. Yes, it is entirely our job to make sure you are informed that your code sucks ass. Had this been any vendor other than sendmail, you wouldn’t be reading this.
Hey Sendmail .. you hold the record, or are tied for, the WORST CODE EVER when it comes to security. Back in August of 1981 you were dealing with “multiple security issues”, you were a core part of the Morris Worm in 1988, and you have been a plague upon security administrators for 25 years. You do not have the right to talk to VDB admins like that sir.
There is a phrase about choosing who you sleep with because you may get fleas or some such. Claus, Sendmail as a program/group/whatever lost *all* rights to bitch about any vulnerability disclosure. In this case, that “3rd party” (you can hear him spitting as he typed that) is someone with OpenBSD, likely Theo de Raadt, who definitely knows security when it comes to coding. If that isn’t good enough, Sendmail (collectively) can shut their pie hole lest they choke on their own words:
SENDMAIL RELEASE NOTES
SECURITY: fix some buffer overruns; in at least one case this allows a local user to get root. This is not known to be exploitable from off-site. The workaround is to disable chfn(1) commands.
Let me quote the comment of another piece of working code as a response:
Hrm… and Eric Allman told me to my face that there were *no* buffer overflows in 8.7.5 — .mudge
This works on systems that have the chpass program runable by users. Tested on FreeBSD, though the vulnerability exists in all Sendmail8.7.5. Granted you need to be able to change your gecos field 😉
The problem is in buildfnam() which lives in util.c – it treats the static allocated array nbuf[MAXSIZE+1], from recipient.c, in an unbounded fashion.
[working exploit snipped]
Steven Christey (CVE) recently posted about vulnerability history and complexity. The recent sendmail vulnerability has brought up discussion about both topics and adds another interesting piece of history to the venerable sendmail package. One point to walk away with is that while sendmail has a long history of vulnerabilities, the last five years have shown the product to be considerably more secure. While overflows still haunt the ~ 25 year old software package, they are growing fewer and requiring considerably more complex methods to exploit them. The latest discovery is by no means a run-of-the-mill remote overflow, rather it takes considerable skill to find and exploit the flaw.
Using vulnerability history to help evaluate the current security posture of software is a bit sketchy, but certainly helps. If a program starts out with standard overflows, race conditions, symlink issues, XSS or SQL injections, it’s basically expected. If years pass and new versions of the same package continue to exhibit the same coding practices that lead to these vulnerabilities, you begin to get an idea of the quality of code as it relates to security. On the other hand, if years pass and the vulnerabilities are published with more time between each, and the difficulty exploiting them increases, it shows the developers are security conscious and producing more secure code. As always, the lack of published vulnerabilities in a product doesn’t mean it is free from defect, just that they possibly have not been found or published.
Fun fact: The first documented Sendmail vulnerability was on Aug 23, 1981.
What is the oldest documented vulnerability? As far as OSVDB is aware, it’s a tie between UNIX-V6 su File Descriptor Exhaustion Local Privilege Escalation and Sendmail Unspecified Multiple Security Issues (yes, we’d love to know the details of the Sendmail issues back then!). These were documented on August 23, 1981, well over 24 years ago.
I’m sure there are vulnerabilities that were discovered and published before that. Does anyone have a copy of the old “Unix Bug List“? Some old t-file or email with an ancient vulnerability? Perhaps a changelog for a product as venerable as Sendmail? We want it, and we’ll reward you for it…
I’m not exactly sure what the reward will be yet. Maybe a gift certificate from one of your favorite shops, maybe some OSVDB swag, maybe something a little more silly, who knows. The rules of this contest:
- The information must be somewhat specific. Sendmail can get away with ‘multiple issues’ and remain vague due to the extensive history behind the program. We need to know some detail about the vulnerability. “BSD 0.83beta had a vulnerability” will not cut it.
- The vulnerability must be documented somewhere. No stories or second hand accounts will work. Changelogs, advisories, email or anything else that can help authenticate it is required.
- It must be a solid vulnerability. Concerns, weaknesses and best practices won’t work.
- Lastly, it must pass the general ‘BS’ test. If our cynical minds detect shenanigans, it doesn’t count.
That’s it! So, beat our two entries from August 23, 1981 and grab a minute of fame on this blog, our appreciation, bragging rights, and whatever reward we come up with. Mail submissions to moderators at osvdb dot org.