Bug 645305 - CVE-2010-3904 kernel: Linux RDS Protocol Local Privilege Escalation
Summary: CVE-2010-3904 kernel: Linux RDS Protocol Local Privilege Escalation
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 14
Hardware: Unspecified
OS: Unspecified
low
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker
Depends On: 645252
Blocks: CVE-2010-3904
TreeView+ depends on / blocked
 
Reported: 2010-10-21 09:40 UTC by Nils Philippsen
Modified: 2013-01-10 06:17 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 645252
Environment:
Last Closed: 2011-08-26 20:30:02 UTC


Attachments (Terms of Use)

Description Nils Philippsen 2010-10-21 09:40:31 UTC
I verified this one on the currently available F-14 kernel, 2.6.35.6-45.fc14.x86_64:

nils@gibraltar:/tmp> getenforce
Enforcing
nils@gibraltar:/tmp> ./linux-rds-exploit 
[*] Linux kernel >= 2.6.30 RDS socket exploit
[*] by Dan Rosenberg
[*] Resolving kernel addresses...
 [+] Resolved rds_proto_ops to 0xffffffffa04c7790
 [+] Resolved rds_ioctl to 0xffffffffa04c1000
 [+] Resolved commit_creds to 0xffffffff8106b52c
 [+] Resolved prepare_kernel_cred to 0xffffffff8106b94f
[*] Overwriting function pointer...
[*] Triggering payload...
[*] Restoring function pointer...
[*] Got root!
sh-4.1# 

+++ This bug was initially created as a clone of Bug #645252 +++

Description of problem:
Vulnerability Details                                                         
- ---------------------                                                       
On Linux, recvmsg() style socket calls are performed using iovec structs,
which
allow a user to specify a base address and size for a buffer used to receive
socket data.  Each packet family is responsible for defining functions that
copy socket data, which is received by the kernel, back to user space to allow
user programs to process and handle received network data.

When performing this copying of data to user space, the RDS protocol failed to
verify that the base address of a user-provided iovec struct pointed to a
valid
userspace address before using the __copy_to_user_inatomic() function to copy
the data.  As a result, by providing a kernel address as an iovec base and
issuing a recvmsg() style socket call, a local user could write arbitrary data
into kernel memory.  This can be leveraged to escalate privileges to root.

Please make updates for all currently stable releases, F12 and F13. Thank you.

Version-Release number of selected component (if applicable):
2.6.34.7-56.fc13.i686.PAE
2.6.32.21-168.fc12.i686.PAE

How reproducible:
Always exploitable

Steps to Reproduce:
And the updated exploit is available at:
http://www.vsecurity.com/download/tools/linux-rds-exploit.c
  
Actual results:
got root access

Additional info:
http://www.vsecurity.com/resources/advisory/20101019-1/

Comment 1 Matthew Ife 2010-10-22 08:00:27 UTC
This does not work on most domains confined by SELinux, including RBAC enabled
users such as staff_t and user_t, because it relies on having access to the
system map / kallsyms which is a restricted file and/or "create" access on
sockets which is typically not supplied in most confinements.

Comment 2 Adam Williamson 2010-10-22 17:49:00 UTC
I'm marking this issue as F14Blocker to proxy for kernel team's suggestion that we respin F14 to include kernel -48 for this issue, the three other CVEs, and the thinkpad suspend/resume fix.

suspend/resume is not a blocker issue, we've established that historically, which leaves the CVEs.

I asked vdanen for security team input on this. Here's what he said:

---

<vdanen> gotchya
 ok, all four issues look like they can only be exploited locally
 so even with a network install, you're not opening up the system with a password-less or static-password-login, right?  (i have no idea, but i doubt it)
<adamw> i really don't think so
<vdanen> if not, you should be ok, as an attacker would need to obtain local access to the system
* vdanen wonders if the installer boots with a restrictive firewall active; if not, it should
<vdanen> regardless, i think it should be fine for a 0day
<adamw> i don't know about that, would have to ask anaconda folks
<vdanen> shouldn't impact installation

---

given that input, my vote is a weak -1 blocker, +1 NTH.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 3 James Laska 2010-10-22 18:00:24 UTC
(In reply to comment #2)
> given that input, my vote is a weak -1 blocker, +1 NTH.

Thanks for the detailed feedback Adam and Vincent.  I agree with +1 NTH

Comment 4 Adam Williamson 2010-10-22 18:26:51 UTC
further info: we asked anaconda team to review the exposure surface of the installer, and it looks good. nothing is listening remotely except sshd if you explicitly launch with the 'sshd' parameter to anaconda. we also evaluated the live CD, and that also looks good: the only thing listening is avahi, which is intended (it's the zeroconf daemon), and is not subject to any known security issues.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 5 Adam Williamson 2010-10-22 18:27:53 UTC
note that if we go ahead and don't make this a blocker, we should document that you shouldn't manually enable sshd in anaconda in a situation where untrusted people could connect to the machine. and certainly not without using a kickstart file to specify a password for it.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 6 Jesse Keating 2010-10-22 18:29:12 UTC
Voting Nice to Have, as in not blocker.

Comment 7 Jesse Keating 2010-10-22 18:30:27 UTC
(In reply to comment #5)
> note that if we go ahead and don't make this a blocker, we should document that
> you shouldn't manually enable sshd in anaconda in a situation where untrusted
> people could connect to the machine. and certainly not without using a
> kickstart file to specify a password for it.
> 

That goes without saying regardless of any potential exploit.  Everything is running as root in anaconda land.  There is no other user for somebody to ssh into, in order to gain root.  It's all root.

Comment 8 Sandro Mathys 2010-10-22 18:39:25 UTC
+1 NTH, but in the unlikely event of a GA slip this should become a blocker - maybe even if we go for a complete RC2, i.e. not only a new Desktop spin.

Either way this should be available as a 0-day update.

Comment 9 Adam Williamson 2010-10-22 19:03:51 UTC
jesse: yep, really just a reminder-to-self to check the install guide.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 10 Sandro Mathys 2010-10-22 20:01:26 UTC
Update confirmed to fix this security issue:
https://admin.fedoraproject.org/updates/kernel-2.6.35.6-48.fc14?_csrf_token=c293eb3dfafa8f4fec9008351595f08e0f92cede

Comment 11 Adam Williamson 2010-10-22 21:28:40 UTC
I think we have enough votes now to declare this NTH. If anyone becomes aware of a factor we haven't considered that may make this back into a blocker, please do raise it here. thanks!



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 12 collura 2010-10-29 22:40:15 UTC
the kernel-2.6.35.6-48.fc14 (x84_64) just came through updater

Comment 13 Adam Williamson 2010-11-01 23:04:11 UTC
Removing F14 NTH status as F14 is now out.

Remaining open nice-to-have issues do NOT automatically become nice-to-have issues for Fedora 15. If you believe a Fedora 14 issue which was accepted as
nice-to-have but not resolved in time for release should also qualify for
nice-to-have status for Fedora 15, please re-propose it as nice-to-have for
Fedora 15.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 14 Josh Boyer 2011-08-26 20:30:02 UTC
This was fixed in the update listed in comment #10.


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