Date: Sat, 15 Jul 2000 11:52:56 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Bengt Richter <bokr@accessone.com> Cc: freebsd-security@FreeBSD.ORG Subject: Re: RFC for Advisories? (Was Re: Newer/Two kinds of advisories?) Message-ID: <Pine.NEB.3.96L.1000715114100.15043D-100000@fledge.watson.org> In-Reply-To: <3.0.5.32.20000714142038.00908650@mail.accessone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 14 Jul 2000, Bengt Richter wrote:
> "NOTICE: vulnscand has received and authenticated advisory <advisory ID>,
> and has (per vulnscand.conf auto option) disabled execution of
> /<path to executable>
> due to a level 7.2 ('Immediate Action Urgent') vulnerability.
> Type vulnscan -i <advisory ID> for full info."
I've thought through this idea a few times, and it has come up every now
and then on various lists. So here's my spin on some of the ideas in your
e-mail.
Machine-readable advisories are generally accepted as a good idea,
allowing them to be conveniently pulled into databases and managed. If
you want to propose such a cross-platform format, I'm sure there would be
wide-spread interest. In particular, you may want to attempt to measure
the machine-readableness of the existing advisory formats from various
vendors and determine if they are adequate, and if not, in what ways not.
You might succeed in pursuading the industry as a whole to adopt the
format, and you would probably garner support from a number of groups.
That said, the idea of automated response is a worrying one. Generally
speaking, I would feel uncomfortable having no human sitting between the
FreeBSD-generated advisory and the implementation of the work-aroud.
There are concerns about potential abuse, denial of service, as well as
timing issues, and management issues. A distributed management mechanism
that could read in an approved advisory and apply that change across a
cluster of FreeBSD boxes would be useful, but if the bug is in the
kerberos libraries, I certainly wouldn't want an automated disabling of
all remote login mechanisms across a cluster of 400 headless boxes :-).
Any form of automated upgrade has its dangers -- there have been times
where I have purposefully not tracked the front edge of -STABLE or
-CURRENT to avoid feature changes that would damage the service-providing
capabilities of a box. I certainly wouldn't want an automated tool
performing that upgrade. Even with human intervention, this would
introduce a new upgrade path that would have to be carefully integrated
and well-understood. Dealing with this mechanism would probably require
first dealing with the base system install and upgrade issues--the two
mechanisms should be the same.
I first useful step would be if the advisory could be read in, and your
vulnerability automatically assessed. You would be informed if the
relevant library were installed, what binaries depended on it, if the port
was installed, and if so what depended on it. This all requires us to be
more concise about describing the vulnerability and its potential effects.
Ideally, all of this should be able to occur in an automated manner -- the
SO identifies a library or binary increasing risk, and to a large extent
the grunt-work of identifying dependencies and generating a risk report
would be automated.
There are some vulnerability scanning products that claim to support
automated correction. It would be worth looking at those to see what, if
anything, they do to solve the problem.
Robert N M Watson
robert@fledge.watson.org http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1000715114100.15043D-100000>