[VIM] Are we REALLY going to go there?
Steven M. Christey
coley at linus.mitre.org
Tue May 30 03:23:11 EDT 2006
On Tue, 30 May 2006, security curmudgeon wrote:
> I hate to add these to OSVDB but we definitely should. If nothing else,
> the vendor will dispute it or someone will do followup like you said.
There's the third possibility: the claim will get recorded, there will be
no concrete post-disclosure analysis, and it will stick around one way or
another. 2005's spring Adobe occurrence coming to mind... See below for
a couple examples.
> That said, a nice rant reminding these 'researchers' would be nice.
There will always be new researchers who do this. My rant was gonna be
about us VDBs making this problem worse by lending an air of legitimacy to
rumors that can't be verified even if we had all the resources in the
world. We can handle r0t disputes because he at least identifies a
Reference: BUGTRAQ:20040219 PunkBuster SQL Injection Attack
** UNVERIFIABLE **
SQL injection vulnerability in PunkBuster Screenshot Database (PB-DB)
Alpha 6 allows remote attackers to execute arbitrary SQL commands via
the username and password fields of the login form. NOTE: the
original vulnerability report contains several significant
inconsistencies that make it unclear whether the report is accurate,
including (1) PB-DB is really the "PunkBuster Screenshot Database" and
not "PunkBuster" itself; (2) there is no apparent association between
PunkBuster and "Punky Brewster"; (3) the claimed source code is not
anywhere in Alpha 6.
** UNVERIFIABLE **
NOTE: this issue describes a problem that can not be independently
verified as of 20050421. Adobe Acrobat reader (AcroRd32.exe) 6.0 and
earlier allows remote attackers to cause a denial of service
("Invalid-ID-Handle-Error" error) and modify memory beginning at a
particular address, possibly allowing the execution of arbitrary code,
via a crafted PDF file. NOTE: the vendor has stated that the reporter
refused to provide sufficient details to confirm the issue. In
addition, due to the lack of details in the original advisory, an
independent verification is not possible. Finally, the reliability of
the original reporter is unknown. This item has only been assigned a
CVE identifier for tracking purposes, and to serve as a concrete
example of the newly defined UNVERIFIABLE and PRERELEASE content
decisions in CVE, which must be discussed by the Editorial Board.
Without additional details or independent verification by reliable
sources, it is highly likely that this item will be REJECTED.
More information about the VIM