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

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.

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

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

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

(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.

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

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

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

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.

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.

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.

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.

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.

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

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

(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

(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.

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

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

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

(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.

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.

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.

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

(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)

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

(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.

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.

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

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

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.

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

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

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

(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

(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)...

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

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