Date: Tue, 15 Sep 2009 16:22:26 +0100 From: Matt Dawson <matt@chronos.org.uk> To: freebsd-security@freebsd.org Subject: Re: Protecting against kernel NULL-pointer derefs Message-ID: <200909151622.26589.matt@chronos.org.uk> In-Reply-To: <8663bk2xcb.fsf@ds4.des.no> References: <4AAF4A64.3080906@thedarkside.nl> <4AAF8775.7000002@thedarkside.nl> <8663bk2xcb.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 15 Sep 2009 13:42:28 Dag-Erling Smørgrav 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; there have been two previously. Nobody is blaming anyone, blowing it out of proportion, leaving FBSD in droves or pointing fingers. We know it's local and we're all well aware of the axiom "if someone else has physical access to your box, it isn't your box any more." I don't see or feel any fear, uncertainty or doubt. I just see a concerned but dedicated FBSD user discussing an issue sensibly with the information currently to hand. Providing it does not seriously affect anything else (Pieter has already asked for information and opinions before the thread went off on this tangent), if setting this #define downgrades arbitrary code execution vulnerabilities and privilege escalations to crashes where system and, more importantly IMHO, host integrity is preserved then I am all for it. I'd certainly rather have a DoS and the risk of cached data loss than a potential information leak or a reputation-destroying spamming session run. That we don't have multiple places that this could be overridden/reset similar to the SELinux issue also inspires confidence in Pieter's method. As simple as it seems, it would appear to be (sorry, buzzword-that-fits coming up) proactive in its approach, addressing and mitigating any future issues of this type and limiting the possible 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 until we're sure there are no more of these lurking? Linux found out the hard way that code order matters when compiling at >-O and that perfectly acceptable code coupled with assumptions made by the compiler can bite you in the backside. -- Matt Dawson MTD15-RIPE matt@chronos.org.uk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200909151622.26589.matt>