Bug 1094232 - (CVE-2014-0196) CVE-2014-0196 kernel: pty layer race condition leading to memory corruption
CVE-2014-0196 kernel: pty layer race condition leading to memory corruption
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=20140501,repo...
: Security
Depends On: 1094236 1094237 1094238 1094239 1094240 1094241 1094242 1094243 1094244 1094245 1111286
Blocks: 1094259
  Show dependency treegraph
 
Reported: 2014-05-05 06:38 EDT by Petr Matousek
Modified: 2016-02-10 03:25 EST (History)
61 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-10 03:25:47 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)

  None (edit)
Description Petr Matousek 2014-05-05 06:38:09 EDT
It is unexpected and not allowed to call TTY buffer helpers like
tty_insert_flip_string concurrently. This may lead to crashes when
ECHOing is enabled and concurrect writers call pty_write in the
meantime. In that case the two writers:
* the ECHOing from a workqueue and
* pty_write from the process
race and can overflow the corresponding TTY buffer.

An unprivileged local user could use this flaw to crash the system or,
potentially, escalate their privileges on the system.

References:
http://seclists.org/oss-sec/2014/q2/243
Comment 1 Petr Matousek 2014-05-05 06:40:27 EDT
Statement:

This issue did not affect the versions of the Linux kernel packages as shipped with Red Hat Enterprise Linux 5.

