From owner-freebsd-security@freebsd.org Wed Oct 26 08:18:41 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 88960C21407 for ; Wed, 26 Oct 2016 08:18:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2110C61A; Wed, 26 Oct 2016 08:18:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u9Q8IZM9066282 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 26 Oct 2016 11:18:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u9Q8IZM9066282 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u9Q8IZcL066281; Wed, 26 Oct 2016 11:18:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 26 Oct 2016 11:18:35 +0300 From: Konstantin Belousov To: "Robert N. M. Watson" Cc: Pawel Jakub Dawidek , freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-16:15.sysarch [REVISED] Message-ID: <20161026081835.GR54029@kib.kiev.ua> References: <20161025173641.BCDFD1911@freefall.freebsd.org> <20161026042748.GG60006@garage.freebsd.pl> <20161026061504.GH60006@garage.freebsd.pl> <0717BEFA-4E65-4990-AC50-FD80681C110C@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0717BEFA-4E65-4990-AC50-FD80681C110C@FreeBSD.org> User-Agent: Mutt/1.7.1 (2016-10-04) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 08:18:41 -0000 On Wed, Oct 26, 2016 at 07:53:44AM +0100, Robert N. M. Watson wrote: > Hi Pawel: > > In general, my strong recommendation is against issuing advisories for local denial-of-service attacks, in part because it suggests we consider it a security guarantee of the system that those problems can be reliably prevented. At least in current operating-system designs, preventing local DoS is a very hard problem (not quite up there with covert channels, but certainly not something we can do reliably) ??? and so I think it would be misleading to suggest to our users that they can expect them not to exist at all. If something is being widely exploited, then it might be appropriate to issue an errata update, but I think if it???s something obscure where a local user to trigger a panic (and there really is no escalation path to kernel privilege, for example), then I think an advisory would generally be a mistake. Otherwise we???d find that a huge number of our ordinary kernel bug fixes get reclassified as security patches requiring advisories, if nothing else! > > (In this case, I???m not passing judgement one way or the other ??? zeroing of arbitrary kernel memory can have more broad implications than a panic ??? for example, you can imagine that if it were to zero a process credential, a process might start running unexpectedly as root. And what were once thought to be innocuous crashes due to NULL-pointer dereferences turn out not to be!) It is not quite arbitrary kernel memory, memory is adjanced to the region allocated with kmem_malloc(kernel_arena), which puts the allocated chunk aside from the typical kernel allocations. In fact, most likely the allocated chunk is followed by an unmapped page, which means that attempt to zero past the end of legit chunk traps. In other words, I consider the escalation of the issue unlikely or, at least, hard. FWIW, I asked the same question as Pawel when initial SA was created. The answer was not technical but satisfactory.