Bug 626504 (CVE-2010-3852)
Summary: | CVE-2010-3852 Luci: Authentication bypass via fake ticket cookie | ||
---|---|---|---|
Product: | [Other] Security Response | Reporter: | Jan Lieskovsky <jlieskov> |
Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | unspecified | CC: | cluster-maint, rmccabe, rmusil, security-response-team |
Target Milestone: | --- | Keywords: | Security |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-04-05 00:32:45 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: | 626415, 645404 | ||
Bug Blocks: |
Description
Jan Lieskovsky
2010-08-23 17:15:31 UTC
The CVE identifier of CVE-2010-3852 has been assigned to this issue. Further flaw details from Jan Pokorny (original reporter): ========================================================== LUCI -- SECURITY ISSUE Fake ticket cookie can be generated quite easily and used to obtain access. Abstract: ======== An attacker can bypass Luci authentication by exploiting 'well-known' secret key to make a fake ticket cookie. I. Problem description: ====================== The main problem is that in who.ini file that contains configuration for repoze.who authentication component used in Luci (default way of authentication in TurboGears2) uses 'well-known' (demonstration-default) secret key. This secret key, "[INSERT SECRET HERE]", is mentioned by Pylons' how-to page [1]. Among other thing that would help the attacker is the whole fact that it is known that Luci uses TurboGears2 which allows him some assumptions about the possible weaknesses and techniques and values that are used by default here -- without the knowledge of them, described attack would be almost impossible. (But even if the attacker did not know about TurboGears2, he could guess it could be among other Python frameworks TurboGears2/Pylons according to the HTTP header sent by the server, e.g. "Server PasteWSGIServer/0.5 Python/2.6.4"). Note that the same kind of attack would be probably possible under similar conditions if Luci used own database of users/groups/permissions as in the past. II. Conclusion: ============== This problem showed up that external components cannot be relied upon without an investigation of possible security impacts and without taking time to understand what everything may or should be configured to ensure high level of security. Main suggested step to ensure security: * secret key unique per-installation (generated at install time) References: ========== [1] http://wiki.pylonshq.com/display/pylonscookbook/Authentication+and+Authorization+with+`repoze.who` [2] https://addons.mozilla.org/en-US/firefox/addon/4510/ [3] http://groups.google.com/group/turbogears-announce/browse_thread/thread/daf8db234df8105b -- Jan Pokorny, jpokorny (AT) redhat (dot) com 2010-08-20 Created luci tracking bugs for this issue Affects: fedora-all [bug 645404] For upstream, http://git.fedorahosted.org/git?p=luci.git;a=commit;h=9e0bbf0c5faa198379d945474f7d55da5031cacf solves this issue. |