Difference between revisions of "EGI CSIRT:Alerts/kernel-2013-05-14"

From EGIWiki
Jump to: navigation, search
 
(22 intermediate revisions by 4 users not shown)
Line 7: Line 7:
 
Title:      Linux kernel perf_event vulnerability (CVE-2013-2094) [EGI-ADV-20130514]
 
Title:      Linux kernel perf_event vulnerability (CVE-2013-2094) [EGI-ADV-20130514]
 
Date:        2013-05-14
 
Date:        2013-05-14
Updated:    2013-05-15
+
Updated:    2013-05-20
  
 
URL:        https://wiki.egi.eu/wiki/EGI_CSIRT:Alerts/kernel-2013-05-14
 
URL:        https://wiki.egi.eu/wiki/EGI_CSIRT:Alerts/kernel-2013-05-14
Line 18: Line 18:
 
  + 2013-05-15: Made mitigation drawbacks more explicit.
 
  + 2013-05-15: Made mitigation drawbacks more explicit.
 
  + 2013-05-15: Revised systemtap mitigation to support v1.7
 
  + 2013-05-15: Revised systemtap mitigation to support v1.7
 +
+ 2013-05-15: Added a more robust systemtap mitigation, updated recommendation
 +
+ 2013-05-15: Removed sysctl mitigation
 +
+ 2013-05-16: Fixed typo in kernel version in section "Affected Software"
 +
+ 2013-05-16: Added pointer to CERN's RPM repo for mitigation package
 +
+ 2013-05-16: Added pointer to Red Hat's Security Advisory
 +
+ 2013-05-16: Added pointer to Scientific Linux Advisory
 +
+ 2013-05-17: Added pointer to Scientific Linux/CERN Advisory
 +
+ 2013-05-17: Added pointer to CentOS Advisory
 +
+ 2013-05-20: Added pointer to SUSE Advisory, replaced recommendations with required actions
 +
+ 2013-05-21: Clarified that RHEL6 and derivatives are affected, not RHEL5
  
  
Line 26: Line 36:
 
to escalate their privilege level and gain root access.  Working exploit code
 
to escalate their privilege level and gain root access.  Working exploit code
 
is publicly available.
 
is publicly available.
 +
All relevant Linux distributions have already published an updated kernel
 +
which fixes this vulnerability.
 +
 +
Note that RHEL6 and it's derivatives are affected by this vulnerability,
 +
RHEL5 and its derivatives are not affected.
 +
 +
 +
Required Actions
 +
================
 +
 +
All running EGI resources MUST be either patched or otherwise have a
 +
work-around in place by 2013-05-27 T21:00+01:00.  EGI sites failing to act and/or
 +
failing respond to requests from the EGI CSIRT team risk site suspension.
  
  
Line 44: Line 67:
 
vulnerable distributions; however, it appears to work on RHEL 6 and derived
 
vulnerable distributions; however, it appears to work on RHEL 6 and derived
 
systems.
 
systems.
 +
 +
The issue has been addressed by CentOS, Debian, Red Hat, Scientific Linux,
 +
Scientific Linux/CERN and Ubuntu.  As per standard EGI procedures, as patches
 +
are widely available at this time, and this issue has been assessed as CRITICAL
 +
by EGI CSIRT, sites must have rolled out the proper patches within 7 days.
 +
As widespread attacks are currently being carried out with this vulnerability,
 +
sites should take action urgently.
  
  
Line 56: Line 86:
 
=================
 
=================
  
  + Linux kernels 2.6.36-3.8.8 through 3.8.9.
+
  + Linux kernels 2.6.36 through 3.8.8 (both including).
 
  + Linux kernels 2.6.32 with Red Hat backports.
 
  + Linux kernels 2.6.32 with Red Hat backports.
  
Line 63: Line 93:
 
==========
 
==========
  
