Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: [Full-Disclosure] RE: Disclosure policy in Re: RealPlayer vulnerabilities |
|---|---|
| Date: | Fri, 8 Oct 2004 10:43:02 -0700 |
Drew, First, you wrote that I do not really believe in "full disclosure" even though I clearly stated I am for it. I find it a little bit difficult to argue on that level of reasoning, but please allow me to clarify what I tried to propose anyway: I truly believe that vulnerability disclosure should follow these steps: 1. Vulnerability is discovered and the vendor is notified. 2. In time X, vulnerability existence is publicly announced without giving specific details. Users are urged to apply the patch. 3. In time Y, vulnerabilityâs technical details are disclosed. While this approach might not provide benefits in all cases, it certainly should not hurt either. We can of course argue what are the appropriate times X and Y but that would be for another discussion and I would be happy if we got there. So what are those benefits? I disagree with you that the value of vulnerabilityâs technical details is worthless to the attacker and that he can figure out the vulnerability as easily as if he had that information. An application may consist of many binary files that may be modified in hundreds of places. The vulnerability might be a buffer overflow or some generic error in applicationâs logic or just bad default configuration. Yes, eventually you will be able to crack it but it is going to take time, determination and resources. But with technical details, you are pointing out - here it is, in this file, under precisely these conditions. Without the technical details, depending on the motives, skills, determination and resources of the attacker, one of the following will happen: 1. It is really easy to figure out where the vulnerability is or the attacker very skillful. He writes the malicious code and releases it. Sad day for everybody. 2. It is not that easy to figure it out but the attacker is determined and eventually he succeeds. However, any time we bought by not helping him pays off. Every hour we won can mean thousands of system patched in time. Not so sad day for hopefully a lot of people. 3. By not publishing details, we discouraged 200 script kiddies around the world because it would be too much hard work and so much less fun. Another 100 gave up after getting bored trying. No so bad day at all. As can you see, I am not talking about the absolute security. But I say if there is anything reasonable that we can do to prevent unnecessary security incidents, we should try to do it. Second, you say that vendors must work much harder at reducing patch development time and I cannot agree with you more, especially after what I stated above. Third, anybody who is releasing information that may lead to unnecessary security incidents is not doing a good thing. And that equally applies to ISSâs release of Apacheâs chunk encoding vulnerability. Martin Viktora -- NTBugtraq Editor's Note: Want to reply to the person who sent this message? This list is configured such that just hitting reply is going to result in the message coming to the list, not to the individual who sent the message. This was done to help reduce the number of Out of Office messages posters received. So if you want to send a reply just to the poster, you'll have to copy their email address out of the message and place it in your TO: field. --
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [Full-Disclosure] RE: Disclosure policy in Re: RealPlayer vulnerabilities, Tim Johnson |
|---|---|
| Next by Date: | Re: CWS = Crummy Windows Security, Ron Parker |
| Previous by Thread: | Re: [Full-Disclosure] RE: Disclosure policy in Re: RealPlayer vulnerabilities, Tim Johnson |
| Next by Thread: | Re: [Full-Disclosure] RE: Disclosure policy in Re: RealPlayer vulnerabilities, Matthew S. Cramer |
| Indexes: | [Date] [Thread] [Top] [All Lists] |