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 for Android: free password hash cracker in your pocket

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

Message-ID: <002e01c36386$f792b3e0$2b02a8c0@dcopley>
From: dcopley at eeye.com (Drew Copley)
Subject: Microsoft MCWNDX.OCX ActiveX buffer overflow


> -----Original Message-----
> From: full-disclosure-admin@...ts.netsys.com 
> [mailto:full-disclosure-admin@...ts.netsys.com] On Behalf Of 
> Matthew Murphy
> Sent: Friday, August 15, 2003 3:50 PM
> To: Full Disclosure
> Subject: Re: [Full-Disclosure] 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. :-)

It is apparently underfunded. They do have a generally slow response to
many issues. As someone that often deals with these databases, I have
noticed that numerous, well proven flaws remain in the candidacy stage
-- with no good reason whatsoever. But, it is free, to me, so I am not
complaining. 

Securityfocus and their bid system tends to be quite a bit more useful
in daily research. (Surely, greatly more useful than the CVE
"candidates" which often have little or pointless references, and rarely
ever a reference to the actual information - aka, bugtraq post - which
propelled the creation of the bug in the first place.

Now, this said, such statements should not be seen as a "complaint",
rather as useful criticism.

:)



> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>