full-disclosure - Microsoft MCWNDX.OCX ActiveX buffer overflow

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <002401c3637f$8f2a8230$0c351c41@basement>
From: mattmurphy at kc.rr.com (Matthew Murphy)
Subject: Microsoft MCWNDX.OCX ActiveX buffer overflow

"Georgi Guninski" <guninski@...inski.com> writes:
> So you are collecting 0days for free, put them in a lame database and
whine more
> than a script kiddie this is a hard job?

You have absolutely no point here, Georgi.  The CVE for one is hardly a
database -- it is more or less a list of lists of references on various
vulnerabilities that are submitted *to* CVE (i.e, not every vulnerability
that David Ahmad finds in project changelogs somewhere).  I don't think
you'll have any support for calling CVE "lame".  CVE has been a solution to
the problem of multiple and confusing names for vulnerabilities.  Simply
looking at the anti-virus industry's constant "name game" when it comes to
viruseses, such as its many different names for "Blaster" (aka
W32-Blaster-A, Win32/Blaster, Win32.Blaster.worm, Win32/Poza.A,
Win32/LovSan.worm, ...), will show you the problem that CVE has helped to
eliminate.

I've yet to see Steve "whine" -- he has never voiced a complaint without
presenting a valid point, backed up by very good research, and usually
provides solutions where possible.  The point that CVE is "collecting 0days"
is also completely inaccurate.  Usually, when CVE assigns an identifier to a
vulnerability without publicly disclosed details, one of two things happen.
Either CVE assigns a pool of IDs to the vendor to assign as issues are
reported, or the vendor requests a candidate assignment to CVE on a
per-issue basis.  Sometimes, a combination of both occurs.  Obviously, when
the former strategy is chosen, details are not revealed to CVE until the
formal announcement is made, and my experience suggests that this is true in
the latter case as well.

Additionally, Steve's point was that inaccurate advisories slow CVE's
response -- he never said that CVE maintenance was a "hard job".  Even so,
it probably is -- that just means that Steve's not a complainer. :-)