Bug 1297475 - (CVE-2016-0728) CVE-2016-0728 kernel: Possible use-after-free vulnerability in keyring facility
CVE-2016-0728 kernel: Possible use-after-free vulnerability in keyring facility
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
high Severity high
: ---
: ---
Assigned To: Red Hat Product Security
impact=important,public=20160119,repo...
: Security
Depends On: 1296623 1298035 1298036 1298037 1298038 1298039 1298040 1298931
Blocks: 1297482
  Show dependency treegraph
 
Reported: 2016-01-11 10:42 EST by Adam Mariš
Modified: 2016-12-02 04:49 EST (History)
76 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
A use-after-free flaw was found in the way the Linux kernel's key management subsystem handled keyring object reference counting in certain error path of the join_session_keyring() function. A local, unprivileged user could use this flaw to escalate their privileges on the system.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-29 08:49:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
prototype systemtap band-aid mk. e (2.56 KB, text/plain)
2016-01-19 12:25 EST, Frank Ch. Eigler
no flags Details
Proposed patch (2.00 KB, text/plain)
2016-01-20 04:53 EST, Wade Mealing
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Article) 2131021 None None None 2016-01-24 20:52 EST
Red Hat Knowledge Base (Solution) 2130791 None None None 2016-01-19 20:12 EST

  None (edit)
Description Adam Mariš 2016-01-11 10:42:09 EST
It was reported that possible use-after-free vulnerability in keyring facility, possibly leading to local privilege escalation, was found. Function join_session_keyring in security/keys/process_keys.c holds a reference to the requested keyring, but if that keyring is the same as the one being currently used by the process, the kernel wouldn't decrease keyring->usage before returning to userspace. The usage field can be possibly overflowed causing use-after-free on the keyring object.

Introduced by:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3a50597de8635cd05133bd12c95681c82fe7b878

References:
http://perception-point.io/2016/01/14/analysis-and-exploitation-of-a-linux-kernel-vulnerability-cve-2016-0728/

Red Hat KCS article:
https://access.redhat.com/articles/2131021

Upstream patch:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=23567fd052a9abb6d67fe8e7a9ccdd9800a540f2
Comment 5 Wade Mealing 2016-01-12 23:49:43 EST
Acknowledgements:

Name: the Perception Point research team
Comment 6 Wade Mealing 2016-01-14 01:54:17 EST
Statement:

This issue does not affect the Linux kernels as shipped with Red Hat Enterprise Linux 5 and 6. 

Refer to https://access.redhat.com/node/2131021 for further information.
Comment 13 Frank Ch. Eigler 2016-01-19 12:25 EST
Created attachment 1116284 [details]
prototype systemtap band-aid mk. e

Further investigation with larger versions of the systemtap band-aid script suggest that the larger exploit manages somehow to increment the key refcount by 2 (!!) per iteration - one of which the stap band-aid does successfully roll back.

The smaller exploit increments it by 1 per iteration, so after the band-aid application, the visible /proc/keys refcount stays static.
Comment 15 Frank Ch. Eigler 2016-01-19 14:52:32 EST
Further experiments with the systemtap band-aid from comment #13 indicate:

- fedora22 4.2.6-200.fc22.x86_64: stap band-aid works for both exploits
  (refcounts on /proc/keys fluctuates up & down during big exploit, within
  reasonable O(10000) ranges, then keyring is gc'd at exploit interrupt)

- git linux + patch, no stap band-aid: identical behaviour

- rhel7 3.10.0-327.4.4.el7.x86_64: stap band-aid works for both exploits,
  identical behaviour

I can't explain my previous observations in comment #11; am suspecting
that the rhel7 VM being tested was already subtly corrupted during prior
testing.  The new results are post-reboot.

So, this appears to provide protection:

# debuginfo-install kernel     (or equivalent)
# stap -vgt -Gfix_p=1 -Gtrace_p=0 cve20160728e.stp
Comment 17 Wade Mealing 2016-01-20 04:53 EST
Created attachment 1116563 [details]
Proposed patch
Comment 24 Vincent Danen 2016-01-21 11:50:53 EST
External References:

https://access.redhat.com/node/2131021
Comment 25 errata-xmlrpc 2016-01-25 14:14:19 EST
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2016:0065 https://rhn.redhat.com/errata/RHSA-2016-0065.html
Comment 26 errata-xmlrpc 2016-01-25 14:28:23 EST
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2016:0064 https://rhn.redhat.com/errata/RHSA-2016-0064.html
Comment 29 errata-xmlrpc 2016-01-26 09:00:38 EST
This issue has been addressed in the following products:

  MRG for RHEL-6 v.2

Via RHSA-2016:0068 https://rhn.redhat.com/errata/RHSA-2016-0068.html
Comment 30 Fedora Update System 2016-01-26 13:22:11 EST
kernel-4.3.3-303.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Comment 31 Fedora Update System 2016-02-01 01:25:09 EST
kernel-4.3.4-200.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
Comment 32 errata-xmlrpc 2016-02-02 12:03:15 EST
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7.1 EUS - Server and Compute Node Only

Via RHSA-2016:0103 https://rhn.redhat.com/errata/RHSA-2016-0103.html

Note You need to log in before you can comment on or make changes to this bug.