Bug 626504 (CVE-2010-3852) - CVE-2010-3852 Luci: Authentication bypass via fake ticket cookie
Summary: CVE-2010-3852 Luci: Authentication bypass via fake ticket cookie
Alias: CVE-2010-3852
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 626415 645404
TreeView+ depends on / blocked
Reported: 2010-08-23 17:15 UTC by Jan Lieskovsky
Modified: 2021-03-26 15:07 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-04-05 00:32:45 UTC

Attachments (Terms of Use)

Description Jan Lieskovsky 2010-08-23 17:15:31 UTC
A security flaw was found in the way Luci administration application
processed ticket cookies. A remote attacker, with certain knowledge
of running Luci instance environment details could use this flaw to
bypass standard Luci authentication mechanism (access resources which
should be otherwise protected by authentication).

Comment 2 Jan Lieskovsky 2010-10-18 19:13:18 UTC
The CVE identifier of CVE-2010-3852 has been assigned to this issue.

Comment 4 Jan Lieskovsky 2010-10-21 13:19:55 UTC
Further flaw details from Jan Pokorny (original reporter):

Fake ticket cookie can be generated quite easily and used to obtain access.


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)

[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

Comment 6 Jan Lieskovsky 2010-10-21 13:25:10 UTC
Created luci tracking bugs for this issue

Affects: fedora-all [bug 645404]

Comment 7 Jan Pokorný [poki] 2010-10-21 18:33:27 UTC
For upstream, http://git.fedorahosted.org/git?p=luci.git;a=commit;h=9e0bbf0c5faa198379d945474f7d55da5031cacf solves this issue.

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