Reports on unverified vulnerabilites

[Shaun Clowes <shaun () SECUREREALITY COM AU>]

Following my post to this list regarding my dislike for vague
vulnerabilty reports that don't actually conclusively indicate if there even
is a problem, I've received a fair bit of mail on the issue and wanted to
share some of the opinions.

Let me firstly point out a home truth, the vast majority of administrators
and programmers aren't in the slightest worried about security. Sad perhaps,
but true none the less. They have day to day jobs, security is at most a
side concern compared with keeping the mail server running or finishing the
app that is due for release next week.

Almost everyone who wrote to me disagreed with my stance that unverified
security reports leave the security community in danger of isolating itself
by adding to administrators workload for no reason. I said that if enough
times this occured, administrators will simply ignore the issues. Most of
those who disagreed with me were along the lines of, its good to know so
that you can:
    1. Check if you're vulnerable
    2. Restrict access to the service
    3. Wait for further results

(1) is often hard with some of the truly vague advisories posted to the
major lists. (2) is often impossible if its a hole reported in a service you
NEED to provide to everyone, including the internet (forgetting over 75% of
all attacks are internal). (3) defeats the purpose of the information in the
first place.

 Any overworked administrator would resent having to spend even 20mins /
server doing this to later find it wasn't necessary. The whole value of the
full disclosure methodology goes down the drain if its reports are ignored.

Several people commented that some people don't have the technical skills to
determine if a problem is exploitable. As I said in my post, they can
contact someone who does in that case, VULN-DEV is an abvious place, my
company and presumably almost every other security team would be willing to
help too.

It was commented that if my company for example were asked to check
vulnerability, we might declare it unexploitable when it is, if thats a
concern, approach several people to determine vulnerability.

One person commented that a bug was a bug and should be fixed, exploitable
or not. Easy to say, harder to do when you're dealing with a service that
needs 24x7 uptime.

Just to clarify my post further, some people commented they'd rather upgrade
before an exploit existed. We're not talking public exploits here, proof of
concept ones that will never be posted anywhere.

Finally one person posted "Why not release the exploits?". I don't believe
in that because unfortunately, the kids are faster than the administrators,
often a lot faster. The kids can take a long time to generate a working
exploit for something, hopefully it gives the admins some time to upgrade.
This person also commented that us saying in a security advisory a problem
was exploitable without proof/enclosed exploit doesn't mean much, we could
be lying. That is an excellent statement, with the sensationalism going on
in the security industry, who do you trust?

Cheers,
Shaun