To mitigate the issue, install the systemtap package and create a
+
The issue can be mitigated with the use of systemtap.  CERN has
file /root/mitigation.stp containing the following (without the
+
provided an RPM package that implements systemtap mitigation as
BEGIN/END marker lines):
+
described below for kernel versions
 +
+ 2.6.32-358.0.1.el6
 +
+ 2.6.32-358.2.1.el6
 +
+ 2.6.32-358.6.1.el6.
 +
The RPM packages for 32-bit and 64-bit kernels are available at:
 +
+ 32-bit: http://linuxsoft.cern.ch/cern/updates/slc6X/i386/RPMS/cve_2013_2094-0.2-1.el6.i686.rpm
 +
+ 64-bit: http://linuxsoft.cern.ch/cern/updates/slc6X/x86_64/RPMS/cve_2013_2094-0.2-1.el6.x86_64.rpm
 +
To put the mitigation in place, download and install the proper
 +
package; this implementation is stable across reboots.
 +
 
 +
To implement the mitigation manually, perform the following steps.
 +
 
 +
1. Install the systemtap package (and its dependencies).  In
 +
  particular, the kernel-devel package matching the running kernel
 +
  is required.  If the matching version is not installed, systemtap
 +
  will give an error message asking for the correct package to be
 +
  installed.  Furthermore, the debuginfo package is necessary.
 +
 
 +
2. There are at least two ways systemtap can be used to address the
 +
  issue.  One of them, published by Red Hat, tries to maintain as
 +
  many performance monitoring capabilities as possible, at the
 +
  expense of more intricate compilation and deployment dependencies,
 +
  as far as systemtap versions used are concerned.  The other fix
 +
  has been provided by Linköping University and disables performance
 +
  monitoring altogether, but is more resilient.
 +
 
 +
  a) To use Red Hat's mitigation, create a file mitigation.stp
 +
      containing the following (without the BEGIN/END marker lines):
 
---BEGIN FILE---
 
---BEGIN FILE---
 
