full-disclosure - 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]

Date: Thu Jun 30 20:21:26 2005
From: jjjwicks at gmail.com (James Wicks)
Subject: Publishing exploit code - what is it good for

The release of exploit code is good for my organization for two
reasons:  It keeps my IT administrators and software vendors on their
toes.

I know a lot of IT administrators who sit on patches and remediation
techniques because there is only proof-of-concept information
available.  When there is exploit code on the web, these lazy IT
administrators are forced to get off their rears and do their jobs.
If my business is attacked by some hacker/cracker using a published
exploit that has been patched, my IT administrative team needs to be
"adjusted".  Most of the executive staff knows little or nothing about
what we do.  They assume (and trust) that their business is as secure
as possible (based on they funds supplied to do the job ? but I
digress).  Even if lazy administrators are forced to work defensively
because exploit code is released, it strengthens the business's IT
security profile.  That is always a good thing.

As far as software vendors go, if their products have an issue, it
should be addressed.  If they cannot (or will not) address it, then I
get a new vendor.  I cannot have business-critical applications
operating unpatched because the vendor does not want to address it.
My business assets are vulnerable, and that is not acceptable.  If
Symantec personnel have to stay up 48 hours in a row to fix a flaw
that can be exploited, I am ok with that.  That is what we pay them
thousands of dollars a year to do.  As long as the software company is
given the opportunity to address the exploit before the release of the
exploit code, there is really no real issue.

Aviram's analyst does not want to concede that there are bad/lazy IT
administrators and software developers who are comfortable pulling a
paycheck while doing as little as possible to earn it.  If a company
develops a solid system of testing, enhancing and maintaining their
infrastructure to minimize the impact of released of exploit code, it
is a good thing for the business.

On 6/30/05, devnull@...ents.montreal.qc.ca
<devnull@...ents.montreal.qc.ca> wrote:
> [Because of all the broken autoresponders on bugtraq, the header From:
> is a bitbucket.  Use the address in the signature to reach me.]
> 
> >> Quote: " If I speak to an end-user organization and they express
> >> legitimate needs for exploit code, then I'll change my opinion."
> 
> Well, I'm not an end-user organization, but as an end user[%], the
> major benefit I see to full disclosure is that it appears to be close
> to the only thing that has any real success at getting vendors to fix
> bugs.  (In general.  There certainly are vendors that stay on top of
> things without needing the prod of public exploit disclosure.  But they
> are notable by their rarity.)
> 
> [%] "End user" is not the only hat I wear.  It's just the one I'm
>    wearing here.
> 
> /~\ The ASCII                           der Mouse
> \ / Ribbon Campaign
>  X  Against HTML               mouse@...ents.montreal.qc.ca
> / \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>