Local root exploit via CVE-2009-2692 (incorrect proto_ops initializations)

[Mike Green]

Binary package hint: linux-image-2.6.15-54-server

CVE Candidate is CVE-2009-2692

Exploit:

http://seclists.org/fulldisclosure/2009/Aug/0180.html

Patch:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e694958388c50148389b0e9b9e9e8945cf0f1b98

WORK-AROUND:

Ubuntu 8.04 and later have a default setting of 65536 in /proc/sys/vm/mmap_min_addr. When set, this issue is blocked. If your value is 0, please purge the "wine" and "dosemu" packages, and reset the value:

sudo apt-get purge wine dosemu
echo 65536 | sudo tee /proc/sys/vm/mmap_min_addr

On Ubuntu 6.06 (Dapper), the following configuration will work around the issue (note this disables IPv6):

sudo -s
cat > /etc/modprobe.d/mitigate-2692.conf << EOM
install ppp_generic /bin/true
install pppoe /bin/true
install pppox /bin/true
install slhc /bin/true
install bluetooth /bin/true
install ipv6 /bin/true
install irda /bin/true
install ax25 /bin/true
install x25 /bin/true
install ipx /bin/true
install appletalk /bin/true
EOM
/etc/init.d/bluez-utils stop
rmmod pppoe pppox ppp_generic slhc ax25 x25 irda crc_ccitt ipx ipv6 appletalk rfcomm l2cap bluetooth

[Eugene (eugene-redhat-bugs)]

Description of problem:
Reported by Tavis Ormandy and Julien Tinnes. The SOCKOPS_WRAP macro from include/linux/net.h doesn't initialise the sendpage operation in the proto_ops structure correctly. Leading to a kernel NULL pointer dereference, and thus a local privilege escalation.

Acknowledgements:

Red Hat would like to thank Tavis Ormandy and Julien Tinnes of the Google
Security Team for responsibly reporting this flaw.

[Eugene (eugene-redhat-bugs)]

References:
http://blog.cr0.org/2009/08/linux-null-pointer-dereference-due-to.html
http://archives.neohapsis.com/archives/fulldisclosure/2009-08/0174.html
http://www.securityfocus.com/bid/36038/info
http://www.centos.org/modules/newbb/viewtopic.php?topic_id=21740&forum=42
http://www.linux-archive.org/centos/352108-kernel-null-pointer-vulnerability.html

Upstream commit for 2.6:
http://git.kernel.org/linus/e694958388c50148389b0e9b9e9e8945cf0f1b98

Upstream commit for 2.4:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.4.37.y.git;a=commitdiff_plain;h=c18d0fe535a73b219f960d1af3d0c264555a12e3

[Eugene (eugene-redhat-bugs)]

CVSS2 score of important, 7.2 (AV:L/AC:L/Au:N/C:C/I:C/A:C)

Note that the CVSS 'access vector' is set to AV:L as this is a vulnerability exploitable with only local access.

Mitigation:
It is possible to mitigate this flaw by blacklisting the affected protocols. Note that this is not an exhaustive list of modules to blacklist, but this should prevent the publicly circulated exploit from working properly as this is the list of protocols (relevant to RHEL) known to be affected.

** Ensure that the module is not already loaded, if not, these mitigation steps will not work.

** We have used the 'install' command to direct the system to run '/bin/true' instead of actually inserting the kernel module if it is called.

** On Red Hat Enterprise Linux 3, add this entry to the end of the /etc/modules.conf file:

install bluez /bin/true

Note that the bluez module is from the kernel-unsupported package. If you do not have this package installed, then you do not have this module.

** On Red Hat Enterprise Linux 4 and 5, add these entries to the end of the
/etc/modprobe.conf file:

install pppox /bin/true
install bluetooth /bin/true
install sctp /bin/true

Note that the sctp module cannot be unloaded in the running kernel if it is already loaded. You will need to make the changes in the /etc/modprobe.conf file and do a reboot.

** On Red Hat Enterprise MRG, add these entries to the end of the
/etc/modprobe.conf file:

install pppox /bin/true
install bluetooth /bin/true
install appletalk /bin/true
install ipx /bin/true
install sctp /bin/true

Updated: Aug 17, 2009 20:45 EDT

[Christopher (christopher-redhat-bugs)]

re:

** On Red Hat Enterprise Linux 3, add this entry to the end of the
/etc/modprobe.conf file:

install bluez /bin/true

I think that should be /etc/modules.conf