%{
 
%{
Line 87: Line 144:
 
---END FILE---
 
---END FILE---
  
Then, run the command
+
  b) To use LIU's mitigation, put the following into mitigation.stp:
  stap -g /root/mitigation.stp
+
---BEGIN FILE---
 +
#!/usr/bin/stap
  
Note that this needs to be re-run after every reboot.
+
# quick and ugly hack by cap@nsc.liu.se to block CVE-2013-2094
 +
# must run in guru mode (-g)
 +
# compile to .ko file: "stap -g -m perf_event_blocker perf_event_blocker.stp
 +
# run on non build host using "staprun [-L] ./perf_event_blocker.ko"
 +
# requires build host and staprun to have identical kernel
  
A much easier mitigation that will only(!) prevent the published exploit
+
# screw up call by setting the attr_uptr pointer to null
code from working correctly can be performed by disabling user-level
+
probe kernel.function("sys_perf_event_open")
kernel profiling:
+
{
   sysctl kernel.perf_event_paranoid=2
+
  printf("hit sys_perf_event_open, DENIED! %s\n", $$vars);
 +
   $attr_uptr = 0
 +
}
  
This is also not persistent across reboots, so it is necessary either to
+
# print out return value to verify that the syscall was screwed up
re-run the command after each boot or to add the line
+
probe kernel.function("sys_perf_event_open").return
  kernel.perf_event_paranoid=2
+
{
to /etc/sysctl.conf.
+
  printf("returning from sys_perf_event_open with: %i\n", $return)
 +
}
 +
 
 +
probe begin
 +
{
 +
  printf("Guru mode sys_perf_event_open blocker active\n");
 +
}
 +
---END FILE---
 +
 
 +
3. Compile into a .ko file with this command:
 +
    stap -g -p4 -m mitigation mitigation.stp
 +
 
 +
4. Load the systemtap module with this command:
 +
    staprun -L ./mitigation.ko
 +
 
 +
The .ko file may be distributed and used on all machines that run
 +
a kernel that is identical to the one on the host used to compile
 +
the .ko file.
 +
 
 +
This fix is not persistent across reboots.
 +
 
 +
In previous releases of this advisory, a sysctl-based mitigation was
 +
also suggested. This is no longer considered sufficient, as it only
 +
protects against a particular piece of exploit code, and this exploit
 +
can trivially be changed so that the mitigation no longer provides
 +
protection.
  
Both mitigations are discussed in more detail at
 
  https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2013-2094
 
  
 
Component Installation information
 
Component Installation information
Line 109: Line 196:
  
 
For many distributions, patched kernel packages are available.  Refer to your
 
For many distributions, patched kernel packages are available.  Refer to your
distro's information channels.
+
distribution's information channels.
 
 
 
 
Recommendations
 
===============
 
 
 
It is recommended that sites implement the mitigation described above unless
 
kernel profiling is essential and upgrade their kernels as soon as possible
 
as they become available for their respective distributions.
 
  
  
Line 126: Line 205:
 
  + NIST NVD: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-2094
 
  + NIST NVD: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-2094
 
  + OSS-Sec: http://marc.info/?s=CVE-2013-2094&l=oss-security
 
  + OSS-Sec: http://marc.info/?s=CVE-2013-2094&l=oss-security
 +
+ CentOS: http://lists.centos.org/pipermail/centos-announce/2013-May/019733.html
 
  + Debian: https://security-tracker.debian.org/tracker/CVE-2013-2094
 
  + Debian: https://security-tracker.debian.org/tracker/CVE-2013-2094
 
  + Red Hat: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2013-2094
 
  + Red Hat: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2013-2094
 +
+ RHSA: https://rhn.redhat.com/errata/RHSA-2013-0830.html
 +
+ SL: http://listserv.fnal.gov/scripts/wa.exe?A2=ind1305&L=scientific-linux-errata&T=0&P=1321
 +
+ SLC: http://linux.web.cern.ch/linux/updates/updates-slc6.shtml
 
  + Ubuntu: http://people.canonical.com/~ubuntu-security/cve/CVE-2013-2094
 
  + Ubuntu: http://people.canonical.com/~ubuntu-security/cve/CVE-2013-2094
 +
+ CERN 32-bit RPM: http://linuxsoft.cern.ch/cern/updates/slc6X/i386/RPMS/cve_2013_2094-0.2-1.el6.i686.rpm
 +
+ CERN 64-bit RPM: http://linuxsoft.cern.ch/cern/updates/slc6X/x86_64/RPMS/cve_2013_2094-0.2-1.el6.x86_64.rpm
 +
+ CERN SRPM: http://linuxsoft.cern.ch/cern/updates/slc6X/SRPMS/cve_2013_2094-0.2-1.el6.src.rpm
 +
+ LIU SystemTap mitigation: http://www.nsc.liu.se/~cap/perf_event_blocker.stp
 +
+ SUSE: http://support.novell.com/security/cve/CVE-2013-2094.html
 
</pre>
 
</pre>

Latest revision as of 12:29, 21 May 2013

** WHITE information - Unlimited distribution allowed                       **
** see https://wiki.egi.eu/wiki/EGI_CSIRT:TLP for distribution restrictions **

EGI CSIRT ADVISORY [EGI-ADV-20130514]

Title:       Linux kernel perf_event vulnerability (CVE-2013-2094) [EGI-ADV-20130514]
Date:        2013-05-14
Updated:     2013-05-20

URL:         https://wiki.egi.eu/wiki/EGI_CSIRT:Alerts/kernel-2013-05-14


Update Summary
==============

 + 2013-05-14: Initial revision.
 + 2013-05-15: Made mitigation drawbacks more explicit.
 + 2013-05-15: Revised systemtap mitigation to support v1.7
 + 2013-05-15: Added a more robust systemtap mitigation, updated recommendation
 + 2013-05-15: Removed sysctl mitigation
 + 2013-05-16: Fixed typo in kernel version in section "Affected Software"
 + 2013-05-16: Added pointer to CERN's RPM repo for mitigation package
 + 2013-05-16: Added pointer to Red Hat's Security Advisory
 + 2013-05-16: Added pointer to Scientific Linux Advisory
 + 2013-05-17: Added pointer to Scientific Linux/CERN Advisory
 + 2013-05-17: Added pointer to CentOS Advisory
 + 2013-05-20: Added pointer to SUSE Advisory, replaced recommendations with required actions
 + 2013-05-21: Clarified that RHEL6 and derivatives are affected, not RHEL5


Introduction
============

A recently-discovered vulnerability in the Linux kernel allows a local user
to escalate their privilege level and gain root access.  Working exploit code
is publicly available.
All relevant Linux distributions have already published an updated kernel
which fixes this vulnerability.

Note that RHEL6 and it's derivatives are affected by this vulnerability,
RHEL5 and its derivatives are not affected. 


Required Actions
================

All running EGI resources MUST be either patched or otherwise have a
work-around in place by 2013-05-27 T21:00+01:00.  EGI sites failing to act and/or 
failing respond to requests from the EGI CSIRT team risk site suspension.


Details
=======

The performance measurement subsystem in the Linux kernel incorrectly casts a
64-bit integer into a 32-bit integer which is subsequently used for array
dereferencing.  Providing carefully chosen integers as input allows arbitrary
code to be executed.

The erroneous code has been introduced in kernel version 2.6.37 (commit
b0a873ebbf87bf38bf70b5e39a7cadc96099fa13 on 2010-09-09) and is fixed in kernel
version 3.8.9 (commit 8176cced706b5e5d15887584150764894e94e02f on 2013-04-15).
Additionally, the vulnerability was backported to 2.6.32 kernels by Red Hat.

Working exploit code is publicly available.  This code will not work on all
vulnerable distributions; however, it appears to work on RHEL 6 and derived
systems.

The issue has been addressed by CentOS, Debian, Red Hat, Scientific Linux,
Scientific Linux/CERN and Ubuntu.  As per standard EGI procedures, as patches
are widely available at this time, and this issue has been assessed as CRITICAL
by EGI CSIRT, sites must have rolled out the proper patches within 7 days.
As widespread attacks are currently being carried out with this vulnerability,
sites should take action urgently.


Risk Category
=============

This issue has been assessed as CRITICAL risk by the EGI CSIRT as a working
exploit is publicly available.


Affected Software
=================

 + Linux kernels 2.6.36 through 3.8.8 (both including).
 + Linux kernels 2.6.32 with Red Hat backports.


Mitigation
==========

The issue can be mitigated with the use of systemtap.  CERN has
provided an RPM package that implements systemtap mitigation as
described below for kernel versions
 + 2.6.32-358.0.1.el6
 + 2.6.32-358.2.1.el6
 + 2.6.32-358.6.1.el6.
The RPM packages for 32-bit and 64-bit kernels are available at:
 + 32-bit: http://linuxsoft.cern.ch/cern/updates/slc6X/i386/RPMS/cve_2013_2094-0.2-1.el6.i686.rpm
 + 64-bit: http://linuxsoft.cern.ch/cern/updates/slc6X/x86_64/RPMS/cve_2013_2094-0.2-1.el6.x86_64.rpm
To put the mitigation in place, download and install the proper
package; this implementation is stable across reboots.

To implement the mitigation manually, perform the following steps.

1. Install the systemtap package (and its dependencies).  In
   particular, the kernel-devel package matching the running kernel
   is required.  If the matching version is not installed, systemtap
   will give an error message asking for the correct package to be
   installed.  Furthermore, the debuginfo package is necessary.

2. There are at least two ways systemtap can be used to address the
   issue.  One of them, published by Red Hat, tries to maintain as
   many performance monitoring capabilities as possible, at the
   expense of more intricate compilation and deployment dependencies,
   as far as systemtap versions used are concerned.  The other fix
   has been provided by Linköping University and disables performance
   monitoring altogether, but is more resilient.

   a) To use Red Hat's mitigation, create a file mitigation.stp
      containing the following (without the BEGIN/END marker lines):
