[VIM] Vulnerability fixed in E-gold (fwd)

security curmudgeon jericho at attrition.org
Wed Mar 22 19:39:49 EST 2006

: > I know the VDB's don't track site specific bugs for the most part
: I'm starting to think that this is a bit of an issue, from the respect 
: of monitoring the space of "all known" vulnerabilities, no matter where 
: they live or how ephemeral they are.  It feels like we're missing out on 
: a bit. The existing DBs out there do have good reasons for not tracking 
: these, but it would be a good thing if someone did it.

OSVDB is fairly sure that tracking them is important, and will do it at 
some point. There are several issues in doing so that give us pause 
though. Unlike most vulns, you can't easily track some data that we 
normally do such as product info, versions, solution etc.

Product info becomes site name and function? Versions become dates? 
Solution would always be "use the site after X date" which doesn't make 
a whole lot of sense. 

: > Has anyone else considered doing this in any fashion? What are the pros
: > and cons in your eyes?
: The con would probably be the sheer amount of issues (XSS would be king, 
: and high risk in this context).  I imagine there would be high 
: analytical expenses to distinguish a site-specific issue from a problem 
: in a third party package that the site is using.  Actually, this expense 
: is starting to show up in CVE, just so we can decide whether or not to 
: include something.

Another big issue. www.example.com is reported as being prone to an XSS or 
SQL injection. The real question is.. is it code they generated, or do 
they use an underlying commercial package that has the vuln? This is 
probably one of the biggest turnoffs for tracking such vulns, especially 
given the lack of detail/research seen in many disclosures.

: The pros would be similar to the pros of disclosure in distributed 
: software, although the same cons would be inherited too.  e.g. someone 
: might hear "XSS in Google" and assume there was some major obvious 
: mistake, even if it required a really obscure attack that took advantage 
: of broken browsers and non-standard behavior.

Most databases have a mechanism to disclaim such requirements, but is that 
enough? If you post that Google has an XSS in FeatureC, and you can get it 
to work only via a Proxy using JerBrowse 3.0 .. does that tell us that 
it's only available via that setup and vector? Of course, we can argue 
this same thing with any other disclosure that puts criteria on 
exploitation.. so is it the fact that X million people use Google that 
should make us consider this more carefully?

: I VERY loosely track these kinds of issues if they're posted to Bugtraq, 
: but they're not in any central location.  Rather, I don't completely 
: throw away the reference.  CVE will be making some internal process 
: changes that might allow this tracking to happen a little more cleanly, 
: but I'm not sure when that would happen.

I save the mail off to a subdirectory. Not very organized, but all in one 
place and I can use the excellent search engine 'grep' =) At present, 182 
files in that directory.

More information about the VIM mailing list