Message-ID: <016a01c2c78f$d5a1d9c0$c71121c2@sharpuk.co.uk>
From: DaveHowe at cmn.sharp-uk.co.uk (David Howe)
Subject: [Secure Network Operations, Inc.] Full Disclosure != Exploit Release

> 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.

Powered by blists - more mailing lists