---BEGIN FILE---
%{
#include <linux/perf_event.h>
%}

function sanitize_config:long (event:long) %{
        struct perf_event *event;

#if STAP_COMPAT_VERSION >= STAP_VERSION(1,8)
        event = (struct perf_event *) STAP_ARG_event;
#else
        event = (struct perf_event *) THIS->event;
#endif
        event->attr.config &= INT_MAX;
%}

probe kernel.function("perf_swevent_init@kernel/events/core.c").call {
        sanitize_config($event);
}
---END FILE---

   b) To use LIU's mitigation, put the following into mitigation.stp:
---BEGIN FILE---
#!/usr/bin/stap

# quick and ugly hack by cap@nsc.liu.se to block CVE-2013-2094
# must run in guru mode (-g)
# compile to .ko file: "stap -g -m perf_event_blocker perf_event_blocker.stp
# run on non build host using "staprun [-L] ./perf_event_blocker.ko"
# requires build host and staprun to have identical kernel

# screw up call by setting the attr_uptr pointer to null
probe kernel.function("sys_perf_event_open")
{
  printf("hit sys_perf_event_open, DENIED! %s\n", $$vars);
  $attr_uptr = 0
}

# print out return value to verify that the syscall was screwed up
probe kernel.function("sys_perf_event_open").return
{
  printf("returning from sys_perf_event_open with: %i\n", $return)
}

