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

From EGIWiki
Jump to: navigation, search
Line 19: Line 19:
 
  + 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: Added a more robust systemtap mitigation, updated recommendation
 +
+ 2013-05-15: Removed sysctl mitigation
  
  
Line 64: Line 65:
 
==========
 
==========
  
There are currently three known mitigations for this issue:
+
The issue can be mitigated with the use of systemtap.  To implement
 +
the mitigation, perform the following steps.
  
1. A general remedy that will not break the kernel performance
+
1. Install the systemtap package (and its dependencies).  In
   measurement subsystem can be achieved with systemtapThis
+
  particular, the kernel-devel package matching the running kernel
   mitigation may be somewhat difficult to use because of its
+
   is requiredIf the matching version is not installed, systemtap
   dependencies.
+
   will give an error message asking for the correct package to be
 +
   installed.  Furthermore, the debuginfo package is necessary.
  
   Install the systemtap package and its dependencies, most
+
2. There are at least two ways systemtap can be used to address the
   notably the kernel-devel package, and create a file
+
   issue.  One of them, published by Red Hat, tries to maintain as
  /root/mitigation.stp containing the following (without the
+
  many performance monitoring capabilities as possible, at the
  BEGIN/END marker lines):
+
  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 96: Line 105:
 
---END FILE---
 
---END FILE---
  
   Then, compile into a .ko file with this command:
+
   b) To use LIU's mitigation, put the following into mitigation.stp:
    stap -g -p4 -m mitigation /root/mitigation.stp
+
---BEGIN FILE---
 +
#!/usr/bin/stap
  
  Load the systemtap module with this command:
+
# quick and ugly hack by cap@nsc.liu.se to block CVE-2013-2094
    staprun -L ./mitigation.ko
+
# 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
  
  The .ko file may be distributed and used on all machines that run
+
# screw up call by setting the attr_uptr pointer to null
  a kernel that is identical to the one on the host used to compile
+
probe kernel.function("sys_perf_event_open")
  the .ko file.
+
{
 +
  printf("hit sys_perf_event_open, DENIED! %s\n", $$vars);
 +
  $attr_uptr = 0
 +
}
  
  This fix is not persistent across reboots.
+
# 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)
 +
}
  
2. This mitigation is also systemtap-based.  However, unlike the
+
probe begin
  previous mitigation, this fix prevents kernel performance
+
{
  monitoring altogether.  It is also somewhat more robust in
+
  printf("Guru mode sys_perf_event_open blocker active\n");
  terms of deployment.
+
}
 +
---END FILE---
  
  Install the systemtap package and its dependencies, most
+
3. Compile into a .ko file with this command:
  notably the kernel-devel package, download
+
     stap -g -p4 -m mitigation mitigation.stp
    http://www.nsc.liu.se/~cap/perf_event_blocker.stp
 
  and compile this file into a .ko file with this command:
 
     stap -g -p4 -m perf_event_blocker perf_event_blocker.stp
 
  
  Load the systemtap module with this command:
+
4. Load the systemtap module with this command:
     staprun -L ./perf_event_blocker.ko
+
     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 also not persistent across reboots.
+
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.
  
3. A much easier mitigation that will only(!) prevent the published
+
This fix is not persistent across reboots.
  exploit code from working correctly can be performed by disabling
 
  user-level kernel profiling:
 
    sysctl kernel.perf_event_paranoid=2
 
  
  This fix is not persistent across reboots.  To make it persistent,
+
In previous releases of this advisory, a sysctl-based mitigation was
  add the line
+
also suggested.  This is no longer considered sufficient, as it only
    kernel.perf_event_paranoid=2
+
protects against a particular piece of exploit code, and this exploit
  to /etc/sysctl.conf.
+
can trivially be changed so that the mitigation no longer provides
 +
protection.
  
  
Line 150: Line 164:
  
 
It is recommended that sites implement one of the mitigations described above,
 
It is recommended that sites implement one of the mitigations described above,
preferably either one of the systemtap fixes, and upgrade their kernels as soon
+
and upgrade their kernels as soon as possible as they become available for their
as possible as they become available for their respective distributions.
+
respective distributions.
  
  

Revision as of 16:44, 15 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-15

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


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.


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.


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-3.8.8 through 3.8.9.
 + Linux kernels 2.6.32 with Red Hat backports.


Mitigation
==========

The issue can be mitigated with the use of systemtap.  To implement
the mitigation, 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
distro's information channels.


Recommendations
===============

It is recommended that sites implement one of the mitigations described above,
and upgrade their kernels as soon as possible as they become available for their
respective distributions.


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
 + Debian: https://security-tracker.debian.org/tracker/CVE-2013-2094
 + Red Hat: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2013-2094
 + Ubuntu: http://people.canonical.com/~ubuntu-security/cve/CVE-2013-2094
 + LIU SystemTap mitigation: http://www.nsc.liu.se/~cap/perf_event_blocker.stp