Re: Open Source vs. Closed Source [ was Re: [fw-wiz] FirewallThroughput ]

[Chris Calabrese <christopher_calabrese () merck com>]

I think this is a very touchy subject, and the proper way of doing things
depends greatly from one situation to the next.

In the best of all possible worlds, you inform the vendor, they work with you to

come up with a fix, they distribute the fix widely, and life is good.

In the real world, experiences vary greatly by the vendor's actual commitment to

security and their sliminess factor.  In the best cases, things go something
like the above.  In most cases they require gentle prodding of the vendor at
each step of the way.  In the worst cases, the vendor starts out by claiming
that their product isn't the problem and that you've obviously done nothing
wrong.  You then have to convince them by setting up a demonstration for them
that is very similar to the type you might use for the press.  Next, they tell
you they've place it on their development list and that they will eventually
address it.  After a few months, you bug them some more and they tell you
they're working on it.  After that, the logical thing is to go to CERT, but they

usually won't release an advisory unless the vendor has a patch, so they're no
help either with an extremely slimy vendor.  After that, your only recourse is
to threaten to widely publicize the vulnerability and how the vendor tried to
ignore the problem.  Eventually, you may have to make good on your threat (at
which point, you're usually so angry that you want the vendor to receive the
worst possible press anyway).

Now, that doesn't mean you have to release exploit code or that you shouldn't
give the vendor a reasonable amount of time to react to each new development.

Doug Hughes wrote:

> On Fri, 15 Sep 2000, amanda wrote:
>
> > You could always make an anonymous post to bugtraq and attach some exploit
> > code for the script kiddies. That should get the vendors attention. Or at
> > least it will make some other customers complain loudly to the vendor.
>
> No no no! Please don't do this. This brings a knee jerk reaction and often
> doesn't give time for proper regression testing of fixes. In the mean
> time, the script kiddies can go blasting around to their hearts content.
> Better to post a patch for the problem (if possible). That serves two
> purposes: make the problem known, and fix it at the same time.
>
> > Just look at how Microsoft reacted to last summers IIS exploit from eEye.
> > For several days they completely ignored it until it turned up on bugtraq.
> > Then they fixed it in a few hours.
> Doesn't mean that that's the right way to do it. It means that the vendor
> has to take all of their resources that may be working on other important
> security issues and preempt them for a quick and dirty fix.
>
>                         doug () eng auburn edu

Attachment: christopher_calabrese.vcf
Description: Card for Chris Calabrese