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]

Message-ID: <462F60C6.3060604@csuohio.edu>
Date: Wed, 25 Apr 2007 10:08:06 -0400
From: Michael Holstein <michael.holstein@...ohio.edu>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: requesting info

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