RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 982771 - luci vs. sessions: check length of secret on startup
Summary: luci vs. sessions: check length of secret on startup
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: luci
Version: 6.4
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Jan Pokorný [poki]
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-09 20:44 UTC by Jan Pokorný [poki]
Modified: 2014-10-14 04:12 UTC (History)
4 users (show)

Fixed In Version: luci-0.26.0-51.el6
Doc Type: Enhancement
Doc Text:
Feature: Startup check that the length of the configured secret (initially, auto-generated) does not weaken the strength of HMAC algorithm used to protect integrity of session data handles. Reason: User might compromise the security of the server-stored session data upon uneducated modification, in extreme case causing secret to be an empty string hence disabling the integrity layer for the session handles altogether. This would allow malicious user to, e.g., keep systematically exhausting resources of /var/run/luci/sessions pertaining file system possibly resulting in denial of service. Result (if any): As a security hardening, if the configured secret is less than 20 characters in length, whether it is caused by human or intermittent processing error, luci won't start with a the diagnostics produced in its log file.
Clone Of:
Environment:
Last Closed: 2014-10-14 04:12:35 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2014:1390 0 normal SHIPPED_LIVE Moderate: luci security, bug fix, and enhancement update 2014-10-14 08:11:39 UTC

Description Jan Pokorný [poki] 2013-07-09 20:44:28 UTC 
1/ checking length of secret
----------------------------

luci should check if the beaker.session.secret value consists of 20+ chars
as it is highly advisable for secret key used within SHA1-HMAC [1]
(which is the case in the current deployment at the python-beaker
level when handling sessions, specifically for integrity check during
cookie-to-session mapping).

By default, the pseudo-random secret is set when luci.ini file is being
generated (upon first run of luci service) and this file is not expected
to be user-serviceable (debugging, etc. putting aside now).
The recipe to choose the secret (the whole config generation logic
comes from python-paste-script) is made so as to select 25 characters,
but does not guarantee it cannot be less (due to too many \n, \r, or =
characters in the greater input pseudo-random vector).

The intention of such a check would be to prevent both inexpert user
modification and the case of "bad luck" with pseudorandom generator.


2/ stale sessions removal
-------------------------

While sessions data are located in /var/run/luci/sessions and hence
tmpfs or some kind of data cleaner might apply here, it's not the
default nor common case.  As python-beaker documentation explicitly
states [2] (TurboGears2: [3]), it doesn't perform any sort of garbage
collection on its own.

Hence, we should consider taking this role and decrease the "entropy"
at the mentioned location.  There are more good reasons for doing so:

- further lowering otherwise extremely unprobable session ID collision
  (NB: beside custom flash2 construct and maybe tg.i18n, nothing
       actively uses sessions, so not a big deal)

- mitigating proactive sessions creation as described by TG2@SF#83 [4]
  and fixed in a newer TG2 release [5]

+ to check: cleanup on package removal.


technical choices
-----------------

Both (but independently) can be performed both in the initscript
or adding hooks into call_on_startup/call_on_shutdown lists of
LuciAppConfig in luci.config.app_cfg.

At least for 2/, I think initscript is a better choice as most
convenient is to call 'find' with appropriate -mtime argument
anyway.


[1] http://tools.ietf.org/html/rfc2104.html#section-3
[2] http://beaker.readthedocs.org/en/latest/sessions.html#removing-expired-old-sessions
[3] https://turbogears.readthedocs.org/en/latest/turbogears/session.html
[4] http://sourceforge.net/p/turbogears2/tickets/83/
[5] https://github.com/TurboGears/tg2/commit/b2656a11e4053e4465f01d0d9051f8e423fb1c15
Comment 2 Jan Pokorný [poki] 2013-08-13 13:01:22 UTC 
re 2/ stale sessions removal:

I've forgotten that this is already supported and default behavior
on both start and stop action (if one wants to suppress it, it can be done
in /etc/sysconfig/luci by uncommenting KEEP_RUNTIME_DATA=1 line.
Comment 5 Jan Pokorný [poki] 2014-06-26 15:05:00 UTC 
Test results, after fresh installation:

[first a sanity-check that we are not in conflict with standard no-touch
use case]

# service luci start
> [...]
> writing new private key to '/var/lib/luci/certs/host.pem'
> Start luci...                                              [  OK  ]
> Point your web browser to https://localhost.localdomain:8084
> (or equivalent) to access luci

# wget -S --no-check-certificate https://localhost:8084 -O/dev/null \
  |& grep HTTP
> HTTP request sent, awaiting response... 
>   HTTP/1.0 302 Found
> HTTP request sent, awaiting response... 
>   HTTP/1.0 302 Found
> HTTP request sent, awaiting response... 
>   HTTP/1.0 200 OK

# grep beaker\\.session\\.secret /var/lib/luci/etc/luci.ini \
  | cut -d= -f2 | tr -d ' \n' | wc -c
> 25

[there is no conflict as the size of implicitly generated secret is
 25 > 20]

---

[now consider that one, against the advice, edits luci.ini = configuration
 predestined by authors of luci and changes beaker.session.secret value
 to something shorter than 20 characters, thus lowering the security of
 server-tracked user session data]

# sed -i.orig \
  's|^[#]\?\(beaker\.session\.secret\s*=\).*|\1 1234567891234567891|' \
  /var/lib/luci/etc/luci.ini

# grep beaker\\.session\\.secret /var/lib/luci/etc/luci.ini \
  | cut -d= -f2 | tr -d ' \n' | wc -c
> 19

# service luci restart
> Stop luci...                                               [  OK  ]
> Start luci...                                              [  OK  ]
> Point your web browser to https://localhost.localdomain:8084
> (or equivalent) to access luci

# service luci status
> No PID file /var/run/luci/luci.pid

# tail -n2 /var/log/luci/luci.log 
> RuntimeError: Insufficient length of 'beaker.session.secret': 19
> Removing PID file /var/run/luci/luci.pid

---

[to check for off-by-one error, use length of 20, i.e. smallest valid one]

# sed -i \
  's|^[#]\?\(beaker\.session\.secret\s*=\).*|\1 12345678912345678912|' \
  /var/lib/luci/etc/luci.ini 

# service luci restart
> Stop luci...                                               [FAILED]
> Start luci...                                              [  OK  ]
> Point your web browser to https://localhost.localdomain:8084
> (or equivalent) to access luci

# service luci status
> Server running in PID 29041

# tail -n2 /var/log/luci/luci.log 
> Starting server in PID 29041.
> serving on 0.0.0.0:8084 view at https://127.0.0.1:8084

[i.e., works as expected]
Comment 9 errata-xmlrpc 2014-10-14 04:12:35 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2014-1390.html
Note You need to log in before you can comment on or make changes to this bug.