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