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]
Message-ID: <20050702002052.678FD256@lists.grok.org.uk>
Date: Sat Jul  2 14:56:35 2005
From: harry at slaptop.com (Harry Metcalfe)
Subject: RE: Publishing exploit code - what is it good for

I agree that in some cases, release of exploit code is unnecessary - but in
other cases, it is completely essential. In an open source product - as was
recently the case with the osCommerce HTTP splitting vulnerability - it is
necessary for programmers to fix vulnerabilities, in cases where the
organisation that produces the software does not release a patch or updated
version in time. 

Also, open source products - especially web applications - are often
modified by their users. I am responsible for maintaining several osCommerce
carts that have been heavily modified to suit the needs of the companies
that use them. Even if a patch or new version were released for a security
problem, it would be of little help for me: to install it would require
remodifying each cart. This would be a horrendous waste of time; it is far
quicker simply to fix the vulnerability in each installed instance, and in
cases like that, proof of concept code is essential: without it, one cannot
reliably test fixes applied to the product.

Finally, proof of concept code has value - in all cases - as a means of
proving the existence of a vulnerability. It is the most efficient way to
provide other researchers with the proof that a vulnerability is real, with
the means to reproduce the problem, and with the ability to check the
original researcher's approach for flaws or related vulnerabilities that may
not have been discovered the first time round.

Release of proof of concept code is obviously dangerous, but not *very*
dangerous: it's a trade-off between the verifying the quality of research
and the ability to fix problems, and the safety of the wider community. I
assert that, as is often the case with this type of problem, the benefits
outweigh the risks: blackhat communities will likely distribute their own
exploit code anyway, and determined attackers will not be put off by the
lack of proof of concept code. In other words, the lack of proof of concept
*can* harm the community, and is unlikely to make much difference to
evildoers.

Harry Metcalfe


-----Original Message-----
From: Aviram Jenik [mailto:aviram@...ondsecurity.com] 
Sent: 30 June 2005 13:14
To: full-disclosure@...ts.grok.org.uk; bugtraq@...urityfocus.com
Subject: Publishing exploit code - what is it good for

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.

-- 
Aviram Jenik
Beyond Security

http://www.BeyondSecurity.com
http://www.SecuriTeam.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