The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: 'Phage List' - Archives (1988 - 1989)
DOCUMENT: phage #101 [Getting Vendors To Fix Bugs] (1 message, 1597 bytes)
SOURCE: http://securitydigest.org/exec/display?f=phage/archive/101.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

From: bukys@cs.rochester.edu
To: phage
Date: Mon 10:57:33 07/11/1988 EST
Subject: Getting Vendors To Fix Bugs
References: [Thread Prev: 105] [Thread Next: 135] [Message Prev: 199] [Message Next: 102]


The never-ending debate in computer security circles is whether to
publicize bugs, or to hide them, hoping the vendor will fix them, someday.

Whatever ones opinions are in this matter, it is clear that the widespread
public embarrassment caused by the worm escapade will lead to a quick response
from the vendors.  Failure to act doesn't look very good when "the network
is the computer".

In light of the power of public embarrassment, here is a modest proposal.
It does NOT address the problem of a malevolent cracker discovering a hole
and instantly exploiting it.  It does address the problem of any vendor's
reluctance to fix bugs or publicize them within a reasonable time.

(1)  Set up an Internet Security Accountability (ISA) organization.  Vendors
subscribe to its services for some reasonable amount.  Failure to subscribe
brands a vendor as one which does not care about security lapses.

(2)  Vendor subscription requires that vendor supply access (to ISA) to
complete source code to every release of software, and in a timely manner.

(3)  ISA employs a crack team of crackers to find security holes in the
systems.  When a hole is found, the bug is reported back to the vendor.
Vendor has two weeks in privacy to produce official patches, which are to
be made immediately available to ISA and the user community.  (Patches
should have no restriction on copying.)  A vendor response of "upgrade
to release X.Y" is not adequate when the previous release is not all that
old.

(4)  Whether or not the vendor produces the patches, when the two weeks is
up, ISA announces the existence of the bug, its ramifications, and the vendor's
patches, if any.  If there aren't any patches yet, the vendor's phone rings
off the hook, and various customers get steamed and cancel orders, etc.

(5)  At the end of that hot two weeks, ISA announces any workarounds that it
has devised, or pronounces the system and vendor hopeless for now.  One hopes
that the stigma attached to the latter is painful enough that vendors will
avoid it.

ISA could publish a newsletter, containing the current inventory of known bugs
and official patches.  Available by anonymous ftp, of course.

Maybe this is all too grandiose.  On the other hand, I think that there are
plenty of responsible people out there who would love to submit bugs reports,
if only there were someplace they could send them where they would have some
effect.  So the crack staff wouldn't have to be very large, since the community
would be providing a lot of "free" expertise.  As to whether vendors could be
made to go for it:  there are lots of things that vendors don't like that they
submit themselves to because the market requires it.  Certification of X.25
protocol implementations, for instance.

Now, will the market require it?

Liudvikas Bukys
<bukys@cs.rochester.edu>

END OF DOCUMENT