Re: full disclosure

From: HC (keydet89@yahoo.com)
Date: 06/07/02


From: HC <keydet89@yahoo.com>
Date: Fri, 07 Jun 2002 07:15:20 -0400


> As long as vendors continue to act as if
> the problem isn't the security hole but our knowing about the security
> hole, full public disclosure is the only protection the rest of us
> have.

I'm not going to defend vendors that keep the information on
vulnerabilities secret until a third party discloses the info...I think
it's a "Very Bad Thing(tm)".

However, Bruce Schneier is quoted as saying something along the lines of
security being a business issue. Take the MS gopher
vulnerability...yes, there is a vulnerability, but what is the risk
associated with it? Was it discovered b/c it's currently being used?
Has anyone fallen victim to a compromise and lost sensitive data to this
exploit?

Well...as far as I've seen, the answer is no. Therefore, the vendor
most likely assumes that there is very low risk.

This is true for a lot of vulnerabilities specific to MS...they are
discovered not b/c some kiddies or "underground blackhats" are stealing
sensitive corporate and gov't data, but b/c some researcher finds it in
a lab environment, verifies it, and reports it. The same was true w/
the BubbleBoy virus...it was originally proof-of-concept (before the
code was somehow released). Look at NTFS alternate data streams...in
the past year, 4 separate bits of malware (3 of them viruses) have come
out, starting w/ Benny and Ratter's (of 29A fame) W2K.Stream virus...and
yet MS has *no* tools in either the distro or RK for alerting the admin
to the presence of ADSs. Has there been an Explorer plugin for showing
these things? Do A/V companies cover ADSs?

NOTE: More on ADSs can be found here:
http://patriot.net/~carvdawg/docs/dark_side.html

My point is exactly the same point made about corporate and gov't
entities w/ regards to security these days...unless a company faces a
major incident, there will be NO impetus for security. Vendors are NOT
inclined to commit resources to clean up a mess in their code/products
unless the threat is very, very real. Over the past couple of years,
and in particular the last couple of months, most of the incidents
directed at MS systems have been annoying and messy, but for the most
part, not damaging. Many of the vulnerabilities discovered have been
found in lab environments, and are found to be dangerous due to default
implementations of MS products (Code Red could have been halted in less
than 15 seconds by simply disabling the ida/idq script mappings). It
seems that for the most part, the majority of the incidents to MS
systems has been web page defacings...and who cares about that?

Look at the worms that have come out...Code Red, Nimda, Masy, SQLspida,
Digispid...while they "look" like big hairy beasts, and some of them
have been effective, their effectiveness has been largely due to lack of
attention to detail on the part of the admins. They have been noisy and
easily detected. And for the most part, they haven't been destructive
in and of themselves...data hasn't been quietly stolen, damaged, or
destroyed.

So, to address the original question, perhaps the reason that vendors
like MS seem to be slow to respond (ie, not responding as quickly as
Dave and others want) is b/c there is no impetus...business or
otherwise...to do so. If a researcher presents code that he's developed
to demo an exploit, MS is going to assume that absent other reports,
he's the only one to have the code...wild speculation and assumptions
that "the underground" already has it are just that...assumptions. MS
might decide to sneak that fix into the next major Service Pack, simply
b/c they're not seeing the exploit used to threaten national security.

Just some thoughts...

Carv



Relevant Pages

  • Re: full disclosure
    ... > the problem isn't the security hole but our knowing about the security ... I'm not going to defend vendors that keep the information on ... Was it discovered b/c it's currently being used? ... This is true for a lot of vulnerabilities specific to MS...they are ...
    (comp.security.misc)
  • [Full-Disclosure] Was: Full Disclosure = Exploit Release - No disclosure No Fix
    ... For the bigger vendors, statistics will iron out mistakes - and ... Would you write a script for that - unlikely. ... 588 new vulnerabilities were posted on major lists. ... To this list of unanswereable questions I could add the ratio of security ...
    (Full-Disclosure)
  • Re: [Full-Disclosure] RE: Disclosure policy in Re: RealPlayer vulnerabilities
    ... you wrote that I do not really believe in "full disclosure" ... Vulnerability is discovered and the vendor is notified. ... I am not talking about the absolute security. ... you say that vendors must work much harder at reducing patch ...
    (Full-Disclosure)
  • Re: [Full-Disclosure] Microsoft Cries Wolf ( again )
    ... response to your posting here, seem to be a point of taking potshots at ... the vendors products. ... > administrators of security issues. ... > security vulnerabilities, most of it is not valid. ...
    (Full-Disclosure)
  • Re: [Full-disclosure] MSIE (mshtml.dll) OBJECT tag vulnerability
    ... Is this the fault of full disclosure? ... mitigation or security assets are required. ... away from vendors whose security processes are colossal failures. ... people will be out there taking apart those patches and finding what ...
    (Full-Disclosure)