Description of problem: A vulnerability in the 32-bit compatibility layer for 64-bit systems was reported. It is caused by insecure allocation of user space memory when translating system call inputs to 64-bit. A stack pointer underflow can occur when using the "compat_alloc_user_space" method with an arbitrary length input. Reference: http://sota.gen.nz/compat1/ Upstream commit: http://git.kernel.org/linus/c41d68a513c71e35a14f66d71782d27a79a81ea6 Acknowledgements: Red Hat would like to thank Ben Hawkes for reporting this issue.
Exploit: http://seclists.org/fulldisclosure/2010/Sep/268
public exploit: http://seclists.org/fulldisclosure/2010/Sep/268
The Red Hat Security Response Team is aware of this issue. We are working on updated packages to correct this issue and will release them once they have been completed and tested.
Statement: More information can be found in this kbase: https://access.redhat.com/kb/docs/DOC-40265.
A workaround for this issue is to run this command echo ':32bits:M:0:\x7fELF\x01::/bin/echo:' > /proc/sys/fs/binfmt_misc/register It disable 32-bit ELF support. The workaround was written by Terje Malmedal. [Source: http://seclists.org/fulldisclosure/2010/Sep/273]
(In reply to comment #13) > [Source: http://seclists.org/fulldisclosure/2010/Sep/273] One report suggests this won't always work: http://www.h-online.com/open/news/forum/S-workaround-DOES-NOT-PREVENT-EXPLOIT/forum-116020/msg-14370942/read/
The 'robert_you_suck' exploit mentioned in the post Mike cites is an exploit for CVE-2010-3080, which is a distinct issue discovered at the same time as this issue. RHEL 5 is not affected by that issue.
May I ask why my comment from 2010-09-16 was removed without comment?
(In reply to comment #18) > May I ask why my comment from 2010-09-16 was removed without comment? See comment #3. I posted the same link earlier, but thanks for sharing the link with us. Appreciated it.
Created attachment 448317 [details] patch with fix to the release kernel-2.6.18-194.11.3.el5 I've shared the patch with fix to the release kernel-2.6.18-194.11.3.el5, due to the urgency. It was tested and applied in production. See the file attached. Regards, Roberto Yokota
Test Information: Last stable kernel: [bob@xxx ~]$ date Sun Sep 19 18:22:38 BRT 2010 [bob@xxx ~]$ cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.5 (Tikanga) [bob@xxx ~]$ uname -a Linux xxx 2.6.18-194.11.3.el5 #1 SMP Mon Aug 23 15:51:38 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux [bob@xxx ~]$ id uid=500(bob) gid=500(bob) groups=500(bob) [bob@xxx ~]$ ./exploit Ac1dB1tCh3z VS Linux kernel 2.6 kernel 0d4y $$$ Kallsyms +r $$$ K3rn3l r3l3as3: 2.6.18-194.11.3.el5 ??? Trying the F0PPPPPPPPPPPPPPPPpppppppppp_____ m3th34d $$$ L00k1ng f0r kn0wn t4rg3tz.. $$$ c0mput3r 1z aqu1r1ng n3w t4rg3t... $$$ selinux_ops->ffffffff80327ac0 $$$ dummy_security_ops->ffffffff804b9540 $$$ capability_ops->ffffffff80329380 $$$ selinux_enforcing->ffffffff804bc2a0 $$$ audit_enabled->ffffffff804a7124 $$$ Bu1ld1ng r1ngzer0c00l sh3llc0d3 - F0PZzzZzZZ/LSD(M) m3th34d $$$ Prepare: m0rn1ng w0rk0ut b1tch3z $$$ Us1ng st4nd4rd s3ash3llz $$$ 0p3n1ng th3 m4giq p0rt4l $$$ bl1ng bl1ng n1gg4 :PppPpPPpPPPpP sh-3.2# id uid=0(root) gid=500(bob) groups=500(bob)
Last stable kernel with the patch: [bob@xxx ~]$ date Sun Sep 19 18:54:11 BRT 2010 [bob@xxx ~]$ cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.5 (Tikanga) [bob@xxx ~]$ uname -a Linux xxx 2.6.18-194.11.4.el5.yos1 #1 SMP Sun Sep 19 17:54:03 BRT 2010 x86_64 x86_64 x86_64 GNU/Linux [bob@xxx ~]$ id uid=500(bob) gid=500(bob) groups=500(bob) [bob@xxx ~]$ ./exploit Ac1dB1tCh3z VS Linux kernel 2.6 kernel 0d4y $$$ Kallsyms +r $$$ K3rn3l r3l3as3: 2.6.18-194.11.4.el5.yos1 ??? Trying the F0PPPPPPPPPPPPPPPPpppppppppp_____ m3th34d $$$ L00k1ng f0r kn0wn t4rg3tz.. $$$ c0mput3r 1z aqu1r1ng n3w t4rg3t... $$$ selinux_ops->ffffffff80327ac0 $$$ dummy_security_ops->ffffffff804b9540 $$$ capability_ops->ffffffff80329380 $$$ selinux_enforcing->ffffffff804bc2a0 $$$ audit_enabled->ffffffff804a7124 $$$ Bu1ld1ng r1ngzer0c00l sh3llc0d3 - F0PZzzZzZZ/LSD(M) m3th34d $$$ Prepare: m0rn1ng w0rk0ut b1tch3z $$$ Us1ng st4nd4rd s3ash3llz $$$ 0p3n1ng th3 m4giq p0rt4l !!! y0u fuq1ng f41l. g3t th3 fuq 0ut! [bob@xxx ~]$ id uid=500(bob) gid=500(bob) groups=500(bob)
(In reply to comment #20) > Created attachment 448317 [details] > patch with fix to the release kernel-2.6.18-194.11.3.el5 > > I've shared the patch with fix to the release kernel-2.6.18-194.11.3.el5, due > to the urgency. It was tested and applied in production. > See the file attached. > > Regards, > > Roberto Yokota Roberto, we have already backported the patch. It's going through testing now. Thanks.
Hi Eugene, Can you give an approximate ETA on release of the patched rpms? Cheers, Orlando.
(In reply to comment #27) > Can you give an approximate ETA on release of the patched rpms? Orlando, early this week. Thanks.
Updated kbase. See comment #12.
Is this backport for RHEL-variants only or are you backporting/testing on Fedora too?
(In reply to comment #30) > Is this backport for RHEL-variants only or are you backporting/testing on > Fedora too? The former. Thanks.
Should we file a separate bug report under F12/13 or is this issue being handled concurrently? As expected, _suck does root F13/x86_64 machine. - Gilboa
(In reply to comment #32) > Should we file a separate bug report under F12/13 or is this issue being > handled concurrently? https://bugzilla.redhat.com/show_bug.cgi?id=635642 Bjørge
*** Bug 635642 has been marked as a duplicate of this bug. ***
For those not aware... Apparently the published exploit code leaves a backdoor that is exploitable and detectable. There is a published tool to check for this at http://www.ksplice.com/uptrack/cve-2010-3081 In my quick and very limited testing this seems to be an in-memory backdoor only which will be cleared by a reboot, but if you wanted to check to see if anyone had been using this exploit before applying the patch and rebooting it might be useful.
(In reply to comment #32) > Should we file a separate bug report under F12/13 or is this issue being > handled concurrently? > As expected, _suck does root F13/x86_64 machine. > > - Gilboa You can install kernel-2.6.34.7-56.fc13 or kernel-2.6.32.21-168.fc12 by running sudo yum --enablerepo=updates-testing install kernel. $ rpm -q --changelog kernel-2.6.34.7-56.fc13.i686 [...] * Tue Sep 14 2010 Kyle McMartin <kyle> - x86_64: plug compat syscalls holes. (CVE-2010-3081, CVE-2010-3301) upgrading is highly recommended. Hope this helps. Thanks, Eugene
For the status of the Fedora kernels addressing this flaw, check the following Bodhi link: https://admin.fedoraproject.org/updates/search/CVE-2010-3081
I can confirm the -56 does solve 3081. (I had it installed on my workstation in-order to test another BZ) -54: $ uname -a Linux gilboa-wx-dev 2.6.34.6-54.fc13.x86_64 #1 SMP Sun Sep 5 17:16:27 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux $ gcc ./check_cve.c -o check_cve $ ./check_cve resolved symbol commit_creds to 0xffffffff8106b711 resolved symbol prepare_kernel_cred to 0xffffffff8106b5f9 mapping at 3f80000000 UID 0, EUID:0 GID:0, EGID:0 sh-4.1# ls /root/ anaconda-ks.cfg install.log install.log.syslog -56: $ uname -a Linux gilboa-home-dev 2.6.34.7-56.fc13.x86_64 #1 SMP Wed Sep 15 03:36:55 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux $ gcc ./check_cve.c -o check_cve $ ./check_cve resolved symbol commit_creds to 0xffffffff8106b731 resolved symbol prepare_kernel_cred to 0xffffffff8106b619 mapping at 3f80000000 UID 800, EUID:800 GID:800, EGID:800 sh-4.1$ ls /root ls: cannot open directory /root: Permission denied Thanks!
From the kbase article, whether or not RHEL4 is affected is unclear. Would someone care to clarify? thanks.
(In reply to comment #35) > For those not aware... Apparently the published exploit code leaves a backdoor > that is exploitable and detectable. There is a published tool to check for > this at http://www.ksplice.com/uptrack/cve-2010-3081 > > In my quick and very limited testing this seems to be an in-memory backdoor > only which will be cleared by a reboot, but if you wanted to check to see if > anyone had been using this exploit before applying the patch and rebooting it > might be useful. Correct - rebooting it will clear out the backdoor that this places. Also keep in mind the ksplice tool only checks for the stuff placed by the original exploit code (Ac1dB1tCh3z).
(In reply to comment #35) > In my quick and very limited testing this seems to be an in-memory backdoor > only which will be cleared by a reboot, but if you wanted to check to see if > anyone had been using this exploit before applying the patch and rebooting it > might be useful. How would one check ? The Ac1dB1tch3z code appears to try 3 exploits, viz. FOPS, IDT, LSM. In my testing on an FC9 machine, the FOPS backdoor disappeared after rebooting. I can't follow the code well enough to understand it, and I'm not sure what the point is of a backdoor that does not survive a reboot if you already have a reliable exploit. The Ksplice page suggests that a patched system would still be vulnerable if the backdoor was installed. This would seem to be nonsense if patching requires a kernel upgrade.
(In reply to comment #41) > (In reply to comment #35) > > > In my quick and very limited testing this seems to be an in-memory backdoor > > only which will be cleared by a reboot, but if you wanted to check to see if > > anyone had been using this exploit before applying the patch and rebooting it > > might be useful. > > How would one check ? > > The Ac1dB1tch3z code appears to try 3 exploits, viz. FOPS, IDT, LSM. In my > testing on an FC9 machine, the FOPS backdoor disappeared after rebooting. > I can't follow the code well enough to understand it, and I'm not sure what the > point is of a backdoor that does not survive a reboot if you already have a > reliable exploit. The Ksplice page suggests that a patched system would still > be vulnerable if the backdoor was installed. This would seem to be nonsense if > patching requires a kernel upgrade. I believe the ksplice article meant if the exploit was already ran their patch / patching in general cannot ensure the integrity of the machine as it may have already been compromised.
Ksplice's entire purpose is to patch kernels without rebooting. I'm pretty sure their point was that if you're a Ksplice user, and you use Ksplice to patch the original hole, you won't have closed the 'backdoor', if, indeed, it had ever been opened. Clearly, if you're not using Ksplice and you upgrade by rebooting, there's nothing to worry about - the upgrade reboot will remove the backdoor.
(In reply to comment #41) > The Ac1dB1tch3z code appears to try 3 exploits, viz. FOPS, IDT, LSM. In my > testing on an FC9 machine, the FOPS backdoor disappeared after rebooting. > I can't follow the code well enough to understand it, and I'm not sure what the > point is of a backdoor that does not survive a reboot if you already have a > reliable exploit. The Ksplice page suggests that a patched system would still > be vulnerable if the backdoor was installed. This would seem to be nonsense if > patching requires a kernel upgrade. After using this exploit, the attacker could install whatever rootkit or whatever other persists-after-reboot code they like. And if they're careful, this may be hard to detect, because your kernel is compromised. A full reinstall is really the wise course.
I understand that this is a kernel level exposure vulnerability and it's technical aspect, but what's the impact for people who use them for things like firewalls, etc (i.e. environments where normally only admins would be able to installs/compile/execute applications). Basically, the question is what are all of the attack vectors (besides having access to install and run an app to use the exploit?
(In reply to comment #45) > I understand that this is a kernel level exposure vulnerability and it's > technical aspect, but what's the impact for people who use them for things like > firewalls, etc (i.e. environments where normally only admins would be able to > installs/compile/execute applications). None, IMO. The risk is for places like university data centres that have hundreds of user accounts and lax security (AKA a legitimate need to login from home or while on sabbatical in Brazil etc.) We found a hacker using a CVE-2009-2692 exploit in conjunction with a trojan SSH server to quietly collect passwords, then hop to other vulnerable machines and try the exploit again. This exploit could be used in exactly the same way.
(In reply to comment #45) > Basically, the question is what are all of the attack vectors (besides having > access to install and run an app to use the exploit? In web hosting, the common attack vector would be via PHP scripts. If you exploit outdated or poorly conceived PHP scripts, you can often execute arbitrary shell commands via the web server user (or another user) and use that access to invoke this exploit.
(In reply to comment #47) > (In reply to comment #45) > > Basically, the question is what are all of the attack vectors (besides having > > access to install and run an app to use the exploit? > > In web hosting, the common attack vector would be via PHP scripts. If you > exploit outdated or poorly conceived PHP scripts, you can often execute > arbitrary shell commands via the web server user (or another user) and use that > access to invoke this exploit. Indeed. I came across a server yesterday which was exploited through a vulnerable joomla installation. The attacker uploaded a precompiled binary which contained the kernel exploit and instructions to mass deface the server. The attacker executed the single binary and it defaced the box without much effort.
(In reply to comment #39) > From the kbase article, whether or not RHEL4 is affected is unclear. Would > someone care to clarify? The Red Hat Enterprise Linux 4 kernel is not affected by the publicly circulated exploit, but we plan to backport the missing compat_alloc_user_space() sanity checks in the future Red Hat Enterprise Linux 4 update.
Fixed in 2.6.27.54, 2.6.32.22 and 2.6.35.5
Indeed, Greg K-H just posted announcements to LKML a bit earlier this evening on those.
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2010:0704 https://rhn.redhat.com/errata/RHSA-2010-0704.html
This issue has been addressed in following products: Red Hat Enterprise Linux 5.4.Z - Server Only Via RHSA-2010:0705 https://rhn.redhat.com/errata/RHSA-2010-0705.html
This issue has been addressed in following products: Red Hat Enterprise Linux 5.3.Z - Server Only Via RHSA-2010:0711 https://rhn.redhat.com/errata/RHSA-2010-0711.html
Hello All, Does this bug pertain to 64 bit only versions of the kernel. I'm currently running the 32 bit version of version 5.5. Linux 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:43 EDT 2010 i686 i686 i386 GNU/Linux Am I affected, by this bug? Where do I download the bug fix from, does it require a reboot?
(In reply to comment #61) > Hello All, > Does this bug pertain to 64 bit only versions of the kernel. > I'm currently running the 32 bit version of version 5.5. > > Linux 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:43 EDT 2010 i686 i686 i386 > GNU/Linux > > Am I affected, by this bug? No, its a 64-bit-only bug. But please update to the latest 5.5 kernel anyway, there are additional security fixes that do impact 32-bit that have been fixed.
This issue has been addressed in following products: Red Hat Enterprise Linux 4 Via RHSA-2010:0718 https://rhn.redhat.com/errata/RHSA-2010-0718.html
This issue has been addressed in following products: Red Hat Enterprise Linux 4.7 Z Stream Via RHSA-2010:0719 https://rhn.redhat.com/errata/RHSA-2010-0719.html
This issue has been addressed in following products: MRG for RHEL-5 Via RHSA-2010:0758 https://rhn.redhat.com/errata/RHSA-2010-0758.html
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2010:0842 https://rhn.redhat.com/errata/RHSA-2010-0842.html
This issue has been addressed in following products: Red Hat Enterprise Linux 3 Extended Lifecycle Support Via RHSA-2010:0882 https://rhn.redhat.com/errata/RHSA-2010-0882.html