Use after free vulnerability in Linux kernel keychain management (CVE-2016-0728)

Red Hat has been made aware of a vulnerability affecting the kernel that ships with Red Hat Enterprise Linux 7 kernel and derivatives. CVE-2016-0728 documents and exploit that could allow a skilled attacker to execute arbitrary code and also be used to escalate their privileges on the system. The attacker must be able to run custom code on the account; in the most common configuration, this requires them to have a login and shell account on the target system.

Diagnostic Steps:

This issue was introduced in commit 3a50597de8635cd05133bd12c95681c82fe7b878 , which was introduced in the kernel version 3.10. All Red Hat Enterprise Linux kernels after this version are affected. This document has been updated with versions containing the fix.

To find out which kernel version a system is running consult https://access.redhat.com/articles/3078.

How to update the kernel

For details on how to apply this update, refer to this article

How does this impact systems:

Users must have an account on the system, or be able to instruct the system to run code on their behalf. The attack is not immediate and may take some time to run; the system shows key usage counts climbing and then eventually wrapping to negative. The below command displays the keys file with a usage count of 50076394, proving an attack is in process.

$ cat /proc/keys | grep TEST_KEY
01cca8cf I--Q--- 50076394 perm 3f3f3f3f     0     0 keyring   TEST_KEY: empty

If this attack is successful, no log events are generated when this faults.

I believe my system may have been compromised due to this vulnerability, what should I do?

If you have run the diagnostic steps in this article, and your system still appears to be vulnerable, or you believe your system has been compromised, open a support case with Red Hat or contact Red Hat support by phone.

Frequently Asked Questions

Q) What is a "Use after free" and how can it be exploited ?

A) The kernel uses reference counters to keep track of how many different parts of the code are using a certain kernel object. In this case, it would be a user created keyring object. When the counter is set to zero, the kernel knows that it can free the object. When the kernel attempts to acquire a keyring object, it uses a matching key_get() and when releasing uses a matching key_put() function call (when it has completed using the object).

The error in this vulnerability was failing to call the key_put() function when handling an error path. When the number of calls to acquire the key object do not match the release requests, it causes the integer value of counter to wrap around from maximum value to zero. When the condition of the counter being zero is met, the object is released but references to it in memory can still exist. This situation that makes a reference counter overflow equivalent to the well-known "use-after-free" bug class.

Other parts of the kernel are able to allocate this freed memory for use. By overwriting the correct memory locations with instructions, an attacker can use this previously freed memory space as the payload for when a function in this memory could be called. The payload in this circumstance is spawning a new shell with elevated privileges.

Q) Sites on the internet have mentioned that the exploit can be prevented with the command:

# echo 1 > /proc/sys/kernel/keys/maxkeys

A) This limit only applies to user-created keys, not keys created by root. Each user gets a session keyring via pam (as root) when logged in. At this time there is no work around.

Q) Is there an alternative mitigation till I can schedule a reboot ?

A) Frank Ch. Eigler created a systemtap workaround in Comment #13 of the vulnerability bug and comment #14. Please follow the instructions from the bugzilla comments.

Q) Do I have to reboot after installing the kernel update ?

A) Yes.

Q) Does SELinux mitigate this issue ?

A) No.

References:

Perception points analysis
Red Hat's Bugzilla on CVE-2016-0728
Red Hat's Security Vulnerability Response Site