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>] [day] [month] [year] [list]
Date: Thu Jun 30 14:01:01 2005
From: Glenn.Everhart at chase.com (Glenn.Everhart@...se.com)
Subject: Publishing exploit code - what is it good for

This argument has gone on for decades at least; you hear very similar things
from the feds about homeland security as well, to pick one of the more prominent
other sources.

We are engaged, when trying to defend systems, in a design contest with attackers,
trying to keep our fortresses from being breached.

While it is temporarily embarrassing and more dangerous that someone publishes
the exact defect that allows the enemy's artillery to penetrate our armor,
I must point out that when trying to design better armor, that design is driven
by knowing precisely what characteristics attacks have. This information is most
honest, when discussing code, when working code can be examined.

If you stop your analysis at the point when you consider the greater ease of more
attackers to duplicate successful attacks, it may appear revealing the attacks
is a problem. (This is even easier if the fact that those attackers have been
much better at sharing such information clandestinely than most defenders have been
with defensive information.)

If you continue to the (necessary) creation of new defenses, though, it is clear that
the defenses cannot be designed without knowing the attacks, and starting from real
attacks and having the designer do his own abstraction is arguably a less error
prone process than having some other "experts" try to produce a summary of a method,
which may leave out precisely the details needed to show the correct broader pattern.

The above is itself pretty abstract, just like the questions asked. It might
be fair to ask the person who advocates keeping attacks secret, though, how many
new defenses he / she has designed. Maybe the world will get some new designers...

Glenn Everhart


-----Original Message-----
From: full-disclosure-bounces@...ts.grok.org.uk
[mailto:full-disclosure-bounces@...ts.grok.org.uk]On Behalf Of
bruen@...drain.net
Sent: Thursday, June 30, 2005 8:39 AM
To: Aviram Jenik
Cc: full-disclosure@...ts.grok.org.uk; bugtraq@...urityfocus.com
Subject: Re: [Full-disclosure] Publishing exploit code - what is it good
for



Hi Aviram,

  There are two main problems with your analyst friend's position. The 
first is that he has no business deciding for me or anyone else as to 
whether or not my needs are legitimate. I get to decide if I need/want 
something (like exploit code) or not, his arrogance notwithstanding.

 The second point is that he, like most software vendors, have to yet to
figure out that their products are consumer products and should be treated
just like automobiles and toys. Consumer product testing is very public.
Software is the same. We all want to know *exactly* how the product fails,
just like any other consumer product, no exceptions.

 It is no longer about "full disclosure", it's about being just like 
everyone else. There is no difference between how my software gets 
exploited and how my child safety seat fails.

                 cheers, bob  



On Thu, 30 Jun 2005, Aviram Jenik wrote:

> Hi,
> 
> I recently had a discussion about the concept of full disclosure with one of 
> the top security analysts in a well-known analyst firm. Their claim was that 
> companies that release exploit code (like us, but this is also relevant for 
> bugtraq, full disclosure, and several security research firms) put users at 
> risks while those at risk gain nothing from the release of the exploit.
> 
> I tried the regular 'full disclosure advocacy' bit, but the analyst remained 
> reluctant. Their claim was that based on their own work experience, a 
> security administrator does not have a need for the exploit code itself, and 
> the vendor information is enough. The analyst was willing to reconsider their 
> position if an end-user came forward and talked to them about their own > benefit of public exploit codes. Quote: " If I speak to an end-user 
> organization and they express legitimate needs for exploit code, then I'll 
> change my opinion."
> 
> Help me out here. Full disclosure is important for me, as I'm sure it is for 
> most of the people on these two lists. If you're an end-user organization and 
> are willing to talk to this analyst and explain your view (pro-FD, I hope), 
> drop me a note and I'll put you in direct contact.
> 
> Please note: I don't need any arguments pro or against full disclosure; all 
> this has been discussed in the past. I also don't need you to tell me about 
> someone else or some other project (e.g. nessus, snort) that utilizes these 
> exploits. Tried that. Didn't work.
> 
> What I need is a security administrator, CSO, IT manager or sys admin that can 
> explain why they find public exploits are good for THEIR organizations. Maybe 
> we can start changing public opinion with regards to full disclosure, and > hopefully start with this opinion leader.
> 
> TIA.
> 
> 

-- 
Dr. Robert Bruen
Cold Rain Technologies 
http://coldrain.net
+1.802.579.6288

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


**********************************************************************
This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you
**********************************************************************

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