From owner-freebsd-security@FreeBSD.ORG Tue Sep 15 15:22:31 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 B4244106566C for ; Tue, 15 Sep 2009 15:22:31 +0000 (UTC) (envelope-from matt@chronos.org.uk) Received: from chronos.org.uk (chronos-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:12b::2]) by mx1.freebsd.org (Postfix) with ESMTP id 256E08FC1C for ; Tue, 15 Sep 2009 15:22:30 +0000 (UTC) Received: from workstation1.localnet (workstation1.local.chronos.org.uk [IPv6:2001:470:1f09:12b::20]) (authenticated bits=0) by chronos.org.uk (8.14.3/8.14.3) with ESMTP id n8FFMREn011370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 15 Sep 2009 16:22:28 +0100 (BST) (envelope-from matt@chronos.org.uk) X-DKIM: Sendmail DKIM Filter v2.8.3 chronos.org.uk n8FFMREn011370 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=chronos.org.uk; s=mail; t=1253028148; bh=Rck+iG2R1Nt4BGpusyJlQIa0gsrxf8pbJgH3wbfz0+4=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=pglsajQ0CtbDy02JK1p/kMt4LfGXNq0SyTISRXnHyQOSL4BBNRXF7bR7LteYYJ+FZ 6wXlz8Mpp50xddkaalBIxsKk3Qyeew9vSWVREhjIzCaDINCL32fZE0AL5qCsS1e/gq fQUNtm59NAFFhD2HoPETo93peC33OOTaj4VyDGig= From: Matt Dawson To: freebsd-security@freebsd.org Date: Tue, 15 Sep 2009 16:22:26 +0100 User-Agent: KMail/1.12.1 (FreeBSD/7.2-RELEASE-p3; KDE/4.3.1; amd64; ; ) References: <4AAF4A64.3080906@thedarkside.nl> <4AAF8775.7000002@thedarkside.nl> <8663bk2xcb.fsf@ds4.des.no> In-Reply-To: <8663bk2xcb.fsf@ds4.des.no> X-Face: Uq{{&_!oO{M&ydj?-f%{D]bN7/|/]a+utod35[+IyH#R>F~YPffK,=?utf-8?q?=25=60=7D=25=0A?=FTMbmzo,]0X3K:N&{h7],FI{?EkORzB; f:V3"vKXsUNw5Yh`}ef4MZ*a4,=?utf-8?q?ObuJ=5F=26=5B1S=27zP=5CK0wcKZP=0A?==?utf-8?q?_=60=23L=25=5Dq*OUPQ-4T=3FHZ=7EAKX0=7D3W=25o=3DP?= X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (chronos.org.uk [IPv6:2001:470:1f09:12b::1]); Tue, 15 Sep 2009 16:22:28 +0100 (BST) X-Virus-Scanned: clamav-milter 0.95.2 at central.local.chronos.org.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.1 required=3.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,NO_RELAYS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on central.local.chronos.org.uk 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 15:22:31 -0000 On Tuesday 15 Sep 2009 13:42:28 Dag-Erling Sm=C3=B8rgrav wrote: > there must be a better way to make your case than to sow FUD? Where? To paraphrase yourself: Please define "sowing FUD." There's an issue= ;=20 there have been two previously. Nobody is blaming anyone, blowing it out of= =20 proportion, leaving FBSD in droves or pointing fingers. We know it's local = and=20 we're all well aware of the axiom "if someone else has physical access to y= our=20 box, it isn't your box any more." I don't see or feel any fear, uncertainty= or=20 doubt. I just see a concerned but dedicated FBSD user discussing an issue=20 sensibly with the information currently to hand. Providing it does not seriously affect anything else (Pieter has already as= ked=20 for information and opinions before the thread went off on this tangent), i= f=20 setting this #define downgrades arbitrary code execution vulnerabilities an= d=20 privilege escalations to crashes where system and, more importantly IMHO, h= ost=20 integrity is preserved then I am all for it. I'd certainly rather have a Do= S=20 and the risk of cached data loss than a potential information leak or a=20 reputation-destroying spamming session run. That we don't have multiple pla= ces=20 that this could be overridden/reset similar to the SELinux issue also inspi= res=20 confidence in Pieter's method. As simple as it seems, it would appear to be= =20 (sorry, buzzword-that-fits coming up) proactive in its approach, addressing= =20 and mitigating any future issues of this type and limiting the possible=20 damage. Also worth thinking about: Do we need to consider -fno-delete-null-pointer- checks or a downgrade to -O for kernel/world optimisation level for now unt= il=20 we're sure there are no more of these lurking? Linux found out the hard way= =20 that code order matters when compiling at >-O and that perfectly acceptable= =20 code coupled with assumptions made by the compiler can bite you in the=20 backside. =2D-=20 Matt Dawson MTD15-RIPE matt@chronos.org.uk