Fix local privilege escalation in MSR code (rhbz 908693 908706)

This commit is contained in:
Josh Boyer 2013-02-07 07:49:44 -05:00
parent a3dd486e63
commit e0b1d41f1c
2 changed files with 64 additions and 1 deletions

View File

@ -54,7 +54,7 @@ Summary: The Linux kernel
# For non-released -rc kernels, this will be appended after the rcX and
# gitX tags, so a 3 here would become part of release "0.rcX.gitX.3"
#
%global baserelease 6
%global baserelease 7
%global fedora_build %{baserelease}
# base_sublevel is the kernel version we're starting with and patching
@ -748,6 +748,9 @@ Patch21245: ext4-set-bg_itable_unused-when-resizing.patch
#rhbz 896051 896038 CVE-2013-0190
Patch21250: xen-fix-stack-corruption-in-xen_failsafe_callback.patch
#rhbz 908693 908706
Patch21251: x86-msr-Add-capabilities-check.patch
# END OF PATCH DEFINITIONS
%endif
@ -1415,6 +1418,9 @@ ApplyPatch ext4-set-bg_itable_unused-when-resizing.patch
#rhbz 896051 896038 CVE-2013-0190
ApplyPatch xen-fix-stack-corruption-in-xen_failsafe_callback.patch
#rhbz 908693 908706
ApplyPatch x86-msr-Add-capabilities-check.patch
# END OF PATCH APPLICATIONS
%endif
@ -2115,6 +2121,9 @@ fi
# and build.
%changelog
* Thu Feb 07 2013 Josh Boyer <jwboyer@redhat.com>
- Fix local privilege escalation in MSR code (rhbz 908693 908706)
* Wed Jan 23 2013 Dave Jones <davej@redhat.com>
- Remove warning about empty IPI mask.

View File

@ -0,0 +1,54 @@
From b9f93c7550b62939f250fad55b111637b0f66bc8 Mon Sep 17 00:00:00 2001
From: Alan Cox <alan@linux.intel.com>
Date: Thu, 15 Nov 2012 13:06:22 +0000
Subject: [PATCH] x86/msr: Add capabilities check
commit c903f0456bc69176912dee6dd25c6a66ee1aed00 upstream.
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 <alan@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
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 a7c5661..4929502 100644
--- a/arch/x86/kernel/msr.c
+++ b/arch/x86/kernel/msr.c
@@ -174,6 +174,9 @@ static int msr_open(struct inode *inode, struct file *file)
unsigned int cpu;
struct cpuinfo_x86 *c;
+ if (!capable(CAP_SYS_RAWIO))
+ return -EPERM;
+
cpu = iminor(file->f_path.dentry->d_inode);
if (cpu >= nr_cpu_ids || !cpu_online(cpu))
return -ENXIO; /* No such CPU */
--
1.8.1