Message-ID: <1043868366.4468.145.camel@localhost.localdomain>
From: simon at snosoft.com (ATD)
Subject: [Secure Network Operations, Inc.] Full
	Disclosure != Exploit Release

Dave, 
	Thanks for your input.  I will be considering your points for our final
decision on how to release exploit materials.  The problems that we have
been running into is that releasing exploits tends to harm our client
base. How could we avoid the client "immage" damage?


On Wed, 2003-01-29 at 07:13, David Howe wrote:
> > I have been following the subject of full disclosure
> > for a while, and as most of you know, have dealt with
> > some of the issues that full disclosure can cause
> > (HP/Secure Network Operations/DMCA).  While the
> > idea of full disclosure is a good idea, and while we
> > support it, we feel that the exploit source code should
> > not be released to everyone.
> That is of course your choice. Vendors in particular were prone to deny
> a vunerability existed unless exploit code were published to prove it.
> However, as part of a managed announcement, I can't see any value
> outside of the obvious - to allow admins to scan for vunerable systems
> on their own network - as a vendor has already produced a patch.
> Note I say *a* vendor though - sometimes using the scan tool against
> theoretically unrelated systems produces surprising results....
> 
> > It is possible to prove a vulnerability exists by releasing
> > well written advisories.
> No, it isn't.
> If the advisory is truely Full Disclosure, it will contain enough
> information that the exploit can be written *anyhow*. By not attaching
> such an exploit, you make it impossible for many less skilled
> administrators (who are diligent enough to closely monitor lists like
> this one, but don't have the coding skills required to write (for
> example) a arp packet rewriter) to test their own systems.  Note however
> that, given that *testing* is the goal here, not actual exploitation, a
> suitably written testing spec (a nessus plugin for example?) may well be
> more useful to the bulk of the readers of this list than an actual
> exploit would be; sysadmins do not want to exploit their own systems,
> they want to test them.
> 
> > Proof of concept code is useful for legitimate contract
> > based penetration tests.
> Again, not really. pentesters should not be exploiting the holes they
> find (unless you wish to daisychain your way into a more secure area -
> such as the effect of the DNS bug on a system foolish enough to be
> running their DNS server on a internet-exposed but non-dmz/internal
> host.
> 
> > It is also useful for study as it demonstrates
> > fundamental flaws computers today (not built
> > in security). But again, proof of concept code
> > is not for everyone.
> again, actual exploit code is not needed. the disclosure advisory should
> give a detailed enough description of the general principles behind the
> exploit that a skilled researcher could apply that to testing for other
> similar vunerabilities in other packages.
> 
> I don't know about the rest of the list but I would be *overjoyed* to
> see exploit code replaced with nessus plugins in advisories - giving us
> instant, hands-on access to testing tools without the overheads of
> actually working over exploit code to create them.
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
-- 
ATD <simon@...soft.com>
Secure Network Operations, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030129/eafb5451/attachment.bin

Powered by blists - more mailing lists