From owner-freebsd-security Sat Jul 15 8:53: 7 2000 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id D9A7F37BBA7 for ; Sat, 15 Jul 2000 08:53:00 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id LAA15666; Sat, 15 Jul 2000 11:52:56 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 15 Jul 2000 11:52:56 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Bengt Richter Cc: freebsd-security@FreeBSD.ORG Subject: Re: RFC for Advisories? (Was Re: Newer/Two kinds of advisories?) In-Reply-To: <3.0.5.32.20000714142038.00908650@mail.accessone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 14 Jul 2000, Bengt Richter wrote: > "NOTICE: vulnscand has received and authenticated advisory , > and has (per vulnscand.conf auto option) disabled execution of > / > due to a level 7.2 ('Immediate Action Urgent') vulnerability. > Type vulnscan -i 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