Bashing response teams

[spaf () cs purdue edu (Gene Spafford)]

Folks,

Try to keep clear that there is a difference between some of the
response teams and the vendors.

If you quietly report a bug to CERT or CIAC or AUSCERT, they do not
fix it themselves.  Instead, they pass it on to the vendors.  Then,
depending on the team, they may wait for the vendor to act.

For instance, if you quietly report a bug to CERT, and CERT passes
that bug on to a vendor, and the vendor does *nothing*, there is
little the folks at CERT can do other than keep pestering the vendor.
Furthermore, if there is no evidence that the bug is being actively
exploited, there is no extreme urgency to push the vendor harder (if
they could).

When you post a bug to a public list, espcially with an exploit, it
now takes on a different form.  Instead of a problem that could be
quietly fixed for the next release without endangering anyone,
suddenly the whole population on the Internet using that software is
endangered.   Now it is more a priority to get something out...and
that may not include a real fix, but simply a workaround.  If the
policy of the team is to only publish vendor-approved fixes, the
notice from the response team may be weeks away from the notice you
get in a list like bugtraq.  (Of course, if no one had ever seen the
bug before the fix was posted, it wouldn't matter so much.)

Some of the response teams have a policy not to make releases of
information until they have approved vendor fixes in hand.  That is
for a number of reasons, with liability being one of them.  You may
scoff at this, but that is the rules they are forced to play under.
Others believe that vendors will be more responsive if they (the
response teams) wait for the vendors to participate.

So, if you are unhappy with the response, you might try to identify
who is really at fault.  If the response team you contacted is waiting
on a vendor, it is the vendor's fault.  If you report it to a vendor,
but end up reporting it to the wrong branch at the vendor, the wrong
people may be evaluating the problem and not fixing it.  And some
vendors are still horrible at responding to security problems.

Are the response teams blameless in their behavior?  No.  But I know
from experience and contact with these folks that they are frustrated
at the pace of vendor response in many cases, too.

As to the credit bit, that is up to the teams.  The teams tend to
publish *fixes*.  What gets posted here and elsewhere tend to be
exploits and the teams aren't going to acknowledge people who post
exploits!  Furthermore, if a problem is posted which no one else has
found and there is zero evidence it is being misused yet, you have
made their lives (and ours) more difficult -- they are hardly going to
thank you or acknowledge you for that, either.

Think about it -- do you tend to thank the person who helped you
change your flat tire, or do you thank the people who scattered the
broken glass in your driveway?

> From past experience, where a flaw is found and reported quietly, and
the vendors can be prodded into appropriate action, the teams
acknowledge the people who helped identify the problem and fix.  Don't
bet on getting any mention, though, if you only point out a
vulnerability and/or an exploit.  That's simply the way those teams
work.

This is *NOT* an attempt to discuss the merits of how much information
to disclose.  However, I think people don't understand the issues
involved with the TIMING of disclosure, and the audience.  I simply
want to point out that many of you may be pointing fingers at the
wrong parties and for the wrong reasons.


--spaf