Re: Towards a responsible vulnerability process

From: Ernst Lopes Cardozo (e.lopes.cardozo@ARANEA.NL)
Date: 11/04/01 

Message-ID:  <000901c16582$4adaed60$0600a8c0@acnllelo>
Date:         Sun, 4 Nov 2001 23:44:40 +0100
From: Ernst Lopes Cardozo <e.lopes.cardozo@ARANEA.NL>
Subject:      Re: Towards a responsible vulnerability process
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

A proposal for an "Automatic Software Recall" service.

Between the necessity (or not) of providing full disclosure to make sure
vendors fix and hopefully prevent vulnerabilities, and the damage that (with
or without) such disclosure is caused to large numbers of systems and their
users, lies that actual fact that not all users apply all security patches
in a timely manner. This blatant understatement is there to avoid discussion
on just how many sysadmins manage to do what is necessary to secure their
systems AND avoid their systems spreading malware. Suffice to say that there
are far too many and that this is unlikely to change in the foreseeable
future.

What would help is a universal method that makes it easy and inexpensive to
inform software users about flaws that they should know about. My proposal
is:

To have an open method (RFC based) that every software vendor may use at his
own discretion.
The vendors software product(s) would, after initial installation, after
updates and otherwise periodically, query a public service that holds
machine-readable (security) advisories for such software products.
The advisories enable the software to decide to 1) run as usual or 2) refuse
to run with an error message to the user and/or log as appropriate that
contains a pointer to the website of the vendor or 3) run with reduced
functionality, e.g. no updates, no web access, etc., as appropriate for the
product.

The advisories do NOT contain fixes, this is not code pushing.

Advisories will be digitally signed by the vendor and authenticated by the
product to prevent false advisories.
Requests to the public server will be phrased such that the identity of the
requesting software can not be determined, even by the server: hence the
server will send the advisories for a larger number of products including
the requesting product.
If the software does not receive a valid reply form the server, it will be
programmed to chose one of the options above, or request the user to confirm
that it is running without web access. The RFC should provide guidance to
software vendors what option to take depending on the possible impact on the
user's business and network security if a necessary advisory is not
received by accident or hacker's action.

I believe this tool would have been of tremendous help e.g. in the case of
code red (I, II and those yet to come). It would have stopped the spreading
of code red within a single 'advisory check cycle'. For a web server, this
could easily be between a day and a week. More importantly, it would have
insured that no new vulnerable systems would come online, as is now the case
for at least a couple of years. Even without new variants, there will be a
constant code red 'background glow' kept alive by unpatched new systems (it
is not uncommon for users to install a vulnerable system on-line, such that
it is infected even before the first service pack is applied - calling them
stupid won't stop the proliferation).

The user community could set up such a service - but would software vendors
use it? Lets see.
Positives:
- Vendor can put "Safety first, includes automated software recall, RFC9999"
on the box.
- Vendor can plead that it did the responsible thing to prevent user and
community damage.
- Vendor can use mechanism to communicate (one-way!) to anybody using his
product. Could be a way to inform about upgrade options. (This is an
interesting option, but we want to make sure the vendors know we don't want
'commercial breaks' in our computer programs)

Negatives:
- Vendors may argue that this will potentially alarm users that don't need
to be alarmed since the vulnerability does not apply in their case , e.g.
because they are behind a firewall. May be mitigated if the mechanism can be
made to discern different types of deployment and the relevance of
advisories duly coded.
- Vendors may argue that they don't want tot sell a product that stops
working when least expected. Indeed, one would be rather infuriated if your
word processor quits when you are about to print that important document for
they courier to deliver. The answer of course is that this will only happen
if the vendor decides that a very serious problem exists and issues such a
drop-dead advisory. For everything less urgent, more appropriate reactions
(warnings, grace periods, etc.) can be designed into the software product.
- Vendors may be concerned that the service exposes the number of advisories
for their products and thus put them in a bad light. I believe the advisory
authentication mechanism can be made to completely conceal the vendor ID.
- Vendors may argue that this is unnecessary since they have their own
notification and patch distribution system. One answer could be that we the
users want to restrict internet access for software products to one port on
one server, rather then something different for each vendor and yes, we do
use other vendors software.
- Vendors may argue that is won't work: that there are to many versions and
patch levels (make that patch paths). The RFC9999 will provide guidance how
to implement the client part.

I believe this is the first time that such an idea is floated. If it was
sunk before by good arguments, let it rest. Otherwise, I'm sure improvements
and refinements will be forthcoming. I hope a few knowledgeable souls will
rise to the challenge to write that RFC. My resources are few, but I'm ready
if you are.

Of course, this will not solve the "full disclosure" dilemma, but it is
relevant to the extend that it may reduce the number of people hit when
knowledge of a vulnerability gets it the wrong hands.

Brief change of scene: automobiles used to be a lot more dangerous then they
are today. Computers are, it seems, still in their pre-Ralf-Nader days. Some
day in the future, disclaimers will not protect a software writer (whether
vendor or source of free software) from claims if bad workmanship (such as
not checking for buffer overflows in a web server) result in non-trivial
damage to customers and the public at large.

Ernst Lopes Cardozo
Principal Consultant
Aranea Consult BV

Reitscheweg 5b
5232 BX 's-Hertogenbosch
Tel: +31-(0)73-646 1660
Fax: +31-(0)73-646 1661
E-mail: e.lopes.cardozo@aranea.nl

Relevant Pages