Bug 645305
| Summary: | CVE-2010-3904 kernel: Linux RDS Protocol Local Privilege Escalation | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Nils Philippsen <nphilipp> |
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | low | ||
| Version: | 14 | CC: | awilliam, collura, dcantrell, dougsland, gansalmon, itamar, jlaska, jonathan, kernel-maint, madhu.chinakonda, matthew.ife, ondrejj, sandro |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | RejectedBlocker | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 645252 | Environment: | |
| Last Closed: | 2011-08-26 20:30:02 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 645252 | ||
| Bug Blocks: | 642896 | ||
|
Description
Nils Philippsen
2010-10-21 09:40:31 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. 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. |