This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 516949 - (CVE-2009-2692) CVE-2009-2692 kernel: uninit op in SOCKOPS_WRAP() leads to privesc
CVE-2009-2692 kernel: uninit op in SOCKOPS_WRAP() leads to privesc
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
impact=important,source=vendorsec,rep...
: Security
Depends On: 516950 516951 516952 516953 516954 516955 517444 517445 519700
Blocks:
  Show dependency treegraph
 
Reported: 2009-08-11 22:26 EDT by Eugene Teo (Security Response)
Modified: 2012-05-25 10:55 EDT (History)
74 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Eugene Teo (Security Response) 2009-08-11 22:26:38 EDT
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.
Comment 10 Eugene Teo (Security Response) 2009-08-14 01:47:26 EDT
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
Comment 11 Christopher McCrory 2009-08-14 11:16:53 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
Comment 12 Eugene Teo (Security Response) 2009-08-14 12:27:37 EDT
(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.
Comment 16 Fedora Update System 2009-08-14 23:10:20 EDT
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
Comment 17 Fedora Update System 2009-08-14 23:11:14 EDT
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
Comment 19 Fedora Update System 2009-08-15 10:08:40 EDT
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
Comment 20 Fedora Update System 2009-08-15 17:45:18 EDT
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.
Comment 21 Fedora Update System 2009-08-15 17:45:36 EDT
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.
Comment 24 Raghavendra Badiger 2009-08-17 07:26:59 EDT
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.
Comment 25 John Kacur 2009-08-17 09:22:18 EDT
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.
Comment 27 Jeff Huckaby 2009-08-17 10:27:45 EDT
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.
Comment 30 Jeremy West 2009-08-17 13:36:08 EDT
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
Comment 32 Jonathan Peatfield 2009-08-17 14:18:59 EDT
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
Comment 34 Eugene Teo (Security Response) 2009-08-17 20:42:12 EDT
(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
Comment 35 Eugene Teo (Security Response) 2009-08-17 20:45:23 EDT
(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.
Comment 37 Eugene Teo (Security Response) 2009-08-18 01:31:34 EDT
Kbase article: http://kbase.redhat.com/faq/docs/DOC-18065
Comment 40 Fedora Update System 2009-08-19 05:10:01 EDT
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
Comment 42 Evan Stable 2009-08-20 14:55:27 EDT
This is not ever going to get fixed, is it?
Comment 43 Eugene Teo (Security Response) 2009-08-20 19:59:13 EDT
(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.
Comment 44 Andrew C Aitchison 2009-08-21 02:32:08 EDT
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.
Comment 46 Jan Lieskovsky 2009-08-21 05:16:34 EDT
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.
Comment 47 Eugene Teo (Security Response) 2009-08-21 09:43:53 EDT
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@redhat.com. 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
Comment 48 Jeroen Wunnink 2009-08-21 10:13:42 EDT
(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)
Comment 49 Evan Stable 2009-08-21 12:02:49 EDT
Not to mention the fact that Debian and Ubuntu have already released an updated kernel.  Debian and Ubuntu are both free distributions.
Comment 50 Ray Van Dolson 2009-08-21 12:10:46 EDT
(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.
Comment 51 Taco Scargo 2009-08-23 04:03:30 EDT
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.
Comment 52 errata-xmlrpc 2009-08-24 04:12:11 EDT
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
Comment 53 errata-xmlrpc 2009-08-24 04:29:26 EDT
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
Comment 54 Andrew C Aitchison 2009-08-24 05:09:34 EDT
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.
Comment 57 errata-xmlrpc 2009-08-27 16:01:49 EDT
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
Comment 58 errata-xmlrpc 2009-09-01 03:38:26 EDT
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
Comment 59 errata-xmlrpc 2009-09-01 05:28:40 EDT
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
Comment 63 Lex 2009-09-18 06:00:52 EDT
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
Comment 64 Jonathan Peatfield 2009-09-18 06:16:38 EDT
(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
Comment 65 Eugene Teo (Security Response) 2009-09-20 22:12:01 EDT
(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)...
Comment 66 errata-xmlrpc 2009-09-22 10:57:55 EDT
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
Comment 67 errata-xmlrpc 2009-09-30 10:58:47 EDT
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

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