lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
From: hellnbak at nmrc.org (hellNbak)
Subject: [Secure Network Operations, Inc.]
 FullDisclosure != Exploit Release

On 28 Jan 2003, Strategic Reconnaissance Team wrote:

> Date: 28 Jan 2003 20:02:59 -0500
> From: Strategic Reconnaissance Team <recon@...soft.com>
> To: Nicolas Villatte <Nicolas.Villatte@...alvas.be>
> Cc: full-disclosure@...ts.netsys.com
> Subject: 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?

I agree with this argument -- mostly.  If I read this correct, you are
still going to release full vuln details in the advisory.  This keeps the
code away from those who do not have the ability to take the advisory and
turn it into their own exploit.

The common argument that is made (and that I agree with) is that IT guys,
don't have the time and don't always have the skill to come up with their
own exploit code.  Combine this with the fact that they don't have the
budget to buy a commercial scanner and there is no way their boss will
allow something scary like Nessus on their network (these organizations
exist).  So how can an IT guy test a patch?  How can he be sure that the
vendor has done their jobs?

Now if you agree with my first few sentences and do release complete
details yes, you have achieved the objective  of protecting the world from
script kiddies and clueless consultants <---- this is a great thing.  But,
as you said the complete vulnerability information is enough information
to make your own exploit so you have not eliminated the true blackhats or
anyone (white, purple, grey, whateverhat) that can create their own
exploit based on the info.

So, the defenseless are still defenseless and the malicious are still
armed.  So is the answer not dislcosing details?  I would say no as the
simple statement "there is an overflow in xyz.dll" is enough to make those
with the abilities look at xyz.dll and find it.  So how about no
disclosure?  Great, now we are all only as good as our own and our friends
research.  Meaning more of us are at risk.

So I say release the code, try and make it as crippled as possible
(localhost only or whatever) so at least you know that *your* code won't
be directly used for malicious intent.  Yeah exploits and malicious
code/worms/virus'/whatever will still exist and be abused but regardless
of what you and anyone else for that matter do it always will.

At least with releasing code you can take comfort in knowing that you are
helping those who cannot help themselves.  That is of course if you
believe in helping others and don't just release advisories for the
media-whoring marketing purposes (hello to my friends at ISS ;p).


-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

"I don't intend to offend, I offend with my intent"

hellNbak@...c.org
http://www.nmrc.org/~hellnbak

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