From owner-freebsd-security@FreeBSD.ORG Tue Sep 15 14:20:43 2009 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED5AC1065695 for ; Tue, 15 Sep 2009 14:20:43 +0000 (UTC) (envelope-from jon@passki.us) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id B3C2B8FC22 for ; Tue, 15 Sep 2009 14:20:43 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so1158225qwe.7 for ; Tue, 15 Sep 2009 07:20:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.54.143 with SMTP id q15mr2292784qcg.74.1253023100493; Tue, 15 Sep 2009 06:58:20 -0700 (PDT) X-Originating-IP: [209.98.139.33] In-Reply-To: <86ab0w2z05.fsf@ds4.des.no> References: <4AAF4A64.3080906@thedarkside.nl> <86ab0w2z05.fsf@ds4.des.no> Date: Tue, 15 Sep 2009 08:58:20 -0500 Message-ID: From: Jon Passki To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org, Pieter de Boer Subject: Re: Protecting against kernel NULL-pointer derefs X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 14:20:44 -0000 2009/9/15 Dag-Erling Sm=F8rgrav > > Pieter de Boer writes: > > Given the amount of NULL-pointer dereference vulnerabilities in the > > FreeBSD kernel that have been discovered of late, > > Specify "amount" and define "of late". > > > By disallowing userland to map pages at address 0x0 (and a bit beyond), > > it is possible to make such NULL-pointer deref bugs mere DoS'es instead > > of code execution bugs. Linux has implemented such a protection for a > > long while now, by disallowing page mappings on 0x0 - 0xffff. > > Yes, that really worked out great for them: > > http://isc.sans.org/diary.html?storyid=3D6820 As I assume you know, one reason (not the only reason) the exploit works is because the SELinux default policy allowed (allows?) users to map at NULL, regardless of the protections offered by the OS (e.g. Redhat w/ mmap_min_addr). His later exploit framework abuses SELinux another way by downgrading protection by going into libselinux and uses a context such as wine_t to execute at NULL [1]. It's not that mmap_min_addr failed (which it doesn't on some distros of Linux); it's that other mechanisms exist that can undo the control put into place. Cheers, Jon Passki [1] http://grsecurity.net/~spender/enlightenment.tgz, exploit.c, pa__init()