Bug 634457 - (CVE-2010-3081) CVE-2010-3081 kernel: 64-bit Compatibility Mode Stack Pointer Underflow
CVE-2010-3081 kernel: 64-bit Compatibility Mode Stack Pointer Underflow
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
public=20100915,reported=20100916,sou...
: Security
: 635642 (view as bug list)
Depends On: 634458 634460 634461 634462 634463 634464 634465 634466 634506 634507 637023 637024
Blocks:
  Show dependency treegraph
 
Reported: 2010-09-16 01:23 EDT by Eugene Teo (Security Response)
Modified: 2015-02-16 10:49 EST (History)
91 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-04-24 00:18:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
patch with fix to the release kernel-2.6.18-194.11.3.el5 (6.81 KB, patch)
2010-09-19 18:08 EDT, Roberto Yokota
no flags Details | Diff

  None (edit)
Description Eugene Teo (Security Response) 2010-09-16 01:23:13 EDT
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.
Comment 3 Eugene Teo (Security Response) 2010-09-16 03:17:41 EDT
Exploit: http://seclists.org/fulldisclosure/2010/Sep/268
Comment 7 Christoph A. 2010-09-16 06:07:35 EDT
public exploit:
http://seclists.org/fulldisclosure/2010/Sep/268
Comment 8 Eugene Teo (Security Response) 2010-09-16 07:07:02 EDT
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.
Comment 12 Eugene Teo (Security Response) 2010-09-17 03:42:54 EDT
Statement:

More information can be found in this kbase: https://access.redhat.com/kb/docs/DOC-40265.
Comment 13 Petter Reinholdtsen 2010-09-17 03:53:32 EDT
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]
Comment 17 Nelson Elhage 2010-09-17 17:45:57 EDT
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.
Comment 18 Christoph A. 2010-09-17 20:11:34 EDT
May I ask why my comment from 2010-09-16 was removed without comment?
Comment 19 Eugene Teo (Security Response) 2010-09-17 21:58:34 EDT
(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.
Comment 20 Roberto Yokota 2010-09-19 18:08:26 EDT
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
Comment 21 Roberto Yokota 2010-09-19 18:11:02 EDT
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)
Comment 22 Roberto Yokota 2010-09-19 18:11:55 EDT
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)
Comment 23 Eugene Teo (Security Response) 2010-09-19 21:19:01 EDT
(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.
Comment 27 Orlando Richards 2010-09-20 04:18:46 EDT
Hi Eugene,

Can you give an approximate ETA on release of the patched rpms?

Cheers,
Orlando.
Comment 28 Eugene Teo (Security Response) 2010-09-20 04:58:38 EDT
(In reply to comment #27)
> Can you give an approximate ETA on release of the patched rpms?

Orlando, early this week. Thanks.
Comment 29 Eugene Teo (Security Response) 2010-09-20 05:36:39 EDT
Updated kbase. See comment #12.
Comment 30 Bjorge Solli 2010-09-20 07:21:54 EDT
Is this backport for RHEL-variants only or are you backporting/testing on Fedora too?
Comment 31 Eugene Teo (Security Response) 2010-09-20 07:41:41 EDT
(In reply to comment #30)
> Is this backport for RHEL-variants only or are you backporting/testing on
> Fedora too?

The former. Thanks.
Comment 32 Gilboa Davara 2010-09-20 10:04:35 EDT
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
Comment 33 Bjorge Solli 2010-09-20 10:15:12 EDT
(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
Comment 34 Eugene Teo (Security Response) 2010-09-20 10:20:50 EDT
*** Bug 635642 has been marked as a duplicate of this bug. ***
Comment 35 Sean E. Millichamp 2010-09-20 10:25:57 EDT
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.
Comment 36 Eugene Teo (Security Response) 2010-09-20 10:27:39 EDT
(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@redhat.com>
- x86_64: plug compat syscalls holes. (CVE-2010-3081, CVE-2010-3301)
  upgrading is highly recommended.

Hope this helps.

Thanks, Eugene
Comment 37 Tomas Hoger 2010-09-20 10:34:42 EDT
For the status of the Fedora kernels addressing this flaw, check the following Bodhi link:

  https://admin.fedoraproject.org/updates/search/CVE-2010-3081
Comment 38 Gilboa Davara 2010-09-20 10:52:07 EDT
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!
Comment 39 Dave Botsch 2010-09-20 11:11:17 EDT
From the kbase article, whether or not RHEL4 is affected is unclear. Would someone care to clarify?

thanks.
Comment 40 Cody Robertson 2010-09-20 11:26:34 EDT
(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).
Comment 41 advax 2010-09-20 12:46:07 EDT
(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.
Comment 42 Cody Robertson 2010-09-20 12:48:25 EDT
(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.
Comment 43 Ewan Mac Mahon 2010-09-20 13:08:08 EDT
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.
Comment 44 Matthew Miller 2010-09-20 13:11:40 EDT
(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.
Comment 45 Gary Smith 2010-09-20 15:18:32 EDT
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?
Comment 46 advax 2010-09-20 15:38:12 EDT
(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.
Comment 47 Kevin Stange 2010-09-20 16:14:55 EDT
(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.
Comment 48 Steven Ciaburri 2010-09-20 16:46:33 EDT
(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.
Comment 49 Eugene Teo (Security Response) 2010-09-20 23:17:05 EDT
(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.
Comment 50 Chuck Ebbert 2010-09-20 23:36:06 EDT
Fixed in 2.6.27.54, 2.6.32.22 and 2.6.35.5
Comment 51 Jon Masters 2010-09-21 01:14:56 EDT
Indeed, Greg K-H just posted announcements to LKML a bit earlier this evening on those.
Comment 52 errata-xmlrpc 2010-09-21 04:09:46 EDT
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
Comment 53 errata-xmlrpc 2010-09-21 04:20:53 EDT
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
Comment 55 errata-xmlrpc 2010-09-22 10:20:02 EDT
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
Comment 61 blackforest 2010-09-27 11:52:56 EDT
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?
Comment 62 Jarod Wilson 2010-09-27 12:09:34 EDT
(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.
Comment 63 errata-xmlrpc 2010-09-28 08:26:19 EDT
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
Comment 64 errata-xmlrpc 2010-09-28 08:52:22 EDT
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
Comment 65 errata-xmlrpc 2010-10-07 22:12:08 EDT
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
Comment 66 errata-xmlrpc 2010-11-10 14:07:51 EST
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
Comment 67 errata-xmlrpc 2010-11-12 04:37:28 EST
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
Comment 68 errata-xmlrpc 2010-11-22 14:34:36 EST
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

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