Message-ID: <00ee01c2c76d$64ce0060$3744cd3e@INTERNET>
From: Nicolas.Villatte at advalvas.be (Nicolas Villatte)
Subject: [Secure Network Operations, Inc.]FullDisclosure != Exploit Release

IMOH your solution will only avoid people not skilled in assembly
language and programming to use directly the vulnerability. People with
interest in vulnerabilities and exploit usually have those skills or
will have the will to develop them anyway. The proof of concept code is
a convenient way for everybody not to lose time coding the exploit
themselves and test systems against it.

Best regards,

Nicolas.


-----Message d'origine-----
De?: Strategic Reconnaissance Team [mailto:recon@...soft.com] 
Envoy??: mercredi 29 janvier 2003 2:03
??: Nicolas Villatte
Cc?: full-disclosure@...ts.netsys.com
Objet?: Re: RE : RE : [Full-Disclosure] [Secure Network Operations,
Inc.]FullDisclosure != Exploit Release

Good points, 
	One question remains however.  If we are to attach exploit code
to our
advisories, how do we protect the innocent from attacks by malicious
people using our exploit code? I honestly believe that exploits are
digital munitions that should be distributed under restrictions. Do you
agree that a vulnerability can be clearly demonstrated in an advisory by
showing debugger output and explaining the output? If proof of concept
code needs to be made, it could be generated from the detail in the
advisory. Why is that not a solution? 


On Tue, 2003-01-28 at 17:03, Nicolas Villatte wrote:
> The reference to SQL worm was here because this incident triggered
such
> debate a bit everywhere.
> The elite term I used is here to define few selected people that would
> be aware of complementary information around vulnerability, not at all
> some kind of quality distinction.
> The proof of concept or any piece of code will allow to have further
> insight in the vulnerability, I do not believe you can explain in a
> standard way programming related stuff the way you would with a piece
of
> code.
> For me a highly detailed advisory should include a code example, else
it
> is not that highly detailed.
> I never stated you were talking about the SQL worm; it was just used
as
> an example in the current context, and "stabbed" was used more as an
> allegory.
> 
> Best regards,
> 
> Nicolas.
> 
> 
> 
> -----Message d'origine-----
> De : Strategic Reconnaissance Team [mailto:recon@...soft.com] 
> Envoy? : mardi 28 janvier 2003 21:10
> ? : Nicolas Villatte
> Cc : full-disclosure@...ts.netsys.com
> Objet : Re: RE : [Full-Disclosure] [Secure Network Operations, Inc.]
> FullDisclosure != Exploit Release
> 
> Nicolas, 
> 	I think that you should re-read the e-mail that I posted to
> full-disclosure. The message had nothing to do with the recent SQL
worm,
> nor was it even mentioned anywhere. The focus of the message was to
help
> determine legitimate reasons, if any, to release proof of concept code
> to everyone. As I stated, full disclosure is a powerful resource and
> helped to educate the possibly vulnerable. However, is proof of
concept
> code a requirement to educate the possibly vulnerable? My argument is
> that a highly detailed advisory would more than suffice. Now, just out
> of curiosity, where did I mention worm, virus, or even being stabbed?
> 
> 	To answer your question: 
> 
> Do you prefer to be aware of the exploit like the ones that will use
it
> after some modifications or do you prefer only some "elite" is able to
> harm the systems?
> 
> I prefer to be aware of the vulnerability and to know how to fix the
> vulnerability. Once the vulnerability is repaired, all of your
exploits
> are rendered useless. 
> 
> As for being "elite", well, I have a hard time considering people
elite
> when they negatively impact the human race. They are quite literally,
> not superior. So, as an argument of opinion,f I'll have to go ahead
and
> disagree there... Ok... (office space speak)
> 
> 
> 
> On Tue, 2003-01-28 at 14:22, Nicolas Villatte wrote:
> > I am sorry but people who made this virus does not appear as script
> > kiddies to me. Do you prefer to be aware of the exploit like the
ones
> > that will use it after some modifications or do you prefer only some
> > "elite" is able to harm the systems?
> > 
> > Personally, I prefer to die seeing my enemy than being stabbed.
> > 
> > 
> > -----Message d'origine-----
> > De : full-disclosure-admin@...ts.netsys.com
> > [mailto:full-disclosure-admin@...ts.netsys.com] De la part de
> Strategic
> > Reconnaissance Team
> > Envoy? : lundi 27 janvier 2003 3:19
> > ? : full-disclosure@...ts.netsys.com
> > Objet : [Full-Disclosure] [Secure Network Operations, Inc.] Full
> > Disclosure != Exploit Release
> > 
> > All, 
> > 
> > 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.
> > 
> > It is possible to prove a vulnerability exists by releasing well
> written
> > advisories.  Because of this fact, proof of concept code (exploit
> > source) is not a requirement for the education of the possibly
> > vulnerable. Releasing non-malicious exploit code is also not an
option
> > as any local script bunny/kiddie can easily render it functional.
> > 
> > Proof of concept code is useful for legitimate contract based
> > penetration tests. 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.
> > 
> > I am interested in hearing the opinions of the people on this list.
If
> > you are for exploit source disclosure, I would like to hear
arguments
> > supported by facts, that explain why.  I am equally interested in
> > reasons why not to disclose information. 
> > 
> > With that said, Secure Network Operations, Inc. will no longer be
> > releasing functional proof of concept code. We may release
> sufficiently
> > detailed advisories. 
> > 
> > 	
-- 
Strategic Reconnaissance Team <recon@...soft.com>
Secure Network Operations, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3374 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030129/9b321615/smime.bin

Powered by blists - more mailing lists