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=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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200909151622.26589.matt>