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
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.
Proposed upstream commit: https://git.kernel.org/cgit/linux/kernel/git/gregkh/tty.git/commit/?h=tty-linus&id=4291086b1f081b869c6d79e5b7441633dc3ace00
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 1094240]
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.
Any news about a fix for RHEL?
any patch released?
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.
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
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?
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
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
Same results as Francisco Garcia.
(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.)
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.
(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
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
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.
(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.
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"
(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.
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..
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.
(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.
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
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/
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.
(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.
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
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
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.
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
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