Skip to navigation

Warning message

log in to add comments or rate this document

Does CVE-2013-2094 affect Red Hat Enterprise Linux and Red Hat Enterprise MRG?

Updated 2014-01-08T14:20:49+00:00

Issue

The flaw identified by CVE-2013-2094 (Red Hat Bugzilla 962792) describes an issue where a user-supplied index into an array in the Linux kernel's Performance Events implementation is not validated properly, resulting in out-of-bounds kernel memory access. A local, unprivileged user could use this flaw to escalate their privileges.

A public exploit that affects Red Hat Enterprise Linux 6 and Red Hat Enterprise MRG 2 is available.

Environment

  • Red Hat Enterprise Linux 6, both 32-bit and 64-bit (specifically, versions 6.1, 6.2, 6.3, and 6.4. 6.0 is not affected)
  • Red Hat Enterprise MRG Realtime 2

Resolution

Red Hat Enterprise Linux 4 and 5

This issue does not affect the kernel packages as shipped with Red Hat Enterprise Linux 4 and 5 because we did not backport upstream commit b0a873eb that introduced this issue.

Red Hat Enterprise Linux 6 and Red Hat Enterprise MRG 2

Red Hat Enterprise Linux 6 and Red Hat Enterprise MRG 2 are affected by the publicly-circulated exploit. Updates to correct this issue are available below. Customers are advised to apply them now.

If update is not possible, the SystemTap script provided below can mitigate this issue on both Red Hat Enterprise Linux 6 and Red Hat Enterprise MRG 2 until updates are applied:

1) On the host, save the following SystemTap script in a file with the .stp extension:

%{
#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 *) (unsigned long) STAP_ARG_event;
#else
        event = (struct perf_event *) (unsigned long) THIS->event;
#endif
        event->attr.config &= INT_MAX;
%}

probe kernel.function("perf_swevent_init").call {
        sanitize_config($event);
}

2) Install the systemtap package and any required dependencies. Refer to the "2. Using SystemTap" chapter in the Red Hat Enterprise Linux 6 "SystemTap Beginners Guide" document, available from access.redhat.com/docs/ for information on installing the required -debuginfo packages.

3) Run the stap -g [filename-from-step-1].stp command as root. Note that it displays nothing and does not return.

If the host is rebooted, the changes will be lost and the script must be run again.

For those who want to compile the SystemTap script on a development machine and deploy the compiled kernel module to other machines, you may choose to explore https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/SystemTap_Beginners_Guide/cross-compiling.html. This is useful if the other machines have systemtap-runtime only, and lack a compiler or the required -debuginfo packages.

Note that while setting the sysctl kernel.perf_event_paranoid variable to 2 (by running the sysctl -w kernel.perf_event_paranoid=2 command as root) prevents the publicly-circulated exploit from working, it does not mitigate the issue itself. It is trivial to modify the public exploit so that it continues to work even on systems with kernel.perf_event_paranoid set to 2.

Root Cause

The CVE-2013-2094 issue was caused by upstream git commit b0a873eb, which introduced an integer conversion issue rendering the validation of the user-supplied index insufficient.

Diagnostic Steps

In some cases it may be possible to detect if the original unmodified "semtex" CVE-2013-2094 public exploit has been run on Red Hat Enterprise Linux 6 or Red Hat Enterprise MRG 2 (on Intel 64 and AMD64 architectures):

1) On the host, save the following in a file with the .stp extension:

global PSE_ADDR=0

probe begin {

        printf("--------------------------------------------------------------------------\n");

        if ((kernel_int(PSE_ADDR-4) != 0) || (kernel_int(PSE_ADDR-8) != 0)) {
                printf("%lx -- %x, %lx -- %x\n", PSE_ADDR-4, kernel_int(PSE_ADDR-4), PSE_ADDR-8, kernel_int(PSE_ADDR-8));

                if (kernel_int(PSE_ADDR-4) == kernel_int(PSE_ADDR-8))
                        printf("CVE-2013-2094 semtex local privilege escalation exploit residue detected!\n");
                else
                        printf("CVE-2013-2094 relevant suspicious value combination detected.\n");

        } else
                printf("CVE-2013-2094 semtex local privilege escalation exploit residue NOT detected!\n");

        printf("--------------------------------------------------------------------------\n");

        exit();
}

2) Install the systemtap package and any required dependencies. Refer to the "2. Using SystemTap" chapter in the Red Hat Enterprise Linux 6 "SystemTap Beginners Guide" document, available from access.redhat.com/docs/, for information on installing the required packages.

3) Run the following command as root:

stap [filename-from-step-1].stp -G PSE_ADDR=0x`grep perf_swevent_enabled /proc/kallsyms | awk '{print $1}'`

4) See the message printed.

Please note that when the script does not detect the "semtex" exploit residue it does not mean the server is/was not hacked. It just means that the unmodified original public exploit was not run on this server (or something went wrong). Considering that most of the exploits used in the wild now will be either based on or are the same as the original public "semtex" exploit, this script can be used to at least give a clue as to whether the original unmodified "semtex" exploit was exercised on the system.

Also please note that it is trivial to modify the exploit to cleanup after the exploitation and as such, this detection script cannot be used as a proof that the server was not hacked.

If you require assistance with mitigating this issue, please contact Red Hat Support: https://access.redhat.com/support/contact/technicalSupport.html.

Revision History

Updated 16th May 2013: This article has been updated to remove references to Red Hat Enterprise Linux 4 and 5 from the Environment section (both products are not affected by CVE-2013-2094); to clarify in the Environment section that both 32-bit and 64-bit versions of Red Hat Enterprise Linux 6 are affected; and to correct the SystemTap script in the Resolution section. Previously, this script did not run on older versions such as Red Hat Enterprise Linux 6.1.

Updated 16th May 2013: This article has been updated to reflect the release of the Red Hat Security Advisory RHSA-2013:0830, which addresses this issue in Red Hat Enterprise Linux 6.

Updated 18th May 2013: This article has been updated to reflect the release of the Red Hat Security Advisory RHSA-2013:0832, which addresses this issue in Red Hat Enterprise Linux 6.3 Extended Update Support.

Updated 21st May 2013: This article has been updated to reflect the release of Red Hat Security Advisories RHSA-2013:0841, RHSA-2013:0840, and RHSA-2013:0829, released on 20th May 2013, which address this issue in Red Hat Enterprise Linux 6.1 and 6.2 Extended Update Support, and Red Hat Enterprise MRG 2, respectively.