This issue affected the versions of the Linux kernel packages as shipped with Red Hat Enterprise Linux 6 prior to version kernel-2.6.32-358.6.1.el6, released via RHSA-2013:0744 (https://rhn.redhat.com/errata/RHSA-2013-0744.html). That update added a backport of the upstream commit c56a00a165, which avoided this issue.

This flaw requires local system access to be exploited. We are currently not aware of any working exploit for Red Hat Enterprise Linux 6 or Red Hat Enterprise MRG 2.
Comment 5 Petr Matousek 2014-05-05 06:46:50 EDT
Created kernel tracking bugs for this issue:

Affects: fedora-all [bug 1094240]
Comment 7 Fedora Update System 2014-05-09 23:20:50 EDT
kernel-3.14.3-200.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 8 Stefan Neufeind 2014-05-12 09:44:53 EDT
Any news about a fix for RHEL?
Comment 9 sincerewong 2014-05-13 04:58:34 EDT
any patch released?
Comment 10 David Busby 2014-05-13 05:18:19 EDT
Took the POC code by Matthew Daley {at} bugfuzz.com (http://bugfuzz.com/stuff/cve-2014-0196-md.c)

and ran against CentOS 6.5 Kernels.

2.6.32.-431.11.2
2.6.32.-431.17.1

The POC code which notes "
 * Caveat: The vulnerability should be exploitable all the way from
 * v2.6.31-rc3, however relevant changes to the TTY subsystem were made in
 * commit acc0f67f307f52f7aec1cffdc40a786c15dd21d9 ("tty: Halve flip buffer
 * GFP_ATOMIC memory consumption") that make exploitation simpler, which this
 * exploit relies on.
"

A root shell could not be gained via the POC code, presumably the required commit noted above is not present? (i'd be happy to test additional POCs)

Tested both with SELinux enforcing and permissive.
Comment 11 Petr Matousek 2014-05-13 05:20:12 EDT
Hello,

(In reply to Stefan Neufeind from comment #8)
> Any news about a fix for RHEL?

(In reply to sincerewong from comment #9)
> any patch released?

please see the statement in comment 1.

Thank you,
--
Petr Matousek / Red Hat Security Response Team
Comment 12 Francisco Garcia 2014-05-13 16:22:34 EDT
Hello
   I compiled the C program on RHEL boxes running kernel 2.6.32-358 and 2.6.32.220 and I could not gain root access

All I get is: [+] Resolving Symbols
              [+] Resolved commit_creds: (nil)
              [+] Resolved prepare_kernel_cred: (nil)


When the execution is done my id remains the same, are there any test scenarios?
Comment 13 Rui Miguel Seabra 2014-05-14 10:17:51 EDT
In a CentOS 6 KVM guest with all current updates it didn't crash for me.

Important note: maybe selinux (which I always keep active in targetted mode unless some stupid application forbids it) prevents this issue from being sucessfully exlpoited...

Currently running 2.6.32-431.17.1.el6
Comment 14 Rui Miguel Seabra 2014-05-14 10:33:53 EDT
To be clear, this is the exploit I tried: http://pastebin.com/raw.php?i=yTSFUBgZ

I'll test now with the one from Matthew Daley
Comment 15 Rui Miguel Seabra 2014-05-14 10:38:15 EDT
Same results as Francisco Garcia.
Comment 16 John Sullivan 2014-05-14 10:58:11 EDT
(In reply to Francisco Garcia from comment #12)
>    I compiled the C program on RHEL boxes running kernel 2.6.32-358 and
> 2.6.32.220 and I could not gain root access
> 
> All I get is: [+] Resolving Symbols
>               [+] Resolved commit_creds: (nil)
>               [+] Resolved prepare_kernel_cred: (nil)

(Speaking only of 358, I've not examined the 220 source.)

The first problem you're hitting here is that it reads kernel symbols from /proc/kallsyms, but that kernel reports all symbol values as 0 for non-root readers. As a security mechanism this is trivial to bypass. Just save the file out as root and change the PoC to read from it instead. Since the symbol values do not change across reboots, and often don't change between minor kernel updates, you don't need root on the target box either, just something running the same kernel (which you can identify with "uname -a" as non-root on the target box.)

The next problem you would hit is that the tty_struct is different between 358 and the exploited kernel. The tty_operations function pointer list has moved, meaning the PoC even if it works just zeroes it out. So you need to adapt the PoC to match the target structure layout.

The third problem is the "halve flip buffer" patch. With it, character data extends to the end of the allocated buffer and can be used to directly overflow into the following kernel structure (hopefully a tty_struct, thus overwriting the operation list.) 358 doesn't have that so the buffer is split into half, character data first, then flags data. So unless you can directly control the flags data it is likely corruption/crash only, not root exploit. Or unless you can write more than double the character buffer size in the race, which probably needs 3 writers (one of which is not under your control, and the others which are may be otherwise interlocked and thus not usable for this).

The fourth problem is that 358 contains a RH specific patch which adds extra spinlock acquisition around the implicated buffer accesses - that might be sufficient mitigation from the exploit. (Though the fix patches a different function, which might still be required.)

(In reply to Rui Miguel Seabra from comment #13)
> Important note: maybe selinux (which I always keep active in targetted mode
> unless some stupid application forbids it) prevents this issue from being
> sucessfully exlpoited...

The meat of the exploit is just doing normal tty/pty operations, so unless your selinux policy is restricting access to /dev/ptmx and /dev/pts/* it's unlikely to affect this. (Even then, it might be possible to exec something that *is* allowed to create ptys, such as /usr/bin/script, to get the work done.)
Comment 17 John Moore 2014-05-14 14:57:04 EDT
While I got similar results as RHEL6 with the latest SL6 updates. I had a strange result. I was testing the exploit with a KVM vm of RHEL7-x86_64-RC1. I had three instances running overnight on the vm and it exhausted resources. I forced off the vm via virt-manager and the SL6 KVM host kernel crashed. I saw a kernel backtrace and did a three fingered salute to reboot the server. While this is an unusual test case, the exploit did work on RHEL7 and indirectly caused the RHEL6 clone host to kernel panic when I tried to kill the virtual machine.
Comment 18 Petr Matousek 2014-05-14 16:02:16 EDT
(In reply to John Sullivan from comment #16)
> The fourth problem is that 358 contains a RH specific patch which adds extra
> spinlock acquisition around the implicated buffer accesses - that might be
> sufficient mitigation from the exploit. (Though the fix patches a different
> function, which might still be required.)

I can confirm that.  Current Red Hat Enterprise Linux 6 kernels contain backport of upstream commit c56a00a165712fd73081f40044b1e64407bb1875 which added additional locking into tty_insert_flip_string() function which effectively avoids the CVE-2014-0196 issue.

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c56a00a165

The latest Red Hat Enterprise Linux 6.2 AUS and 6.3 EUS kernel do not have the above mentioned backport and thus are affected.

--
Petr Matousek / Red Hat Security Response Team
Comment 19 Petr Matousek 2014-05-14 16:07:03 EDT
Hi, John.

(In reply to John Moore from comment #17)
> I was testing the exploit with a KVM vm of RHEL7-x86_64-RC1.
> I had three instances running overnight on the vm and it exhausted
> resources. I forced off the vm via virt-manager and the SL6 KVM host kernel
> crashed. I saw a kernel backtrace and did a three fingered salute to reboot
> the server. While this is an unusual test case, the exploit did work on
> RHEL7 and indirectly caused the RHEL6 clone host to kernel panic when I
> tried to kill the virtual machine.

Can you reproduce this issue? If so, can you please file a (separate) bug with all the details?

Thank you,
--
Petr Matousek / Red Hat Security Response Team
Comment 23 kyumin 2014-05-16 01:51:05 EDT
Hi 
Does it mean normal rhel 5 & rhel 6 is not affected from this bugs while rhel 6.2 AUS, 6.3 EUS  and rhel mrg 2 are..

This issue does not affect the versions of the Linux kernel packages as shipped with Red Hat Enterprise Linux 5.


This issue does not affect the versions of the Linux kernel packages as shipped  with Red Hat Enterprise Linux 6.

This flaw requires shell access, and we are currently unaware of any working exploits affecting Red Hat Enterprise Linux 6.2 AUS, 6.3 EUS or Red Hat Enterprise MRG 2.
Comment 24 Petr Matousek 2014-05-16 02:13:46 EDT
(In reply to kyumin from comment #23)
> Does it mean normal rhel 5 & rhel 6 is not affected from this bugs while
> rhel 6.2 AUS, 6.3 EUS  and rhel mrg 2 are..

Yes. 

You've omitted one paragraph from comment 1 which says --

This issue does affect the versions of the Linux kernel packages as shipped with Red Hat Enterprise Linux 6.2 AUS, Red Hat Enterprise Linux 6.3 EUS and Red Hat Enterprise MRG 2, and we are currently working on corrected kernel packages that address this issue.
Comment 25 kyumin 2014-05-16 02:18:45 EDT
thanks for your answer, 
so those people who is using normal version of "rhel 6.0, 6.1, 6.2, 6.3, 6.4, 6.5" doesn't need to be worried unless they are using specific version which are "Red Hat Enterprise Linux 6.2 AUS, Red Hat Enterprise Linux 6.3 EUS and Red Hat Enterprise MRG 2"
Comment 26 Petr Matousek 2014-05-16 03:01:30 EDT
(In reply to kyumin from comment #25)
> so those people who is using normal version of "rhel 6.0, 6.1, 6.2, 6.3,
> 6.4, 6.5" doesn't need to be worried unless they are using specific version
> which are "Red Hat Enterprise Linux 6.2 AUS, Red Hat Enterprise Linux 6.3
> EUS and Red Hat Enterprise MRG 2"

With your definition of normal, AUS/EUS are incremental add-ons to normal versions, in terms of support. That is, if AUS/EUS version is affected, so is the normal version.

For more information about Red Hat Enterprise Linux versioning and support status, please consult https://access.redhat.com/site/support/policy/updates/errata and/or contact Red Hat customer support at https://access.redhat.com/home.
Comment 27 kyumin 2014-05-16 03:19:52 EDT
ok thanks for your clarification. 

Pleaes, allow me to double-confirm one more time.. 
so rhel 6.0, 6.1, 6.4 & 6.4 are not affected from this bug but rhel 6.2, 6.3 & rhel mrg 2, right? 
Thanks for your time and your patience..
Comment 28 kyumin 2014-05-16 03:48:24 EDT
sorry for noise.. 

if you mean is that all rhel 6 version is affected this bug beside 'Red Hat Enterprise Linux 6.4 EUS (since kernel-2.6.32-358.6.2.el6) and Red Hat Enterprise Linux 6.5', Should below statment be "does", not "does not"

==============Statement:==============
This issue does not affect the versions of the Linux kernel packages as shipped  with Red Hat Enterprise Linux 6.
=======================================

Please, correct me if I am wrong.
Comment 29 Petr Matousek 2014-05-16 03:54:44 EDT
(In reply to kyumin from comment #27)
> Pleaes, allow me to double-confirm one more time.. 
> so rhel 6.0, 6.1, 6.4 & 6.4 are not affected from this bug but rhel 6.2, 6.3
> & rhel mrg 2, right? 

Every Red Hat Enterprise Linux 6 kernel version before kernel-2.6.32-358.6.2.el6 (released via https://rhn.redhat.com/errata/RHSA-2013-0744.html) is affected.
Comment 30 Petr Matousek 2014-05-16 04:17:48 EDT
Hi,

(In reply to kyumin from comment #28)

I understand that my original statement regarding this issues could be confusing to our customers. I've updated the statement with a new version that is (hopefully) more clear. I am very sorry for the troubles.

Please check updated comment 1.

Thank you,
--
Petr Matousek / Red Hat Security Response Team
Comment 32 Tomas Hoger 2014-05-16 04:36:34 EDT
If you need further assistance with determining if particular kernel version used is affected, please contact Red Hat Support:

https://access.redhat.com/site/support/contact/technicalSupport/
Comment 33 kyumin 2014-05-16 05:37:52 EDT
Thanks Pert. 

Can anyone take care of "https://access.redhat.com/security/cve/CVE-2014-0196" as well, Please ? 

To Tomas, 
I have my TAM support for this issue. thanks.
Comment 34 Tomas Hoger 2014-05-16 05:54:21 EDT
(In reply to kyumin from comment #33)
> Can anyone take care of
> "https://access.redhat.com/security/cve/CVE-2014-0196" as well, Please ? 

Updated statement here will propagate to the CVE database automatically within few hours.
Comment 35 errata-xmlrpc 2014-05-19 07:21:06 EDT
This issue has been addressed in following products:

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

Via RHSA-2014:0512 https://rhn.redhat.com/errata/RHSA-2014-0512.html
Comment 36 errata-xmlrpc 2014-05-20 07:01:27 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6.2 AUS

Via RHSA-2014:0520 https://rhn.redhat.com/errata/RHSA-2014-0520.html
Comment 37 Fedora Update System 2014-05-21 19:22:24 EDT
kernel-3.14.4-100.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 39 errata-xmlrpc 2014-05-27 12:28:22 EDT
This issue has been addressed in following products:

  MRG for RHEL-6 v.2

Via RHSA-2014:0557 https://rhn.redhat.com/errata/RHSA-2014-0557.html
Comment 40 errata-xmlrpc 2014-06-10 08:45:51 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 7

Via RHSA-2014:0678 https://rhn.redhat.com/errata/RHSA-2014-0678.html

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