From: joel at helgeson.com (Joel R. Helgeson)
Subject: Vulnerability Disclosure Debate

<SNIP>
> > Also, full disclosure, including exploit code, frees you from the
> > obligation to believe in software vendor advisories and patches -
> > another critical issue, demonstrated again by the RPC/DCOM flaw:
>
> Exploit code *does not* solve the problem.  I can do just as well by
> providing no code, and just being descriptive with my details, as I can by
> providing code.  I've provided code with some advisories; this is not a
> practice I engage in any longer.  It really speaks poorly for the writing
> capabilities of the discoverer if they are incapable of offering
sufficient
> detail to at least reproduce the flaw without providing exploit code.
> Exploit code, while it can conclusively prove that the vulnerability
exists
> in a particular config, is not 100% accurate (offsets can be bad, for
> instance), and this can even create a false sense of security.  Further,
you
> don't get any solution by running an exploit.

It doesn't matter how much detail they offer.  I want to be able to take an
exploit, compile it and run it against a test server on a test network.
Capture the packets transmitted and analyze them. I want to dissect the
'worm' or 'virii' and develop an IDS signature as well as produce a Nessus
plugin to scan other servers.  If I use other tools, I want to have enough
knowledge to look into their signature files to realize that they're looking
for the wrong stuff and thereby giving false positives (or false negatives).

Are you telling me that I can do that with a *really descriptive set of
documentation*?  I don't think so.  Gimme the code for the exploit.

We are going to continue down this road of FD debate until M$ et al. start
writing secure code.  I have said it many times; Requiring patches to
achieve security is fundamentally flawed. Coders need to write secure code.
The onus is on them to keep the net secure.  Don't blame the
hackers/crackers for airing their dirty laundry / wiping their collective
arses with the M$ flag.  If M$ loses market share because they consistantly
release insecure code that is repeatedly being compromised then that is
their fault.

It was only after being repeatedly beat over the head with the proverbial
lead pipe by the hacker community that good ole Bill Gates sent out a memo
stating that Security is becoming Microsofts #1 priority.  Do you really
think he would have done that if we didn't have the Full Disclosure in
place?  We should not rely on 'security by obscurity' by keeping the
exploits secret, or keeping the information reserved for the security elite.

If it weren't for FD, we'd have more 0day exploits because companies would
not feel the pressure to release timely updates. It chews up development
cycles to go back and put an emergency fix in place for insecure code, test
it, and release it.  Do you think companies would do this voluntarily?  I
think not.  Too expensive. They'll include it with their next major update
and charge for the upgrade or some crap like that.  Meanwhile, the news of
the exploit gets into the wrong hands where some 1337 h4x0r develops code
and releases it to a world of completely unpatched machines...

I say the medicine is bad, but the disease is worse.  Full Disclosure is the
Medicine, bad coding the disease.

</snip>
>
> > Apparently, M$' fix doesnt really fix the problem to its full extent,
> > and in some cases, is believed to leave machines vulnerable to the
> > attack. Again, something which was to be discovered by END USERS loading
> > proof-of-concept exploits and trying them on their own systems. To me,
> > it makes no sense to blindly trust in a software vendor's patch, when it
> > has repeately been shown that software vendor's patches often do not
> > fully provide the anticipated security fixes.
>
> And exploit code, of course, fills that gap, right?  You are talking about
> two different things here.  MS03-026 certainly does mitigate the
> vulnerability at hand.  Also, you must remember that vendor patches are
only
> designed to protect against vulnerabilities that immediately impact the
> system being patched.  In a perfect world, ports 135, 139, and 445 would
be
> completely blocked by every machine that was connected to the internet,
and
> be used for LAN services only (the intended purpose of these services).
> This would effectively make patch installation a moot point, as well as
> preventing exploitation of any future RPC-related vulnerability.
>
> > Obviously, time has NOT yet come to say goodbye to full disclosure, and
> > doing so would leave end users at the fate of some sotware producers'
> > industry consortium to take care of OUR security - which they have
> > repeatedly shown to be incapable of.
>
> This depends on how you define Full Disclosure.  I strongly believe that
> details of vulnerabilities I find should be made available to the public.
> This is how I define Full Disclosure.  Most security researchers today
have
> adopted the more rational viewpoint that Full-Disclosure does not require
> exploit code, as it has been proven many times (and will continue to be
> proven) that exploit code does far more damage than good.  I also feel
that
> those who require that vulnerabilities be disclosed immediately (or after
> some other short period), are harming the concept.  The idea of Full
> Disclosure is that the public has the best opportunity for remedial
action;
> this usually includes vendor fixes.
>
> In today's environment where every new vulnerability is a time bomb, we
must
> balance the public's need to know with its requirement for suitable
> solutions.
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>

Powered by blists - more mailing lists