probe begin
{
  printf("Guru mode sys_perf_event_open blocker active\n");
}
---END FILE---

3. Compile into a .ko file with this command:
     stap -g -p4 -m mitigation mitigation.stp

4. Load the systemtap module with this command:
     staprun -L ./mitigation.ko

The .ko file may be distributed and used on all machines that run
a kernel that is identical to the one on the host used to compile
the .ko file.

This fix is not persistent across reboots.

In previous releases of this advisory, a sysctl-based mitigation was
also suggested.  This is no longer considered sufficient, as it only
protects against a particular piece of exploit code, and this exploit
can trivially be changed so that the mitigation no longer provides
protection.


Component Installation information
==================================

For many distributions, patched kernel packages are available.  Refer to your
distribution's information channels.


References
==========

 + Mitre: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2094
 + NIST NVD: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-2094
 + OSS-Sec: http://marc.info/?s=CVE-2013-2094&l=oss-security
 + CentOS: http://lists.centos.org/pipermail/centos-announce/2013-May/019733.html
 + Debian: https://security-tracker.debian.org/tracker/CVE-2013-2094
 + Red Hat: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2013-2094
 + RHSA: https://rhn.redhat.com/errata/RHSA-2013-0830.html
 + SL: http://listserv.fnal.gov/scripts/wa.exe?A2=ind1305&L=scientific-linux-errata&T=0&P=1321
 + SLC: http://linux.web.cern.ch/linux/updates/updates-slc6.shtml
 + Ubuntu: http://people.canonical.com/~ubuntu-security/cve/CVE-2013-2094
 + CERN 32-bit RPM: http://linuxsoft.cern.ch/cern/updates/slc6X/i386/RPMS/cve_2013_2094-0.2-1.el6.i686.rpm
 + CERN 64-bit RPM: http://linuxsoft.cern.ch/cern/updates/slc6X/x86_64/RPMS/cve_2013_2094-0.2-1.el6.x86_64.rpm
 + CERN SRPM: http://linuxsoft.cern.ch/cern/updates/slc6X/SRPMS/cve_2013_2094-0.2-1.el6.src.rpm
 + LIU SystemTap mitigation: http://www.nsc.liu.se/~cap/perf_event_blocker.stp
 + SUSE: http://support.novell.com/security/cve/CVE-2013-2094.html