full-disclosure - Re: requesting info

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: Wed, 25 Apr 2007 20:35:54 -0600
From: "Jason Miller" <jammer128@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: requesting info

or you can have some fun and post everything about it, and email the
vendor 5 seconds before you post it....but thats not very nice..is it?
:(

On 4/25/07, Michael Holstein <michael.holstein@...ohio.edu> wrote:
> > i'm just a new guy to this community...i was asking about the right
> > procedures that one should do when he/she discovers a vulnerability in and
> > application or operating system
>
> Generally, the most accepted procedure is to :
>
> 1) notify the vendor, including the specific conditions (and/or code)
> required to invoke the exploit. Give then at least 30-60 days to chew on
> it and come up with a fix.
>
> 2) notify the community, but withhold specific details needed for your
> average point-and-click scriptkiddie to create an exploit (eg: name the
> program, function, etc. but don't provide specifics).
>
> 3) wait .. how long you wait is a subject of debate .. but most folks
> either give the vendor a fixed amount of time, either from the original
> notice (good), or from the time the vendor releases a patch (better).
>
> 4) release the vulnerability details publicly, including source code.
> The value of releasing the specifics is debatable, but it certainly
> helps community-supported projects like Nessus, and those of us that
> can't cough up the tens-of-thousands for a "commercial" vuln-scan product.
>
>
> > also what is the right procedure to make in order to publish a new hacking
> > technique to that it's know by the name of the publisher
>
> Generally (and with the exception of Microsoft), most vendors will give
> you credit for a discovery. Most folks publish with a LGPL-ish license
> that both requires attribution and restricts closed-source commercial use.
>
> If you publish to FD, and sign with your PGP key, it'll be hard for a
> vendor to claim later that they came up with it on their own.
>
> ..
>
> The main thing is to recognize that many in the community are smart
> enough to figure out where the problem is based on minimal details
> (function, type of exploit, etc) without having the exact details (for
> example, we can set a killbit on an ActiveX object without needing to
> know exactly what's wrong with it).
>
> You want to help the software (or hardware) manufacturer fix the problem
> before you "tell the world" exactly what's wrong, because you want to at
> least make the bar high enough that script-kiddies can't just
> incorporate your code into their latest "bot".
>
> If the manufacturer ignores your legitimate attempts to inform them
> about a problem, or stalls perpetually, then it's an accepted practice
> to go ahead and embarrass them by releasing the exploit after a
> reasonable length of time.
>
> It's this "embarrassment" that keeps folks honest.
>
> My $a { ($a = 1 * .02); }
>
> Cheers,
>
> Michael Holstein CISSP GCIA
> Cleveland State University
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

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