|Summary:||CVE-2016-0728 kernel: Possible use-after-free vulnerability in keyring facility|
|Product:||[Other] Security Response||Reporter:||Adam Mariš <amaris>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||CLOSED ERRATA||QA Contact:|
|Version:||unspecified||CC:||agordeev, ajb, alexander.strachan, alwin.warringa, anazmy, aquini, baumanmo, bhu, blc, ctowsley, dgross, dhoward, dhowells, didier.fabert, emilovanov, eric.eisenhart, esammons, fche, fdeutsch, fhrbata, gagriogi, gbailey, gnaik, hannsj_uhl, hartsjc, iboverma, jaeshin, james.eckersall, jkacur, joelsmith, jonathan.moore, jross, jsmith.fedora, kernel-mgr, kstutsma, leon, lgoncalv, liko, lwang, marcvanwageningen, matt, mcressma, mdshaikh, mguzik, mlangsdo, mmilgram, mschena, mszpak, nmurray, pdwyer, pholasek, pim, plougher, pmatouse, rcernin, redhat, riehecky, rik.theys, rvdwees, rvrbovsk, scolebrook, security-response-team, slawomir, slong, swat, syangsao, tadej.j, t.h.amundsen, timm2k, toracat, tru, vchepkov, williams, wliu, wmealing, yozone|
|Fixed In Version:||Doc Type:||Bug Fix|
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.
|Last Closed:||2016-01-29 13:49:29 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||1296623, 1298035, 1298036, 1298037, 1298038, 1298039, 1298040, 1298931|
Description Adam Mariš 2016-01-11 15:42:09 UTC
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-13 04:49:43 UTC
Acknowledgements: Name: the Perception Point research team
Comment 6 Wade Mealing 2016-01-14 06:54:17 UTC
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 17:25:15 UTC
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 14 Arkadiusz Miskiewicz 2016-01-19 18:54:29 UTC
Comment 15 Frank Ch. Eigler 2016-01-19 19:52:32 UTC
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 24 Vincent Danen 2016-01-21 16:50:53 UTC
External References: https://access.redhat.com/node/2131021
Comment 25 errata-xmlrpc 2016-01-25 19:14:19 UTC
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 19:28:23 UTC
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 14:00:38 UTC
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 18:22:11 UTC
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 06:25:09 UTC
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.