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/
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.
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
(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
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
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
Voting Nice to Have, as in not blocker.
(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.
+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.
jesse: yep, really just a reminder-to-self to check the install guide. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Update confirmed to fix this security issue: https://admin.fedoraproject.org/updates/kernel-2.6.35.6-48.fc14?_csrf_token=c293eb3dfafa8f4fec9008351595f08e0f92cede
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
the kernel-2.6.35.6-48.fc14 (x84_64) just came through updater
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
This was fixed in the update listed in comment #10.