[VIM] Sendmail vendor dispute - CVE-2006-4434 (fwd)

[security curmudgeon]

: I gave the standard response to the criticism in the last paragraph, 
: with the observation that we vdb's had reported it because OpenBSD did.

Since i'm not paid to work on a VDB and not doing this in any official 
capacity, i'll respond to this paragraph!

: 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/
: 
: Claus Assmann
: (current maintainer of sendmail)

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, 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
8.7.6/8.7.3     96/09/17
        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.


# 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.
#
# mudge at l0pht.com

[working exploit snipped]