Bug 849210 - (CVE-2012-3503) CVE-2012-3503 Katello: Application.config.secret_token is not generated properly
CVE-2012-3503 Katello: Application.config.secret_token is not generated properly
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20120821,reported=2...
: Reopened, Security
Depends On: 848905 849682
Blocks: 849712
  Show dependency treegraph
 
Reported: 2012-08-17 13:31 EDT by Kurt Seifried
Modified: 2015-08-20 11:17 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-26 03:43:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kurt Seifried 2012-08-17 13:31:05 EDT
Lukas Zapletal (lzap@redhat.com) found a flaw in the generation of the
Application.config.secret_token value. This value is used in the file
/usr/share/katello/config/initializers/secret_token.rb to provide a secret
token when session cookies are generated for user sessions within Katello.

Specifically a static key with a value of:

f466b184ef680822293d7130f57593a7087a34b5de0607c64d1ceb66fcac4dce\
6810a6f176feba3fbbf2489de93c0918397c0c275996eb476b2fa6079ab849c1

is included by default. The spec file for Katello includes commands to generate a new key:

NEWKEY=$(</dev/urandom tr -dc A-Za-z0-9 | head -c128)
sed -i "s/^Src::Application.config.secret_token = '.*'/Src::Application.config.secret_token = '$NEWKEY'/" \
    /usr/share/katello/config/initializers/secret_token.rb

however this was erroneously placed in the "postuninstall" section, which is 
run when removing Katello from the system). Thus a new secret token is not 
created and all affected Katello installations have the same secret token 
value. 

As a temporary workaround sites can create a new token using the command:

cat /dev/urandom | tr -dc A-Za-z0-9 | head -c128 ; echo ""

and then manually editing 
/usr/share/katello/config/initializers/secret_token.rb and replacing the 
existing "Src::Application.config.secret_token" value with the new one. Once 
the new value is inserted please restart Katello for it to take effect, you 
will of course be prompted to login again as your session will no longer be 
valid.

To test if you Katello installation is vulnerable simply query the rpm file:

rpm -qp --scripts katello-common-1.0.2-1.el6.noarch.rpm 
rpm -q --scripts katello-common 

if vulnerable you will see the NEWKEY generation in the "postuninstall" section:

postuninstall scriptlet (using /bin/sh):
#update config/initializers/secret_token.rb with new key
NEWKEY=$(</dev/urandom tr -dc A-Za-z0-9 | head -c128)
sed -i "s/^Src::Application.config.secret_token = '.*'/Src::Application.config.secret_token = '$NEWKEY'/" \
    /usr/share/katello/config/initializers/secret_token.rb

To check an existing installation you can also view the contents of the 
/usr/share/katello/config/initializers/secret_token.rb file and ensure the
"Src::Application.config.secret_token" is not the above listed value.
Comment 3 errata-xmlrpc 2012-08-21 16:13:33 EDT
This issue has been addressed in following products:

  Red Hat Subscription Asset Manager 1.1

Via RHSA-2012:1187 https://rhn.redhat.com/errata/RHSA-2012-1187.html
Comment 4 errata-xmlrpc 2012-08-21 16:14:06 EDT
This issue has been addressed in following products:

  CloudForms for RHEL 6

Via RHSA-2012:1186 https://rhn.redhat.com/errata/RHSA-2012-1186.html
Comment 5 Jordan OMara 2013-01-22 16:00:44 EST
Patched upstream:

https://github.com/Katello/katello/pull/1434
Comment 6 Og Maciel 2013-02-01 15:52:38 EST
[root@tigger ~]# rpm -qp --scripts katello-common-1.0.2-1.el6.noarch.rpm
error: open of katello-common-1.0.2-1.el6.noarch.rpm failed: No such file or directory
[root@tigger ~]# rpm -q --scripts katello-common
preinstall scriptlet (using /bin/sh):
# Add the "katello" user and group
getent group katello >/dev/null || groupadd -r katello -g 182
getent passwd katello >/dev/null || \
    useradd -r -g katello -d /usr/share/katello -u 182 -s /sbin/nologin -c "Katello" katello
exit 0
postinstall scriptlet (using /bin/sh):
#Add /etc/rc*.d links for the script
/sbin/chkconfig --add katello
/sbin/chkconfig --add katello-jobs

#Generate secret token if the file does not exist
#(this must be called both for installation and upgrade)
TOKEN=/etc/katello/secret_token
test -f $TOKEN || (echo $(</dev/urandom tr -dc A-Za-z0-9 | head -c128) > $TOKEN \
    && chmod 600 $TOKEN && chown katello:katello $TOKEN)
preuninstall scriptlet (using /bin/sh):
if [ $1 -eq 0 ] ; then
    /sbin/service katello-jobs stop >/dev/null 2>&1
    /sbin/chkconfig --del katello-jobs
    /sbin/service katello stop >/dev/null 2>&1
    /sbin/chkconfig --del katello
fi
posttrans scriptlet (using /bin/sh):
rm -f /var/lib/katello/Gemfile.lock 2>/dev/null
/sbin/service katello condrestart >/dev/null 2>&1 || :


Token included in /etc/katello/secret_token is not the hard-coded value mentioned here.
Comment 7 Kurt Seifried 2013-07-26 03:43:15 EDT
The Red Hat Security Response Team has rated this issue as having low security impact in CloudForms 1.1. This issue is not currently planned to be addressed in future updates.

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