From: Solar Designer <solar@openwall.com> To: Vasiliy Kulikov <segoon@openwall.com> Cc: "H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, James Morris <jmorris@namei.org>, x86@kernel.org, kernel-hardening@lists.openwall.com, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org Subject: Re: [RFC] x86: restrict pid namespaces to 32 or 64 bit syscalls Date: Sun, 14 Aug 2011 13:09:00 +0400 [thread overview] Message-ID: <20110814090900.GA14293@openwall.com> (raw) In-Reply-To: <20110813163252.GA18458@albatros> On Sat, Aug 13, 2011 at 08:32:52PM +0400, Vasiliy Kulikov wrote: > I didn't say all IA-32 compatibility layer of x86 is a crap, surely no. > But there is some code, which is poorly tested exactly because it is > compatibility code. One relatively recent example: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3e645d6b485446c54c6745c5e2cf5c528fe4deec Here's another one: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3081 https://bugzilla.redhat.com/show_bug.cgi?id=634457 https://access.redhat.com/kb/docs/DOC-40265 "The compat_alloc_user_space functions in include/asm/compat.h files in the Linux kernel before 2.6.36-rc4-git2 on 64-bit platforms do not properly allocate the userspace memory required for the 32-bit compatibility layer, which allows local users to gain privileges by leveraging the ability of the compat_mc_getsockopt function (aka the MCAST_MSFILTER getsockopt support) to control a certain length value, related to a "stack pointer underflow" issue, as exploited in the wild in September 2010." It would have been nice if this one were not exploitable from 64-bit OpenVZ containers at the time, which, if I understand correctly, would be the case with Vasiliy's patch (and the corresponding change to vzctl to make use of the feature, which we're planning to make). Similarly, it would be nice if 32-bit compat issues like this would not be triggerable from privsep child processes of vsftpd, sshd, etc. - those programs would need to set a flag via prctl(), which we'll add support for. > I'll move the check to the tracesys branch, which is not a hot path, in > the next RFC version, so this should not be a problem. Vasiliy is going to reuse a check (of multiple flags at once) that is already in the code, so the change will have no performance impact for permitted and non-traced syscalls (the case where we care about performance). Alexander
WARNING: multiple messages have this Message-ID (diff)
From: Solar Designer <solar@openwall.com> To: Vasiliy Kulikov <segoon@openwall.com> Cc: "H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, James Morris <jmorris@namei.org>, x86@kernel.org, kernel-hardening@lists.openwall.com, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org Subject: [kernel-hardening] Re: [RFC] x86: restrict pid namespaces to 32 or 64 bit syscalls Date: Sun, 14 Aug 2011 13:09:00 +0400 [thread overview] Message-ID: <20110814090900.GA14293@openwall.com> (raw) In-Reply-To: <20110813163252.GA18458@albatros> On Sat, Aug 13, 2011 at 08:32:52PM +0400, Vasiliy Kulikov wrote: > I didn't say all IA-32 compatibility layer of x86 is a crap, surely no. > But there is some code, which is poorly tested exactly because it is > compatibility code. One relatively recent example: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3e645d6b485446c54c6745c5e2cf5c528fe4deec Here's another one: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3081 https://bugzilla.redhat.com/show_bug.cgi?id=634457 https://access.redhat.com/kb/docs/DOC-40265 "The compat_alloc_user_space functions in include/asm/compat.h files in the Linux kernel before 2.6.36-rc4-git2 on 64-bit platforms do not properly allocate the userspace memory required for the 32-bit compatibility layer, which allows local users to gain privileges by leveraging the ability of the compat_mc_getsockopt function (aka the MCAST_MSFILTER getsockopt support) to control a certain length value, related to a "stack pointer underflow" issue, as exploited in the wild in September 2010." It would have been nice if this one were not exploitable from 64-bit OpenVZ containers at the time, which, if I understand correctly, would be the case with Vasiliy's patch (and the corresponding change to vzctl to make use of the feature, which we're planning to make). Similarly, it would be nice if 32-bit compat issues like this would not be triggerable from privsep child processes of vsftpd, sshd, etc. - those programs would need to set a flag via prctl(), which we'll add support for. > I'll move the check to the tracesys branch, which is not a hot path, in > the next RFC version, so this should not be a problem. Vasiliy is going to reuse a check (of multiple flags at once) that is already in the code, so the change will have no performance impact for permitted and non-traced syscalls (the case where we care about performance). Alexander
next prev parent reply other threads:[~2011-08-14 9:09 UTC|newest] Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-08-12 15:03 [RFC] x86: restrict pid namespaces to 32 or 64 bit syscalls Vasiliy Kulikov 2011-08-12 15:03 ` [kernel-hardening] " Vasiliy Kulikov 2011-08-12 20:08 ` H. Peter Anvin 2011-08-12 20:08 ` [kernel-hardening] " H. Peter Anvin 2011-08-13 6:22 ` Vasiliy Kulikov 2011-08-13 6:22 ` [kernel-hardening] " Vasiliy Kulikov 2011-08-13 15:41 ` H. Peter Anvin 2011-08-13 15:41 ` [kernel-hardening] " H. Peter Anvin 2011-08-13 16:32 ` Vasiliy Kulikov 2011-08-14 9:09 ` Solar Designer [this message] 2011-08-14 9:09 ` Solar Designer 2011-08-18 14:40 ` [RFC v2] " Vasiliy Kulikov 2011-08-18 14:40 ` [kernel-hardening] " Vasiliy Kulikov 2011-08-14 2:38 ` [RFC] " Andi Kleen 2011-08-14 2:38 ` [kernel-hardening] " Andi Kleen 2011-08-14 5:08 ` H. Peter Anvin 2011-08-14 5:08 ` [kernel-hardening] " H. Peter Anvin 2011-08-14 9:20 ` Solar Designer 2011-08-14 9:20 ` [kernel-hardening] " Solar Designer 2011-08-14 14:48 ` H. Peter Anvin 2011-08-14 14:48 ` [kernel-hardening] " H. Peter Anvin 2011-08-14 15:27 ` Andi Kleen 2011-08-14 15:27 ` [kernel-hardening] " Andi Kleen 2011-08-14 15:36 ` H. Peter Anvin 2011-08-14 15:36 ` [kernel-hardening] " H. Peter Anvin 2011-08-14 23:29 ` James Morris 2011-08-14 23:29 ` [kernel-hardening] " James Morris 2011-08-15 0:18 ` Andi Kleen 2011-08-15 0:18 ` [kernel-hardening] " Andi Kleen 2011-08-15 0:32 ` Will Drewry 2011-08-15 0:58 ` Andi Kleen [not found] ` <20110814152729.GU5782-qrUzlfsMFqo/4alezvVtWx2eb7JE58TQ@public.gmane.org> 2011-08-14 16:08 ` Vasiliy Kulikov 2011-08-14 16:08 ` [kernel-hardening] " Vasiliy Kulikov 2011-08-14 16:08 ` Vasiliy Kulikov 2011-08-15 18:51 ` Solar Designer 2011-08-15 18:51 ` [kernel-hardening] " Solar Designer 2011-08-15 18:59 ` H. Peter Anvin 2011-08-15 18:59 ` [kernel-hardening] " H. Peter Anvin 2011-08-15 20:14 ` Solar Designer 2011-08-15 20:14 ` [kernel-hardening] " Solar Designer 2011-08-15 20:27 ` Andi Kleen 2011-08-15 20:27 ` [kernel-hardening] " Andi Kleen 2011-08-15 20:48 ` H. Peter Anvin 2011-08-15 20:48 ` [kernel-hardening] " H. Peter Anvin 2011-08-15 22:13 ` Eric Paris 2011-08-15 22:13 ` [kernel-hardening] " Eric Paris 2011-08-16 1:18 ` Andi Kleen 2011-08-16 1:18 ` [kernel-hardening] " Andi Kleen
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20110814090900.GA14293@openwall.com \ --to=solar@openwall.com \ --cc=hpa@zytor.com \ --cc=jmorris@namei.org \ --cc=kernel-hardening@lists.openwall.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=mingo@redhat.com \ --cc=segoon@openwall.com \ --cc=tglx@linutronix.de \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.