Bug 626504 - (CVE-2010-3852) CVE-2010-3852 Luci: Authentication bypass via fake ticket cookie
CVE-2010-3852 Luci: Authentication bypass via fake ticket cookie
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On: 626415 645404
  Show dependency treegraph
Reported: 2010-08-23 13:15 EDT by Jan Lieskovsky
Modified: 2016-04-26 09:52 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-04-04 20:32:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jan Lieskovsky 2010-08-23 13:15:31 EDT
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 15:13:18 EDT
The CVE identifier of CVE-2010-3852 has been assigned to this issue.
Comment 4 Jan Lieskovsky 2010-10-21 09:19:55 EDT
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 09:25:10 EDT
Created luci tracking bugs for this issue

Affects: fedora-all [bug 645404]
Comment 7 Jan Pokorný 2010-10-21 14:33:27 EDT
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.