full-disclosure - Re: Publishing exploit code

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: <417FBD79471FC74E98397AF3640E6AC5153E70@phyexha.physics.uiuc.edu>
Date: Thu Jun 30 21:14:51 2005
From: menscher at uiuc.edu (Damian Menscher)
Subject: Re: Publishing exploit code - what is it good for

On Thu, 30 Jun 2005, Aviram Jenik wrote:

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

I'll skip over the obvious stuff (exploits are distributed anyway, 
knowing when exploits exist is helpful for prioritizing patches, etc) 
and jump to your specific question: how this helps me and my 
organization as end-users.

When a vendor issues an advisory, it tells us that their software should 
be upgraded, and often gives mitigating factors.  But upgrading software 
all the time is risky: you never know when a patch will break something. 
So it's often helpful to wait a day before upgrading, if you know that 
there is no known exploit.  FD lists therefore help us prioritize 
updates.

Also, many times there are enough mitigating factors that it may be 
difficult to determine whether (in the case of an exploit being 
published before we've had a chance to patch) there was any period of 
vulnerability.  For example, with stack randomization enabled, the 
exploit might fail.  It would be reassuring to confirm that.

Finally, many vendors (RedHat being a notable one) backport security 
patches, rather than upgrading to the latest version (which may 
introduce new bugs^Wfeatures).  A side effect is that it's often 
difficult to determine whether your machines are vulnerable to any given 
exploit.  Yes, we could probably glean the information from changelogs 
and security advisories from the vendor, but that's often a confusing 
process (the inclusion of CAN/CVE numbers helps).

And, of course, if you're the security guy (I've worn this hat too), all 
you can see is that they're running (for the case of OpenSSH) 
OpenSSH_3.6.1p2, which might be vulnerable.  You don't know that the fix 
was backported into openssh-3.6.1p2-33.30.4.  So you need to test.  In 
fact, I suspect this is why your friend doesn't want the exploits to be 
released.  If organizations could test their own security (which 
*requires* having the exploits, as I just explained), it would cut into 
his company's market-share.

Damian Menscher
-- 
-=#| Physics Grad Student & SysAdmin @ U Illinois Urbana-Champaign |#=-
-=#| 488 LLP, 1110 W. Green St, Urbana, IL 61801 Ofc:(217)333-0038 |#=-
-=#| 4602 Beckman, VMIL/MS, Imaging Technology Group:(217)244-3074 |#=-
-=#| <menscher@...c.edu> www.uiuc.edu/~menscher/ Fax:(217)333-9819 |#=-
-=#| The above opinions are not necessarily those of my employers. |#=-