From patchwork Fri Feb 15 15:02:59 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Henriques X-Patchwork-Id: 220757 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from chlorine.canonical.com (chlorine.canonical.com [91.189.94.204]) by ozlabs.org (Postfix) with ESMTP id 61A402C007A for ; Sat, 16 Feb 2013 02:03:13 +1100 (EST) Received: from localhost ([127.0.0.1] helo=chlorine.canonical.com) by chlorine.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1U6MoZ-0000xk-0X; Fri, 15 Feb 2013 15:03:03 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by chlorine.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1U6MoW-0000xf-Ke for kernel-team@lists.ubuntu.com; Fri, 15 Feb 2013 15:03:00 +0000 Received: from bl15-100-125.dsl.telepac.pt ([188.80.100.125] helo=localhost) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1U6MoW-00082j-Br for kernel-team@lists.ubuntu.com; Fri, 15 Feb 2013 15:03:00 +0000 From: Luis Henriques To: kernel-team@lists.ubuntu.com Subject: [Lucid CVE-2013-0268] x86/msr: Add capabilities check Date: Fri, 15 Feb 2013 15:02:59 +0000 Message-Id: <1360940579-30417-1-git-send-email-luis.henriques@canonical.com> X-Mailer: git-send-email 1.8.1.2 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.13 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: kernel-team-bounces@lists.ubuntu.com Errors-To: kernel-team-bounces@lists.ubuntu.com From: Alan Cox CVE-2013-0268 BugLink: http://bugs.launchpad.net/bugs/1123049 At the moment the MSR driver only relies upon file system checks. This means that anything as root with any capability set can write to MSRs. Historically that wasn't very interesting but on modern processors the MSRs are such that writing to them provides several ways to execute arbitary code in kernel space. Sample code and documentation on doing this is circulating and MSR attacks are used on Windows 64bit rootkits already. In the Linux case you still need to be able to open the device file so the impact is fairly limited and reduces the security of some capability and security model based systems down towards that of a generic "root owns the box" setup. Therefore they should require CAP_SYS_RAWIO to prevent an elevation of capabilities. The impact of this is fairly minimal on most setups because they don't have heavy use of capabilities. Those using SELinux, SMACK or AppArmor rules might want to consider if their rulesets on the MSR driver could be tighter. Signed-off-by: Alan Cox Cc: Linus Torvalds Cc: Andrew Morton Cc: Peter Zijlstra Cc: Horses Signed-off-by: Ingo Molnar (cherry picked from commit c903f0456bc69176912dee6dd25c6a66ee1aed00) Conflicts: arch/x86/kernel/msr.c Signed-off-by: Luis Henriques Acked-by: Leann Ogasawara --- arch/x86/kernel/msr.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c index 5eaeb5e..63a053b 100644 --- a/arch/x86/kernel/msr.c +++ b/arch/x86/kernel/msr.c @@ -176,6 +176,9 @@ static int msr_open(struct inode *inode, struct file *file) struct cpuinfo_x86 *c = &cpu_data(cpu); int ret = 0; + if (!capable(CAP_SYS_RAWIO)) + return -EPERM; + lock_kernel(); cpu = iminor(file->f_path.dentry->d_inode);