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]