[Kees Cook (kees)]

Ubuntu 8.04 and later have a default setting of 65536 in /proc/sys/vm/mmap_min_addr. When set, this issue is blocked. If your value is 0, please purge the "wine" and "dosemu" packages, and reset the value:

  sudo apt-get purge wine dosemu
  echo 65536 | sudo tee /proc/sys/vm/mmap_min_addr

On Ubuntu 6.06, we recommend the work-around detailed above. Kernel are being built shortly to address the issue directly.

[Eugene (eugene-redhat-bugs)]

(In reply to comment #11)
> re:
>
> ** On Red Hat Enterprise Linux 3, add this entry to the end of the
> /etc/modprobe.conf file:
>
> install bluez /bin/true
>
> I think that should be /etc/modules.conf

That's right. Thanks, Christopher. I have corrected this in c#10.

[Mike Green (mikey-badpenguins)]

Not sure about 8.04 and above with mmap_min_addr set > 0 if SELinux is implemented, according to the Mitigation section of the following post:

http://seclists.org/fulldisclosure/2009/Aug/0173.html

[Kees Cook (kees)]

SELinux is not a default on Ubuntu, but if it is enabled, the work-arounds above could be used instead.

[Fedora (fedora-redhat-bugs)]

kernel-2.6.29.6-217.2.7.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/kernel-2.6.29.6-217.2.7.fc11

[Fedora (fedora-redhat-bugs)]

kernel-2.6.27.29-170.2.79.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/kernel-2.6.27.29-170.2.79.fc10

[Fedora (fedora-redhat-bugs)]

kernel-2.6.30.5-28.rc2.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/kernel-2.6.30.5-28.rc2.fc11

[Mike Green (mikey-badpenguins)]

From my admittedly limited understanding mmap_min_addr can be gotten around with suid executables, pulseaudio is used in the published exploits. If this is the case, wouldn't 8.04 and above, unpatched, be exploitable via suid executables, even with the mmap_min_addr set above 0?

http://lwn.net/Articles/342330/

[Kees Cook (kees)]

That issue was fixed in the last kernel update (USN-807-1) as CVE-2009-1895.

[Fedora (fedora-redhat-bugs)]

kernel-2.6.27.29-170.2.79.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.

[Fedora (fedora-redhat-bugs)]

kernel-2.6.29.6-217.2.7.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.

[Xaweryz (xaweryz)]

This patch should be applied to fix this issue.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e694958388c50148389b0e9b9e9e8945cf0f1b98

[Raghavendra (raghavendra-redhat-bugs)]

Hi,

As following modules are affected by this "Linux Kernel 'sock_sendpage()' NULL Pointer Dereference Vulnerability" which is very critical, could you please let us know when the fix for this will be available on RHEL 4.X and RHEL5.X Updates.

 The affected module includes PF_APPLETALK, PF_IPX,
  PF_IRDA, PF_X25 and PF_AX25 families.

- Initializations were missing in other protocols, including PF_BLUETOOTH,
  PF_IUCV, PF_INET6 (with IPPROTO_SCTP), PF_PPPOX and PF_ISDN.

Affected Kernel Modules
=======================
ipx.ko
irda.ko
x25.ko
ax25.ko
bluetooth.ko
sctp.ko
pppoe.ko
pppox.ko
appletalk.ko

Thanks & Regards
-Raghu.

[John (john-redhat-bugs)]

git describe --contains e694958388c50148389b0e9b9e9e8945cf0f1b98
v2.6.31-rc6~8

The current MRG V2 kernel is based off v2.6.31-rc6 - so this is not a problem
for us.

[Jeff (jeff-redhat-bugs)]

I had an RHEL 4 system compromised today due to this issue.

Using GDB I was able to core dump the processes and found the web site from
which they obtained the exploit code. I have copies of the exploit code if
someone is interested. They entered the system through a web application
exploit and then used the exploit to gain a root shell.

I have applied the mitigation techniques above until a updated kernel is made
available.

[Jeremy (jeremy-redhat-bugs)]

Please note that Bugzilla is not an avenue for technical support. Customers
using Red Hat Enterprise Linux who require assistance regarding this issue
should contact their Red Hat Support representative.

Please see http://www.redhat.com/support for details on contacting Red Hat
Support

[Jonathan (jonathan-redhat-bugs)]

I think that the point of #24 and probably #27 is that the suggested workround for RHEL4/5 does _not_ close all the possible ways to exploit this exploit, ie adding just:

  install pppox /bin/true
  install bluetooth /bin/true

will (for example) still allow code using PF_INET6, SOCK_STREAM, IPPROTO_SCTP to exploit the hole if ipv6 and sctp are available.

One of the links from #5 has some sample exploit code which tried a whole bunch of different options to the socket call to see if any of them work.

BTW I'm puzzled that this bz is still marked as 'new' - surely it ought to have been confirmed and the proposed patches passed to engineering by now... Maybe that the bug is only regarded as 'important' (well in #10 it is), means that we will have to wait for the next regular kernel update for this to be fixed.

 -- Jon

[Eugene (eugene-redhat-bugs)]

(In reply to comment #32)
> I think that the point of #24 and probably #27 is that the suggested workround
> for RHEL4/5 does _not_ close all the possible ways to exploit this exploit, ie
> adding just:
>
> install pppox /bin/true
> install bluetooth /bin/true
>
> will (for example) still allow code using PF_INET6, SOCK_STREAM, IPPROTO_SCTP
> to exploit the hole if ipv6 and sctp are available.

As I mentioned in comment #10, this is not an exhaustive list of modules to blacklist. On my test Red Hat Enterprise Linux 5 machine, the sctp module does not load automatically when the reproducer is executed. But yes, I will include your suggestion to the existing mitigation steps.

> BTW I'm puzzled that this bz is still marked as 'new' - surely it ought to have
> been confirmed and the proposed patches passed to engineering by now... Maybe
> that the bug is only regarded as 'important' (well in #10 it is), means that we
> will have to wait for the next regular kernel update for this to be fixed.

For every security bug, we have a top-level bug (this one) and several tracking bugs. The top-level bug is only used for tracking purposes, so the status for the top-level bug should not be taken as an indication for anything. Only the status of the tracking bugs matter.

Thanks, Eugene

[Eugene (eugene-redhat-bugs)]

(In reply to comment #24)
> As following modules are affected by this "Linux Kernel 'sock_sendpage()' NULL
> Pointer Dereference Vulnerability" which is very critical, could you please
> let us know when the fix for this will be available on RHEL 4.X and RHEL5.X
> Updates.

Raghavendra, please contact Red Hat Support. See http://www.redhat.com/support for details on contacting the team.

[Eugene (eugene-redhat-bugs)]

Kbase article: http://kbase.redhat.com/faq/docs/DOC-18065

[Julian Kranz (juliankranz)]

Why THE HELL is bug "Medium"? Every idiot is able to get root privileges within a minute on every ubuntu system world wide and you think this just a "medium" problem?

And why is this hole still gaping wide open, even more then 48 hours after debian released a fix for the bug?

[Kees Cook (kees)]

Hi, it's medium because it's local-only, and is not, as you say, an issue for all Ubuntu systems -- only those with a non-default /proc/sys/vm/mmap_min_addr setting. Additionally, there are work-around available while the fix is being worked oni. Debian was more vulnerable, so they acted more quickly. The Ubuntu kernels are currently building, and we expect them to publish after they pass QA today.

[Julian Kranz (juliankranz)]

Your statement is false; I've just successfully used the famous exploit ( http://grsecurity.net/~spender/wunderbar_emporium.tgz ) to gain root privileges on a fresh bootet Ubuntu 9.04 x86 Live CD.

[Julian Kranz (juliankranz)]

I must apologise: After a little more research I found out that this might actually be connected to some older bug, that is already fixed. I didn't know that this exploit tries out more than one way to break the security ;-)

But even given that I don't really change my opinion - I do not have a very special configuration; I think installing wine already sets /proc/sys/vm/mmap_min_addr to zero. So this will actually affect the utter most part of the ubuntu installations and is also caused by an application inside the repository, which is therefor a part of ubuntu.

[Kees Cook (kees)]

Correct, the Live CD does not contain an updated kernel for the personality-via-pulse exploit (CVE-2009-1895), fixed in USN-807-1, which allowed mmap_min_addr to be bypassed. Ubuntu with Wine installed are most likely to be single-user systems, which helps reduce the number of people in real danger from this vulnerability.

This current bug is certainly important, which is why it's not being ignored. Kernels take a while to build for all releases on all architectures, and will be completed later today.

[Kees Cook (kees)]

Released as: http://www.ubuntu.com/usn/usn-819-1

[Bremm (bremm)]

Hi everyone,

I noticed before kernel update (15.49) that sctp and libcrc32 modules were loaded (2.6.28-15-generic) and AFAIK, SCTP stills experimental. Well, since config.gz isn't available under /proc, could I use /usr/src/linux-headers-2.6.28-15-generic/.config as reference?

Thanks in advance

(Sidenote: I've just lost my previous text -- it was much better but a bit longer -- because lauchpad logged me off before I submit this posting)

[Fedora (fedora-redhat-bugs)]

kernel-2.6.30.5-32.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/kernel-2.6.30.5-32.fc11

[Kees Cook (kees)]

You need to reboot for the kernel to be reloaded. As for config, see /boot/config-$(uname -r)

[Evan (evan-redhat-bugs)]

This is not ever going to get fixed, is it?

[Eugene (eugene-redhat-bugs)]

(In reply to comment #42)
> This is not ever going to get fixed, is it?

No. We will be releasing an update to address this very soon. Right now, Quality Engineering is testing the updated kernel to ensure we do not introduce any regression.

[Andrew (andrew-redhat-bugs)]

I trust that there would have been a different QA process had it been a critical, remotely exploitable, bug ? Over a week from a published exploit *and* an upstream fix to release a kernel is not good.

I don't have access to the tracking bugs, so there may be a good reason,
but frankly I'm surprised that this bug wasn't fixed by applying the
upstream patch to the last kernel that Quality Engineering approved, and released with only abbreviated QA.

[Jan (jan-redhat-bugs)]

A duplicate CVE identifier of CVE-2009-2962 has been also assigned to this
issue. Note from MITRE:

Name: CVE-2009-2962
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2962

** REJECT **

DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2009-2692. Reason:
This candidate is a duplicate of CVE-2009-2692. A typo caused the
wrong ID to be used. Notes: All CVE users should reference
CVE-2009-2692 instead of this candidate. All references and
descriptions in this candidate have been removed to prevent accidental
usage.

[Eugene (eugene-redhat-bugs)]

Hi Andrew,

(In reply to comment #44)
> I trust that there would have been a different QA process had it been a
> critical, remotely exploitable, bug ? Over a week from a published exploit
> *and* an upstream fix to release a kernel is not good.

If this is a critical remote exploitable vulnerability, we will give it the highest priority to release a kernel update that addresses the issue.

For this issue, it is a local privilege escalation vulnerability that can be mitigated. For customers who are unable to perform the mitigation steps, they can request for a hotfix (unofficial but supported kernel that has this fix until we are ready to release one) from Red Hat Support.

If you have any questions, feel free to email us directly at <email address hidden>. We respond very quickly ;)

> I don't have access to the tracking bugs, so there may be a good reason,

Please see https://bugzilla.redhat.com/show_bug.cgi?id=516949#c34

Thanks, Eugene

[Jeroen (jeroen-redhat-bugs)]

(In reply to comment #47)
>
> If this is a critical remote exploitable vulnerability, we will give it the
> highest priority to release a kernel update that addresses the issue.
>
> For this issue, it is a local privilege escalation vulnerability that can be
> mitigated. For customers who are unable to perform the mitigation steps, they
> can request for a hotfix (unofficial but supported kernel that has this fix
> until we are ready to release one) from Red Hat Support.

The problem is, that apache is also a local user, so any server running Apache with PHP, Perl (or any other scripting language) just became a huge risk.

Any PHP script (like your random badly programmed mambo/joomla module) which has a remote file include exploit, just became a very easy way into root access on almost every RHEL and Fedora server.

We've been upgrading 250 servers over the last 5 days with official .src.rpm's of the kernels with our own patched socket.c file in it, in that time we almost had 1 server compromised, so this exploit is certainly in the wild.
'Luckily' the server froze instead of dropping to a root shell.

- Jeroen Wunnink
(Sysadmin at a dutch webhosting company)

[Evan (evan-redhat-bugs)]

Not to mention the fact that Debian and Ubuntu have already released an updated kernel. Debian and Ubuntu are both free distributions.

[Ray (ray-redhat-bugs)]

(In reply to comment #49)
> Not to mention the fact that Debian and Ubuntu have already released an updated
> kernel. Debian and Ubuntu are both free distributions.

What's your point? Fedora released their update as well.

RHEL's customers tend to be Enterprise users, and while we certainly expect any critical vulnerabilities to be fixed in a timely manner, we also expect thorough testing and QA to be done on any release so as not to interrupt our environments. This is why we use RHEL and not a "free" distribution. :-)

In any case, this probably isn't the place for this discussion to happen. If you want the patched kernel faster, get a hotfix from Support and push it out.

[Taco (taco-redhat-bugs)]

A simple but very needed patch like this should be able to be tested and out to customers as fast as lightning. In my eyes this issue leaves competitors and bashers of Red Hat all the room they would need.
I myself am very disappointed in the way that Red Hat addresses this vulnerability.

@Ray Van Dolson: Enterprise customers pay Red Hat to provide a patch instead of needing to create one themselves or rely on the community. I agree that Red Hat's customers expect a tested and Q&A'd kernel release. But due to the severity and exploitability of this flaw, combined with the relative simple fix, should not cause customers to have to wait (more than) two weeks for an updated kernel to be released to customers. Added to this Red Hat is relatively silent on the ETA of their fixed kernel.

[errata-xmlrpc (errata-xmlrpc-redhat-bugs)]

This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2009:1222 https://rhn.redhat.com/errata/RHSA-2009-1222.html

[errata-xmlrpc (errata-xmlrpc-redhat-bugs)]

This issue has been addressed in following products:

  Red Hat Enterprise Linux 4

Via RHSA-2009:1223 https://rhn.redhat.com/errata/RHSA-2009-1223.html

[Andrew (andrew-redhat-bugs)]

Ah. Now I see why the delay.
Two security holes fixed, with the second coming just at the wrong time and delaying the first by a week :-(
Not very happy, but at least I now understand the delay. However a pointer to
https://bugzilla.redhat.com/show_bug.cgi?id=518034 - even if I couldn't read it - in comment #43 would have stopped me making comment #44.

Thanks for the fixes for Enterprise Linux 4 and Enterprise Linux 5.
Looking forward to the fix for Enterprise Linux 3 too.

[errata-xmlrpc (errata-xmlrpc-redhat-bugs)]

This issue has been addressed in following products:

  Red Hat Enterprise Linux 3

Via RHSA-2009:1233 https://rhn.redhat.com/errata/RHSA-2009-1233.html

[errata-xmlrpc (errata-xmlrpc-redhat-bugs)]

This issue has been addressed in following products:

  MRG for RHEL-5

Via RHSA-2009:1239 https://rhn.redhat.com/errata/RHSA-2009-1239.html

[Lex (lex-redhat-bugs)]

Hi,

i add below line in file /etc/modprobe.conf. it work but i would like to enable sctp module.is that any other mitigative method to protect the system(FC6,2.6.18-1.2798) without blocking sctp module.Thank!

install ppp_generic /bin/true
install pppoe /bin/true
install pppox /bin/true
install slhc /bin/true
install bluetooth /bin/true
install ipv6 /bin/true
install irda /bin/true
install ax25 /bin/true
install x25 /bin/true
install ipx /bin/true
install appletalk /bin/true

--lex

[Jonathan (jonathan-redhat-bugs)]

(In reply to comment #63)
> Hi,
>
> i add below line in file /etc/modprobe.conf. it work but i would like to enable
> sctp module.is that any other mitigative method to protect the
> system(FC6,2.6.18-1.2798) without blocking sctp module.Thank!

Only muy opinion but _I_ think you probably ought to update to a supported version first. You will be missing many more security updates than just this one if you are still running something based on FC6...

 -- Jon

[Eugene (eugene-redhat-bugs)]

(In reply to comment #64)
> (In reply to comment #63)
> > Hi,
> >
> > i add below line in file /etc/modprobe.conf. it work but i would like to enable
> > sctp module.is that any other mitigative method to protect the
> > system(FC6,2.6.18-1.2798) without blocking sctp module.Thank!
>
> Only muy opinion but _I_ think you probably ought to update to a supported
> version first. You will be missing many more security updates than just this
> one if you are still running something based on FC6...
>
> -- Jon

Jon is correct. Besides, Fedora Core 6 is already End of Life (EOL)...

[errata-xmlrpc (errata-xmlrpc-redhat-bugs)]

This issue has been addressed in following products:

  Red Hat Enterprise Linux 5.2 Z Stream

Via RHSA-2009:1457 https://rhn.redhat.com/errata/RHSA-2009-1457.html

[errata-xmlrpc (errata-xmlrpc-redhat-bugs)]

This issue has been addressed in following products:

  Red Hat Enterprise Linux 4.7 Z Stream

Via RHSA-2009:1469 https://rhn.redhat.com/errata/RHSA-2009-1469.html