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.




Network Security NTBugtraq
[Top] [All Lists]

Re: [Full-Disclosure] RE: Disclosure policy in Re: RealPlayer vulnerabil

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>