From astorms at ncircle.com Tue Sep 8 19:11:00 2009 From: astorms at ncircle.com (Andrew Storms) Date: Tue Sep 8 19:11:07 2009 Subject: CVE-2008-4609 Message-ID: Now that the details are out - MS and Cisco patched today. I went looking back into the FreeBSD security announcements and don't seem to be able to find any references for a patch. Did FreeBSD already patch or discuss this bug and I missed it? http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4609 Thanks -_S From ohauer at gmx.de Tue Sep 8 21:25:21 2009 From: ohauer at gmx.de (olli hauer) Date: Tue Sep 8 21:25:28 2009 Subject: CVE-2008-4609 Message-ID: <20090908205832.GA8174@sorry.mine.nu> > Now that the details are out - MS and Cisco patched today. > I went looking back into the FreeBSD security announcements and don't > seem > to be able to find any references for a patch. > Did FreeBSD already patch or discuss this bug and I missed it? > > http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4609 > > Thanks > > -_S According the more complete list at http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2008-4609 the latest rel. (FreeBSD 6.4/7.2, OpenBSD 4.4+) are not a affected. It seems if you run the latest versions of Free/OpenBSD you are fine. olli From des at des.no Tue Sep 8 21:37:06 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Sep 8 21:37:13 2009 Subject: CVE-2008-4609 In-Reply-To: (Andrew Storms's message of "Tue, 08 Sep 2009 11:56:24 -0700") References: Message-ID: <86my55nmnz.fsf@ds4.des.no> Andrew Storms writes: > Now that the details are out - MS and Cisco patched today. I went > looking back into the FreeBSD security announcements and don't seem to > be able to find any references for a patch. Did FreeBSD already patch > or discuss this bug and I missed it? This is old news: http://www.google.com/#&q=sockstress The initial version was just connection flooding - they thought it was a big deal because they came up with a very clever and complicated setup to increase the flood rate, when in fact a short C program using bpf could have done the job just as well. When people pointed out that it was a load of bs, they started making wild claims about more serious attacks, the details of which would be released at the next compsec conference, except not really, because we're still working on it, but the next one, we promise, for real this time... Just read their website (http://www.sockstress.com/), it'll give you an idea of just how far off their rocker they are. DES -- Dag-Erling Sm?rgrav - des@des.no From elsiddik at gmail.com Sun Sep 13 12:42:36 2009 From: elsiddik at gmail.com (M.Z.el-Siddik) Date: Sun Sep 13 12:42:52 2009 Subject: (no subject) Message-ID: <4738a3900909130522p16ed833el6015e1279349f8f3@mail.gmail.com> From frederique at isafeelin.org Tue Sep 15 08:01:13 2009 From: frederique at isafeelin.org (Frederique Rijsdijk) Date: Tue Sep 15 08:01:32 2009 Subject: FreeBSD bug grants local root access (FreeBSD 6.x) Message-ID: <4AAF45B4.60307@isafeelin.org> Hi, Any info on this subject on http://www.theregister.co.uk/2009/09/14/freebsd_security_bug/ -- Frederique From pieter at thedarkside.nl Tue Sep 15 08:03:49 2009 From: pieter at thedarkside.nl (Pieter de Boer) Date: Tue Sep 15 08:04:07 2009 Subject: Protecting against kernel NULL-pointer derefs Message-ID: <4AAF4A64.3080906@thedarkside.nl> All, Given the amount of NULL-pointer dereference vulnerabilities in the FreeBSD kernel that have been discovered of late, I've started looking at a way to generically protect against the code execution possibilities of such bugs. 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. On FreeBSD, it appears that simply bumping up VM_MIN_ADDRESS to 65536 downgrades a whole class of code execution vulnerabilities to DoS vulnerabilities. I've raised that #define to 65536 on a 6.4-RELEASE i386 VM. This made at least the mmap() method to map at 0x0 fail. So: - How do you feel about disallowing such mappings to protect against NULL-pointer deref code executions? - Is bumping VM_MIN_ADDRESS enough to protect against all methods of creating such mappings (on all supported platforms)? - Are there unwanted side-effects of raising VM_MIN_ADDRESS? - Should I file a PR to get this into FreeBSD? Lemme know, Pieter From delphij at delphij.net Tue Sep 15 09:08:53 2009 From: delphij at delphij.net (Xin LI) Date: Tue Sep 15 09:09:00 2009 Subject: FreeBSD bug grants local root access (FreeBSD 6.x) In-Reply-To: <4AAF45B4.60307@isafeelin.org> References: <4AAF45B4.60307@isafeelin.org> Message-ID: <4AAF5999.7020501@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Frederique Rijsdijk wrote: > Hi, > > Any info on this subject on > > http://www.theregister.co.uk/2009/09/14/freebsd_security_bug/ Currently we (secteam@) are testing the correction patch and do peer-review on the security advisory draft, the bug was found and fixed on -HEAD and 7-STABLE before 7.1-RELEASE during some stress test but was not recognized as a security vulnerability at that time. The exploit code has to be executed locally, i.e. either by an untrusted local user, or be exploited in conjunction with some remote vulnerability on applications that allow the attacker to inject their own code. We can not release further details about the problem at this time, though, but I think we will likely to publish the advisory and correction patch this patch Wednesday. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkqvWZgACgkQi+vbBBjt66DAwACdHwj+VB8Ak0oRwhiH7X16+2Wl nU0An2bMd4Y40DqCUJI+DEmNmozmm7fz =+LtQ -----END PGP SIGNATURE----- From utisoft at googlemail.com Tue Sep 15 09:11:02 2009 From: utisoft at googlemail.com (utisoft@googlemail.com) Date: Tue Sep 15 11:32:27 2009 Subject: FreeBSD bug grants local root access (FreeBSD 6.x) In-Reply-To: <4AAF45B4.60307@isafeelin.org> Message-ID: <0016e6d99efa540b8b047399738b@google.com> On 15 Sep 2009 08:43, Frederique Rijsdijk wrote: > Hi, > Any info on this subject on > http://www.theregister.co.uk/2009/09/14/freebsd_security_bug/ It appears to only affect 6.x.... and requires local access. If an attacker has local access to a machine you're screwed anyway. Chris From des at des.no Tue Sep 15 12:06:36 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Sep 15 12:06:43 2009 Subject: Protecting against kernel NULL-pointer derefs In-Reply-To: <4AAF4A64.3080906@thedarkside.nl> (Pieter de Boer's message of "Tue, 15 Sep 2009 10:03:48 +0200") References: <4AAF4A64.3080906@thedarkside.nl> Message-ID: <86ab0w2z05.fsf@ds4.des.no> 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=6820 DES -- Dag-Erling Sm?rgrav - des@des.no From pieter at thedarkside.nl Tue Sep 15 12:24:23 2009 From: pieter at thedarkside.nl (Pieter de Boer) Date: Tue Sep 15 12:24:30 2009 Subject: Protecting against kernel NULL-pointer derefs In-Reply-To: <86ab0w2z05.fsf@ds4.des.no> References: <4AAF4A64.3080906@thedarkside.nl> <86ab0w2z05.fsf@ds4.des.no> Message-ID: <4AAF8775.7000002@thedarkside.nl> Dag-Erling Sm?rgrav wrote: >> Given the amount of NULL-pointer dereference vulnerabilities in the >> FreeBSD kernel that have been discovered of late, > Specify "amount" and define "of late". 'amount' => 2, 'of late' is more figure of speech than anything else. For me, amount was high enough to get interested and 'of late' may be because I've not been looking long enough. >> 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=6820 I was aware of that issue, and was expecting your comment as well. While SELinux (and iirc SysV compatibility) effectively killed the "don't map at 0x0" feature, that does not mean such a feature is useless in of itself. If it is possible to attain a high enough level of confidence that such a feature would actually work, without negative side-effects, I feel that it would be beneficial to FreeBSD. I'd be interested in hearing your and other's opinions, specifically on the topics my original questions hinted at. -- Pieter From des at des.no Tue Sep 15 12:42:30 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Sep 15 12:42:37 2009 Subject: Protecting against kernel NULL-pointer derefs In-Reply-To: <4AAF8775.7000002@thedarkside.nl> (Pieter de Boer's message of "Tue, 15 Sep 2009 14:24:21 +0200") References: <4AAF4A64.3080906@thedarkside.nl> <86ab0w2z05.fsf@ds4.des.no> <4AAF8775.7000002@thedarkside.nl> Message-ID: <8663bk2xcb.fsf@ds4.des.no> Pieter de Boer writes: > Dag-Erling Sm?rgrav writes: > > 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". > 'amount' => 2, 'of late' is more figure of speech than anything > else. For me, amount was high enough to get interested and 'of late' > may be because I've not been looking long enough. A search of FreeBSD security advisories shows two in the last four years, plus the current unreleased issue. I agree that there is no reason to allow applications to mmap() at address 0, but surely there must be a better way to make your case than to sow FUD? DES -- Dag-Erling Sm?rgrav - des@des.no From pieter at thedarkside.nl Tue Sep 15 13:01:00 2009 From: pieter at thedarkside.nl (Pieter de Boer) Date: Tue Sep 15 13:01:06 2009 Subject: Protecting against kernel NULL-pointer derefs In-Reply-To: <8663bk2xcb.fsf@ds4.des.no> References: <4AAF4A64.3080906@thedarkside.nl> <86ab0w2z05.fsf@ds4.des.no> <4AAF8775.7000002@thedarkside.nl> <8663bk2xcb.fsf@ds4.des.no> Message-ID: <4AAF900B.8010900@thedarkside.nl> Dag-Erling Sm?rgrav wrote: >> 'amount' => 2, 'of late' is more figure of speech than anything >> else. For me, amount was high enough to get interested and 'of late' >> may be because I've not been looking long enough. > > A search of FreeBSD security advisories shows two in the last four > years, plus the current unreleased issue. I agree that there is no > reason to allow applications to mmap() at address 0, but surely there > must be a better way to make your case than to sow FUD? I have no intention to sow FUD. Three such advisories is not much, but if there is a simple/inexpensive way to ensure that such bugs are not exploitable to gain root, I think 'we' should consider it. -- Pieter From jon at passki.us Tue Sep 15 14:20:44 2009 From: jon at passki.us (Jon Passki) Date: Tue Sep 15 14:20:51 2009 Subject: Protecting against kernel NULL-pointer derefs In-Reply-To: <86ab0w2z05.fsf@ds4.des.no> References: <4AAF4A64.3080906@thedarkside.nl> <86ab0w2z05.fsf@ds4.des.no> Message-ID: 2009/9/15 Dag-Erling Sm?rgrav > > 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=6820 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() From leccine at gmail.com Tue Sep 15 14:24:42 2009 From: leccine at gmail.com (=?ISO-8859-1?B?SXN0duFu?=) Date: Tue Sep 15 14:24:49 2009 Subject: Protecting against kernel NULL-pointer derefs In-Reply-To: References: <4AAF4A64.3080906@thedarkside.nl> <86ab0w2z05.fsf@ds4.des.no> Message-ID: hehe this is the "install another security layer to introduce less security" model 2009/9/15 Jon Passki > 2009/9/15 Dag-Erling Sm?rgrav > > > > 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=6820 > > 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() > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org > " > -- the sun shines for all From matt at chronos.org.uk Tue Sep 15 15:22:31 2009 From: matt at chronos.org.uk (Matt Dawson) Date: Tue Sep 15 15:22:39 2009 Subject: Protecting against kernel NULL-pointer derefs In-Reply-To: <8663bk2xcb.fsf@ds4.des.no> References: <4AAF4A64.3080906@thedarkside.nl> <4AAF8775.7000002@thedarkside.nl> <8663bk2xcb.fsf@ds4.des.no> Message-ID: <200909151622.26589.matt@chronos.org.uk> 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 From przemyslaw at frasunek.com Tue Sep 15 15:52:10 2009 From: przemyslaw at frasunek.com (Przemyslaw Frasunek) Date: Tue Sep 15 15:52:18 2009 Subject: Protecting against kernel NULL-pointer derefs In-Reply-To: <8663bk2xcb.fsf@ds4.des.no> References: <4AAF4A64.3080906@thedarkside.nl> <86ab0w2z05.fsf@ds4.des.no> <4AAF8775.7000002@thedarkside.nl> <8663bk2xcb.fsf@ds4.des.no> Message-ID: <4AAFB465.4010901@frasunek.com> Dag-Erling Sm?rgrav: > A search of FreeBSD security advisories shows two in the last four > years, plus the current unreleased issue. There are three NULL pointer dereference issues, that I found in last month, but probably more to come, so implementing some kind of zero page protection should be considered. The first one affects 6.1 and it was made public in August: http://www.frasunek.com/kqueue.txt Another one affects 6.4 and is currently handled by secteam. Advisory will be released on Wednesday. The last one, as demonstrated on http://www.vimeo.com/6580991 affects 7.x up to 7.2 and 6.x up to 6.4. I'm not going to disclose any details before official security advisory. From des at des.no Tue Sep 15 16:07:36 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Sep 15 16:07:44 2009 Subject: Protecting against kernel NULL-pointer derefs In-Reply-To: <200909151622.26589.matt@chronos.org.uk> (Matt Dawson's message of "Tue, 15 Sep 2009 16:22:26 +0100") References: <4AAF4A64.3080906@thedarkside.nl> <4AAF8775.7000002@thedarkside.nl> <8663bk2xcb.fsf@ds4.des.no> <200909151622.26589.matt@chronos.org.uk> Message-ID: <863a6our7c.fsf@ds4.des.no> Matt Dawson writes: > Dag-Erling Sm?rgrav writes: > > 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. Pieter strongly implied that there had been *numerous* such cases, when in fact there hasn't. DES -- Dag-Erling Sm?rgrav - des@des.no From des at des.no Tue Sep 15 16:08:22 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Sep 15 16:08:29 2009 Subject: Protecting against kernel NULL-pointer derefs In-Reply-To: <4AAFB465.4010901@frasunek.com> (Przemyslaw Frasunek's message of "Tue, 15 Sep 2009 17:36:05 +0200") References: <4AAF4A64.3080906@thedarkside.nl> <86ab0w2z05.fsf@ds4.des.no> <4AAF8775.7000002@thedarkside.nl> <8663bk2xcb.fsf@ds4.des.no> <4AAFB465.4010901@frasunek.com> Message-ID: <86y6ogtclm.fsf@ds4.des.no> Przemyslaw Frasunek writes: > Dag-Erling Sm?rgrav writes: > > A search of FreeBSD security advisories shows two in the last four > > years, plus the current unreleased issue. > There are three NULL pointer dereference issues, that I found in last > month, but probably more to come, so implementing some kind of zero page > protection should be considered. Feel free to *actually read what Pieter wrote and what I wrote in reply* EOD DES -- Dag-Erling Sm?rgrav - des@des.no From chris at noncombatant.org Tue Sep 15 17:35:25 2009 From: chris at noncombatant.org (Chris Palmer) Date: Tue Sep 15 17:35:33 2009 Subject: Protecting against kernel NULL-pointer derefs In-Reply-To: <4AAF4A64.3080906@thedarkside.nl> References: <4AAF4A64.3080906@thedarkside.nl> Message-ID: <20090915171742.GB24361@noncombatant.org> Pieter's approach to the problem seems reasonable. If it provides some safety without breaking any/too many applications, why not adopt it? I wonder how many of these kinds of issues could also be caught with unit tests/regression tests. See also: the CanSecWest 2009 FreeBSD bugs by Christer Oberg and Neil Kettle. -- http://www.noncombatant.org/ http://hemiolesque.blogspot.com/ From matt at chronos.org.uk Tue Sep 15 18:08:18 2009 From: matt at chronos.org.uk (Matt Dawson) Date: Tue Sep 15 18:08:27 2009 Subject: Protecting against kernel NULL-pointer derefs In-Reply-To: <863a6our7c.fsf@ds4.des.no> References: <4AAF4A64.3080906@thedarkside.nl> <200909151622.26589.matt@chronos.org.uk> <863a6our7c.fsf@ds4.des.no> Message-ID: <200909151908.10099.matt@chronos.org.uk> On Tuesday 15 Sep 2009 17:07:35 Dag-Erling Sm?rgrav wrote: > Pieter strongly implied that there had been numerous such cases, when > in fact there hasn't. Yes, DES, it could be read that way and I apologise. Without trying to wiggle out of that apology, it just seemed a bit harsh when I doubt what was written was meant as "the code is riddled with these things! RIDDLED!" given the fact that Pieter proposed a possible mitigation instead of the expected "El Reg says it's broken! EL REG! Fix it now, goddammit!" ;o) @All: Having put both feet in my mouth and had to publicly apologise, we now have a little more information from Przemyslaw on what is potentially broken and what isn't (7.2, the current production release). That "probably more to come," while still vague and very much unverified, makes me wonder if Pieter's interim mitigation or something very much like it isn't needed Right Now [TM] as he says. So, is there any technically sound reason why raising VM_MIN_ADDRESS to 65536 would not be a good trade-off (or even just a good idea) in security terms until we're sure there are no more of these lurking? A few of us paranoid security types might want to do so manually in the interim if there are no objections. -- Matt Dawson MTD15-RIPE matt@chronos.org.uk From chris at noncombatant.org Tue Sep 15 20:26:55 2009 From: chris at noncombatant.org (Chris Palmer) Date: Tue Sep 15 20:27:17 2009 Subject: FreeBSD bug grants local root access (FreeBSD 6.x) In-Reply-To: <0016e6d99efa540b8b047399738b@google.com> References: <4AAF45B4.60307@isafeelin.org> <0016e6d99efa540b8b047399738b@google.com> Message-ID: <20090915202703.GF24361@noncombatant.org> utisoft@googlemail.com writes: > It appears to only affect 6.x.... and requires local access. If an > attacker has local access to a machine you're screwed anyway. No, the thing you're screwed anyway by is local *physical* access. Merely running a process as a non-root local user should *not* be a "you're screwed anyway" scenario. The fundamental security guarantee of a modern operating system is that different principals cannot affect each other's resources (user chris cannot read or write user jane's email -- let alone root's email). This bug breaks that guarantee, and is definitely not a ho-hum bug. Remote exploits, which I agree are even worse, are in a sense a special case of breaking the same guarantee: the pseudo-principal "anonymous maniac from the Internet" can affect user root's (or whoever's) resources. Some operating systems even have an explicit "anonymous" user, but the point is the same either way. -- http://www.noncombatant.org/ http://hemiolesque.blogspot.com/ From delphij at delphij.net Wed Sep 16 00:02:28 2009 From: delphij at delphij.net (Xin LI) Date: Wed Sep 16 00:02:35 2009 Subject: FreeBSD bug grants local root access (FreeBSD 6.x) In-Reply-To: <0016e6d99efa540b8b047399738b@google.com> References: <0016e6d99efa540b8b047399738b@google.com> Message-ID: <4AB02B07.8050404@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 utisoft@googlemail.com wrote: > It appears to only affect 6.x.... and requires local access. If an > attacker has local access to a machine you're screwed anyway. 'local' here means login as a local user, i.e. ssh/telnet/etc, not console access which seems to be what you mean by 'local access'. Note that, in order to successfully exploit this vulnerability, a remote attacker still need someone or something to run the code on their behalf, typically this would have to be used in conjunction with some other remote vulnerability (i.e. some popular remote admin tool that allows you to upload and run something on web server's context, etc). We are still working on this one, it looks like that we would need to patch some other problems altogether. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkqwKwcACgkQi+vbBBjt66BtawCgsDhrON8DzvX7A6M1O37A2Qw6 /54An0CAgPeTTJcJKcdkVWcF9qX0FVuY =EeKO -----END PGP SIGNATURE----- From delphij at delphij.net Wed Sep 16 00:06:03 2009 From: delphij at delphij.net (Xin LI) Date: Wed Sep 16 00:06:10 2009 Subject: FreeBSD bug grants local root access (FreeBSD 6.x) In-Reply-To: <20090915202703.GF24361@noncombatant.org> References: <4AAF45B4.60307@isafeelin.org> <0016e6d99efa540b8b047399738b@google.com> <20090915202703.GF24361@noncombatant.org> Message-ID: <4AB02BE0.1030305@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Palmer wrote: > utisoft@googlemail.com writes: > >> It appears to only affect 6.x.... and requires local access. If an >> attacker has local access to a machine you're screwed anyway. > > No, the thing you're screwed anyway by is local *physical* access. Merely > running a process as a non-root local user should *not* be a "you're screwed > anyway" scenario. The fundamental security guarantee of a modern operating > system is that different principals cannot affect each other's resources > (user chris cannot read or write user jane's email -- let alone root's > email). This bug breaks that guarantee, and is definitely not a ho-hum bug. Exactly. This type of vulnerability could turn into a serious threat if being used with some other vulnerabilities that allows code injection, which is worse. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkqwK+AACgkQi+vbBBjt66Cu2gCfQWDWssPUTP+YESUOS7pJXCal TY0An332WH2WDUiF1vhlgOW+QUk9U0rk =S2nD -----END PGP SIGNATURE----- From utisoft at googlemail.com Wed Sep 16 15:37:46 2009 From: utisoft at googlemail.com (Chris Rees) Date: Wed Sep 16 15:37:53 2009 Subject: FreeBSD bug grants local root access (FreeBSD 6.x) In-Reply-To: <4AB02BE0.1030305@delphij.net> References: <4AAF45B4.60307@isafeelin.org> <0016e6d99efa540b8b047399738b@google.com> <20090915202703.GF24361@noncombatant.org> <4AB02BE0.1030305@delphij.net> Message-ID: 2009/9/16 Xin LI : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Chris Palmer wrote: >> utisoft@googlemail.com writes: >> >>> It appears to only affect 6.x.... and requires local access. If an >>> attacker has local access to a machine you're screwed anyway. >> >> No, the thing you're screwed anyway by is local *physical* access. Merely >> running a process as a non-root local user should *not* be a "you're screwed >> anyway" scenario. The fundamental security guarantee of a modern operating >> system is that different principals cannot affect each other's resources >> (user chris cannot read or write user jane's email -- let alone root's >> email). This bug breaks that guarantee, and is definitely not a ho-hum bug. > > Exactly. ?This type of vulnerability could turn into a serious threat if > being used with some other vulnerabilities that allows code injection, > which is worse. > > Cheers, > - -- > Xin LI ? ?http://www.delphij.net/ Ahem, I must read posts correctly first. Beg pardon, I'll type that 100 times this evening. Chris -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in a mailing list? From hdk_2 at yahoo.co.jp Fri Sep 18 15:39:56 2009 From: hdk_2 at yahoo.co.jp (Hideki EIRAKU) Date: Fri Sep 18 15:40:05 2009 Subject: Protecting against kernel NULL-pointer derefs In-Reply-To: <4AAF4A64.3080906@thedarkside.nl> References: <4AAF4A64.3080906@thedarkside.nl> Message-ID: <20090919.001313.110616099.hdk_2@yahoo.co.jp> From: Pieter de Boer Subject: Protecting against kernel NULL-pointer derefs Date: Tue, 15 Sep 2009 10:03:48 +0200 > - Are there unwanted side-effects of raising VM_MIN_ADDRESS? Mapping at address 0x0 is needed by some softwares using vm86 mode. For example, emulators/doscmd uses vm86 mode to emulate an old DOS environment. In this case, the address 0x0 - 0x3ff is used for an interrupt vector of emulated DOS world. If VM_MIN_ADDRESS is not zero, doscmd doesn't work. vm86 mode is in 32bit i386 architecture only, not in amd64 or other architectures. -- Hideki EIRAKU -------------------------------------- Thanks 10 years! Yahoo! Shopping and Yahoo! Auctions http://pr.mail.yahoo.co.jp/ec10years/ From leccine at gmail.com Fri Sep 18 15:52:05 2009 From: leccine at gmail.com (=?ISO-8859-1?B?SXN0duFu?=) Date: Fri Sep 18 15:52:12 2009 Subject: Protecting against kernel NULL-pointer derefs In-Reply-To: <20090919.001313.110616099.hdk_2@yahoo.co.jp> References: <4AAF4A64.3080906@thedarkside.nl> <20090919.001313.110616099.hdk_2@yahoo.co.jp> Message-ID: the question is how much percent of the user are using wine and dosbox which are going to break with this setting, i guess 10% or less. So those guys could use _NO_VM_MIN kernel or something while the rest of the world would fly high with secured kernel. to quote a security friend: the freebsd was the last target platform for this bugclass :)) regards, Istvan On Fri, Sep 18, 2009 at 4:13 PM, Hideki EIRAKU wrote: > From: Pieter de Boer > Subject: Protecting against kernel NULL-pointer derefs > Date: Tue, 15 Sep 2009 10:03:48 +0200 > > > - Are there unwanted side-effects of raising VM_MIN_ADDRESS? > > Mapping at address 0x0 is needed by some softwares using vm86 mode. > For example, emulators/doscmd uses vm86 mode to emulate an old DOS > environment. In this case, the address 0x0 - 0x3ff is used for an > interrupt vector of emulated DOS world. If VM_MIN_ADDRESS is not zero, > doscmd doesn't work. vm86 mode is in 32bit i386 architecture only, not > in amd64 or other architectures. > > -- > Hideki EIRAKU > -------------------------------------- > Thanks 10 years! Yahoo! Shopping and Yahoo! Auctions > http://pr.mail.yahoo.co.jp/ec10years/ > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org > " > -- the sun shines for all From julian at elischer.org Fri Sep 18 17:20:56 2009 From: julian at elischer.org (Julian Elischer) Date: Fri Sep 18 18:06:27 2009 Subject: Protecting against kernel NULL-pointer derefs In-Reply-To: References: <4AAF4A64.3080906@thedarkside.nl> <20090919.001313.110616099.hdk_2@yahoo.co.jp> Message-ID: <4AB3BEC7.6090409@elischer.org> Istv?n wrote: > the question is how much percent of the user are using wine and dosbox which > are going to break with this setting, i guess 10% or less. So those guys > could use _NO_VM_MIN kernel or something while the rest of the world would > fly high with secured kernel. The assumption is that the userland and kernel share a memory map. While we do implement it this way, it is not necessarily needed. We do it for performance reasons (each user memory map includes an identical top section that is the kernel space, so that we do not need to switch memory page arenas (change CR3) when entering the kernel. However it might be possible to not do this, and in fact on some hardware it is mandatory to not do this). It would require a page table arena switch with each syscall which would require flushing the TLBs which would be expensive.. Hmm I guess I've talked myself out of this as a solution.. :-) Julian > > to quote a security friend: > > the freebsd was the last target platform for this bugclass :)) > > regards, > Istvan > > > On Fri, Sep 18, 2009 at 4:13 PM, Hideki EIRAKU wrote: > >> From: Pieter de Boer >> Subject: Protecting against kernel NULL-pointer derefs >> Date: Tue, 15 Sep 2009 10:03:48 +0200 >> >>> - Are there unwanted side-effects of raising VM_MIN_ADDRESS? >> Mapping at address 0x0 is needed by some softwares using vm86 mode. >> For example, emulators/doscmd uses vm86 mode to emulate an old DOS >> environment. In this case, the address 0x0 - 0x3ff is used for an >> interrupt vector of emulated DOS world. If VM_MIN_ADDRESS is not zero, >> doscmd doesn't work. vm86 mode is in 32bit i386 architecture only, not >> in amd64 or other architectures. >> >> -- >> Hideki EIRAKU >> -------------------------------------- >> Thanks 10 years! Yahoo! Shopping and Yahoo! Auctions >> http://pr.mail.yahoo.co.jp/ec10years/ >> _______________________________________________ >> freebsd-security@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-security >> To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org >> " >> > > > From pieter at thedarkside.nl Fri Sep 18 21:04:42 2009 From: pieter at thedarkside.nl (Pieter de Boer) Date: Fri Sep 18 21:04:49 2009 Subject: Protecting against kernel NULL-pointer derefs In-Reply-To: <4AB3BEC7.6090409@elischer.org> References: <4AAF4A64.3080906@thedarkside.nl> <20090919.001313.110616099.hdk_2@yahoo.co.jp> <4AB3BEC7.6090409@elischer.org> Message-ID: <4AB3F5DB.5070304@thedarkside.nl> Julian wrote: > The assumption is that the userland and kernel share a memory map. > While we do implement it this way, it is not necessarily needed. > We do it for performance reasons (each user memory map includes an > identical top section that is the kernel space, so that we do not need > to switch memory page arenas (change CR3) when entering the kernel. > However it might be possible to not do this, and in fact on some > hardware it is mandatory to not do this). > > It would require a page table arena switch with each syscall which > would require flushing the TLBs which would be expensive.. > Hmm I guess I've talked myself out of this as a solution.. :-) So, to be able to run VM86 mode or Wine we could make the NULL mapping protection a configurable kernel option, (defaulting to 'on'?), which doscmd/wine users could turn off. A nicer way would be to be able to map 0x0 in userland while having the kernel use its own 0x0 mapping. Possibly there is a way to do that without making context switches very expensive? Partial TLB flushes?? I also wonder how Linux and (possibly) other OS'es handle this; I can imagine it can easily become quite messy resulting in added security issues or insufficient protection. Anyone have pointers to that regard? -- Pieter From drosih at rpi.edu Fri Sep 18 22:15:14 2009 From: drosih at rpi.edu (Garance A Drosihn) Date: Fri Sep 18 22:15:21 2009 Subject: Protecting against kernel NULL-pointer derefs In-Reply-To: <20090919.001313.110616099.hdk_2@yahoo.co.jp> References: <4AAF4A64.3080906@thedarkside.nl> <20090919.001313.110616099.hdk_2@yahoo.co.jp> Message-ID: At 12:13 AM +0900 9/19/09, Hideki EIRAKU wrote: >From: Pieter de Boer >Subject: Protecting against kernel NULL-pointer derefs >Date: Tue, 15 Sep 2009 10:03:48 +0200 > >> - Are there unwanted side-effects of raising VM_MIN_ADDRESS? > >Mapping at address 0x0 is needed by some softwares using vm86 mode. >For example, emulators/doscmd uses vm86 mode to emulate an old DOS >environment. In this case, the address 0x0 - 0x3ff is used for an >interrupt vector of emulated DOS world. If VM_MIN_ADDRESS is not >zero, doscmd doesn't work. vm86 mode is in 32bit i386 architecture >only, not in amd64 or other architectures. Could we: a) alter those programs so they didn't need that vector in page 0? or b) provide some system call or other facility which would allow *that* process to use page 0? -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From brde at optusnet.com.au Sat Sep 19 16:36:32 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Sat Sep 19 16:36:38 2009 Subject: Protecting against kernel NULL-pointer derefs In-Reply-To: <4AB3F5DB.5070304@thedarkside.nl> References: <4AAF4A64.3080906@thedarkside.nl> <20090919.001313.110616099.hdk_2@yahoo.co.jp> <4AB3BEC7.6090409@elischer.org> <4AB3F5DB.5070304@thedarkside.nl> Message-ID: <20090920001841.G933@besplex.bde.org> On Fri, 18 Sep 2009, Pieter de Boer wrote: > Julian wrote: >> The assumption is that the userland and kernel share a memory map. >> While we do implement it this way, it is not necessarily needed. >> We do it for performance reasons (each user memory map includes an >> identical top section that is the kernel space, so that we do not need >> to switch memory page arenas (change CR3) when entering the kernel. >> However it might be possible to not do this, and in fact on some >> hardware it is mandatory to not do this). >> >> It would require a page table arena switch with each syscall which >> would require flushing the TLBs which would be expensive.. >> Hmm I guess I've talked myself out of this as a solution.. :-) > > So, to be able to run VM86 mode or Wine we could make the NULL mapping > protection a configurable kernel option, (defaulting to 'on'?), which > doscmd/wine users could turn off. Does VM86 mode really require or use mapping to kernel address 0? I think it doesn't and shouldn't, since VM86 mode gets a special %cs which can have a nonzero base address. Hmm, the user %cs is always different from the kernel %cs, so I think it can alway have a nonzero base, but then user addresses would be different from kernel address, which would require large changes and small extra runtime to convert the addresses. VM86 mode would hopefully require only small or null changes since it is already weird. > A nicer way would be to be able to map > 0x0 in userland while having the kernel use its own 0x0 mapping. > Possibly there is a way to do that without making context switches very > expensive? Partial TLB flushes?? Not just context switches, but all kernel entries and exits are relevant. I think the cost of switching the map would be small if you only do it when necessary (on every kernel entry/exit from/to a user context that has pages mapped near address 0). Most switches should be null since most processes shouldn't do that. This can be optimized a bit more by delaying the switch back to the unsafe user map until userland actually accesses a low address. Bruce From kostikbel at gmail.com Sat Sep 19 17:26:44 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Sat Sep 19 17:26:51 2009 Subject: Protecting against kernel NULL-pointer derefs In-Reply-To: <20090920001841.G933@besplex.bde.org> References: <4AAF4A64.3080906@thedarkside.nl> <20090919.001313.110616099.hdk_2@yahoo.co.jp> <4AB3BEC7.6090409@elischer.org> <4AB3F5DB.5070304@thedarkside.nl> <20090920001841.G933@besplex.bde.org> Message-ID: <20090919164837.GF47688@deviant.kiev.zoral.com.ua> On Sun, Sep 20, 2009 at 12:44:25AM +1000, Bruce Evans wrote: > On Fri, 18 Sep 2009, Pieter de Boer wrote: > > >Julian wrote: > >>The assumption is that the userland and kernel share a memory map. > >>While we do implement it this way, it is not necessarily needed. > >>We do it for performance reasons (each user memory map includes an > >>identical top section that is the kernel space, so that we do not need > >>to switch memory page arenas (change CR3) when entering the kernel. > >>However it might be possible to not do this, and in fact on some > >>hardware it is mandatory to not do this). > >> > >>It would require a page table arena switch with each syscall which > >>would require flushing the TLBs which would be expensive.. > >>Hmm I guess I've talked myself out of this as a solution.. :-) > > > >So, to be able to run VM86 mode or Wine we could make the NULL mapping > >protection a configurable kernel option, (defaulting to 'on'?), which > >doscmd/wine users could turn off. > > Does VM86 mode really require or use mapping to kernel address 0? I think > it doesn't and shouldn't, since VM86 mode gets a special %cs which can > have a nonzero base address. Hmm, the user %cs is always different from > the kernel %cs, so I think it can alway have a nonzero base, but then > user addresses would be different from kernel address, which would require > large changes and small extra runtime to convert the addresses. VM86 > mode would hopefully require only small or null changes since it is already > weird. In vm86 mode, %cs works exactly the same as in real mode, as well as all other segment registers. vm86-mode code is free to load any 16bit value into any segment register, and virtual address is calculated as (seg << 4) + offset. > > >A nicer way would be to be able to map > >0x0 in userland while having the kernel use its own 0x0 mapping. > >Possibly there is a way to do that without making context switches very > >expensive? Partial TLB flushes?? > > Not just context switches, but all kernel entries and exits are relevant. > I think the cost of switching the map would be small if you only do > it when necessary (on every kernel entry/exit from/to a user context > that has pages mapped near address 0). Most switches should be null > since most processes shouldn't do that. This can be optimized a bit > more by delaying the switch back to the unsafe user map until userland > actually accesses a low address. Redhat did that some time ago, but do not any more. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20090919/05590cf4/attachment.pgp From mike at sentex.net Fri Sep 25 13:05:20 2009 From: mike at sentex.net (Mike Tancsa) Date: Fri Sep 25 13:05:27 2009 Subject: FreeBSD bug grants local root access (FreeBSD 6.x) In-Reply-To: <4AAF5999.7020501@delphij.net> References: <4AAF45B4.60307@isafeelin.org> <4AAF5999.7020501@delphij.net> Message-ID: <200909251248.n8PCmJPY011925@lava.sentex.ca> At 05:08 AM 9/15/2009, Xin LI wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Hi, > >Frederique Rijsdijk wrote: > > Hi, > > > > Any info on this subject on > > > > http://www.theregister.co.uk/2009/09/14/freebsd_security_bug/ > >Currently we (secteam@) are testing the correction patch and do >peer-review on the security advisory draft, the bug was found and fixed >on -HEAD and 7-STABLE before 7.1-RELEASE during some stress test but was >not recognized as a security vulnerability at that time. The exploit >code has to be executed locally, i.e. either by an untrusted local user, >or be exploited in conjunction with some remote vulnerability on >applications that allow the attacker to inject their own code. > >We can not release further details about the problem at this time, >though, but I think we will likely to publish the advisory and >correction patch this patch Wednesday. Hi, Just wondering if there is any update on this issue ? ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From simon at FreeBSD.org Fri Sep 25 22:05:24 2009 From: simon at FreeBSD.org (Simon L. Nielsen) Date: Fri Sep 25 22:05:30 2009 Subject: bundled openssl version In-Reply-To: <20090827192946.7f5782c3@Picasso.Zahemszky.HU> References: <25ae98a90908270451m1d3c17b2nab12dc259f808848@mail.gmail.com> <20090827192946.7f5782c3@Picasso.Zahemszky.HU> Message-ID: <20090925220524.GC1275@arthur.nitro.dk> On 2009.08.27 19:29:46 +0200, Zahemszky G?bor wrote: > >> I'm just puzzled why we still stick to 0.9.8e. It's almost ancient. > >> Why not 0.9.8f? Doesn't someone need TLS extensions working? > > > Why don't you use security/openssl ? > > Why do we need a port, if we can / could use the program from the base > system? Well, 0.9.8f is also rather ancient :-). Anyway: [simon@frankie:~] openssl version OpenSSL 0.9.8k 25 Mar 2009 [simon@frankie:~] uname -a FreeBSD frankie.nitro.dk 8.0-RC1 FreeBSD 8.0-RC1 #0: Thu Sep 17 20:45:19 UTC 2009 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 I also hope to MFC it to 7-stable, but I need to check that the ABI and ABI is compatible first... -- Simon L. Nielsen Hat: OpenSSL janitor From rwatson at FreeBSD.org Sun Sep 27 18:39:13 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Sep 27 18:39:20 2009 Subject: Protecting against kernel NULL-pointer derefs In-Reply-To: <4AAF4A64.3080906@thedarkside.nl> References: <4AAF4A64.3080906@thedarkside.nl> Message-ID: On Tue, 15 Sep 2009, Pieter de Boer wrote: > Given the amount of NULL-pointer dereference vulnerabilities in the FreeBSD > kernel that have been discovered of late, I've started looking at a way to > generically protect against the code execution possibilities of such bugs. > > 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. > > On FreeBSD, it appears that simply bumping up VM_MIN_ADDRESS to 65536 > downgrades a whole class of code execution vulnerabilities to DoS > vulnerabilities. I've raised that #define to 65536 on a 6.4-RELEASE i386 VM. > This made at least the mmap() method to map at 0x0 fail. FYI, changes are now going into head to implement this policy, although by slightly different mechanisms. I expect to see them merged to various branches, and also to active security branches (although disabled there by default using a sysctl so as not to disturb existing setups unless desired by the administrator). Robert > > So: > - How do you feel about disallowing such mappings to protect against > NULL-pointer deref code executions? > - Is bumping VM_MIN_ADDRESS enough to protect against all methods of > creating such mappings (on all supported platforms)? > - Are there unwanted side-effects of raising VM_MIN_ADDRESS? > - Should I file a PR to get this into FreeBSD? > > Lemme know, > Pieter > > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > From rwatson at freebsd.org Sun Sep 27 20:00:46 2009 From: rwatson at freebsd.org (Robert N. M. Watson) Date: Sun Sep 27 20:01:20 2009 Subject: Protecting against kernel NULL-pointer derefs In-Reply-To: <200909271904.NAA14681@lariat.net> References: <4AAF4A64.3080906@thedarkside.nl> <200909271904.NAA14681@lariat.net> Message-ID: <4C92C4D0-1224-4885-98D4-629F67AC6DBB@freebsd.org> On 27 Sep 2009, at 20:04, Brett Glass wrote: > As someone who has been frustrated by a disproportionate number of > bugs related to null and wild pointer dereferencing, I'd opt for > such an option to be incorporated in the next point release. > > Perhaps, there could be two options: one to generate a warning in > the log and then "fail soft" (e.g. by mapping a zero page) and > another to cause a hard panic. The "fail soft" option would be > particularly handy to help flush out bugs -- particularly in device > drivers -- in preparation for making a hard panic the default at > some future time. It would also provide a fallback for > administrators, to allow them to keep their systems running while a > bug was diagnosed and fixed. Right now the immediate goals are: (1) Enable by default in head so that we can evaluate the compatibility fallout (2) Provide the ability to enable on other -stable and -security branches non-default My guess is that we'll enable it in -stable (and hence point releases) fairly quickly, but it's not a switch we want to throw in -stable until we have a better understanding of the impact. We're also still working through the implementation details so I suspect more commits will follow. In practice, it will be tools like "doscmd" that fail in the new world order; some may not consider this a significant functional loss. We observe that Wine does do a mapping at NULL by default, but seems not to mind if it can't (as is also true on Linux I believe). Robert > > --Brett Glass > > At 12:39 PM 9/27/2009, Robert Watson wrote: > >> FYI, changes are now going into head to implement this policy, >> although by slightly different mechanisms. I expect to see them >> merged to various branches, and also to active security branches >> (although disabled there by default using a sysctl so as not to >> disturb existing setups unless desired by the administrator). >> >> Robert > From brett at lariat.net Sun Sep 27 19:43:21 2009 From: brett at lariat.net (Brett Glass) Date: Sun Sep 27 20:25:37 2009 Subject: Protecting against kernel NULL-pointer derefs In-Reply-To: References: <4AAF4A64.3080906@thedarkside.nl> Message-ID: <200909271904.NAA14681@lariat.net> As someone who has been frustrated by a disproportionate number of bugs related to null and wild pointer dereferencing, I'd opt for such an option to be incorporated in the next point release. Perhaps, there could be two options: one to generate a warning in the log and then "fail soft" (e.g. by mapping a zero page) and another to cause a hard panic. The "fail soft" option would be particularly handy to help flush out bugs -- particularly in device drivers -- in preparation for making a hard panic the default at some future time. It would also provide a fallback for administrators, to allow them to keep their systems running while a bug was diagnosed and fixed. --Brett Glass At 12:39 PM 9/27/2009, Robert Watson wrote: >FYI, changes are now going into head to implement this policy, >although by slightly different mechanisms. I expect to see them >merged to various branches, and also to active security branches >(although disabled there by default using a sysctl so as not to >disturb existing setups unless desired by the administrator). > >Robert From simon at FreeBSD.org Mon Sep 28 19:22:57 2009 From: simon at FreeBSD.org (Simon L. Nielsen) Date: Mon Sep 28 19:23:05 2009 Subject: FreeBSD bug grants local root access (FreeBSD 6.x) In-Reply-To: <200909251248.n8PCmJPY011925@lava.sentex.ca> References: <4AAF45B4.60307@isafeelin.org> <4AAF5999.7020501@delphij.net> <200909251248.n8PCmJPY011925@lava.sentex.ca> Message-ID: <20090928192256.GC2111@arthur.nitro.dk> On 2009.09.25 08:52:25 -0400, Mike Tancsa wrote: > At 05:08 AM 9/15/2009, Xin LI wrote: > >Frederique Rijsdijk wrote: > > > Hi, > > > > > > Any info on this subject on > > > > > > http://www.theregister.co.uk/2009/09/14/freebsd_security_bug/ > > > >Currently we (secteam@) are testing the correction patch and do > >peer-review on the security advisory draft, the bug was found and fixed > >on -HEAD and 7-STABLE before 7.1-RELEASE during some stress test but was > >not recognized as a security vulnerability at that time. The exploit > >code has to be executed locally, i.e. either by an untrusted local user, > >or be exploited in conjunction with some remote vulnerability on > >applications that allow the attacker to inject their own code. > > > >We can not release further details about the problem at this time, > >though, but I think we will likely to publish the advisory and > >correction patch this patch Wednesday. > > Just wondering if there is any update on this issue ? It turned out more difficult to fix than expected and we (secteam) didn't handle that as well as we should have, but I think we are almost there so the advisory should be out soon - sometime this week at the latest. Sorry about the delay - this should have been fixed by now. -- Simon L. Nielsen FreeBSD Deputy Security Officer From freebsd at optiksecurite.com Wed Sep 30 16:46:59 2009 From: freebsd at optiksecurite.com (Martin Turgeon) Date: Wed Sep 30 16:47:06 2009 Subject: Update on protection against slowloris Message-ID: <4AC37D6B.3060409@optiksecurite.com> Hi list! We tested mod_antiloris 0.4 and found it quite efficient, but before putting it in production, we would like to hear some feedback from freebsd users. We are using Apache 2.2.x on Freebsd 6.2 and 7.2. Is anyone using it? Do you have any other way to patch against Slowloris other than putting a proxy in front or using the HTTP accept filter? Thanks for your feedback, Martin