Bug 607340

Summary: CVE-2010-2235 Spacewalk (cobbler): Code injection flaw (ACE as root) by processing of a specially-crafted kickstart template file
Product: [Community] Spacewalk Reporter: Doug Knight <doug.knight>
Component: ServerAssignee: Justin Sherrill <jsherril>
Status: CLOSED NOTABUG QA Contact: Red Hat Satellite QA List <satqe-list>
Severity: high Docs Contact:
Priority: high    
Version: 1.1CC: awood, cperry, dgoodwin, doug.knight, jeckersb, jlieskov, jpazdziora, jsherril, jskrabal, msuchy, mzazrivec, paji, security-response-team, shenson, smithj, vdanen
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: 2010-10-18 13:38:33 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:    
Bug Blocks: 607662, 623772    
Attachments:
Description Flags
patch to disable execution of python code in Cheetah templates none

Description Doug Knight 2010-06-23 20:42:10 UTC
Description of problem:

Presently, any Satellite/Spacewalk user with the configuration administrator role code execute code as root on the Satellite/Spacewalk server by putting something like "<%= os.popen('/usr/bin/id').read() %>" in a templated kickstart script or variable.  The same can be done in a non-templated script by wrapping the command in #end raw and #raw directives.

Cheetah should probably not be invoked as root.  Additionally, the following checks should be made to prevent the execution of code on the server:

 * Refuse to accept templated scripts or variables that include unescaped <%= ... %>, <% ... %>, or #compiler-settings directives.
 * Prevent the use of the #end raw directive in non-templated scripts (e.g. s/#end/##end raw gobbled #raw end/ the raw scripts before writing out the kickstart template).

Version-Release number of selected component (if applicable):
n/a

Comment 3 Vincent Danen 2010-06-23 22:40:06 UTC
Hi, Jonathan.  Ok great.  Thank you for that confirmation.

Also to quickly confirm, this is limited in scope only to users of the configuration administrator role, correct?  I don't have a spacewalk or satellite install handy to quickly test this, and I suspect it will be tomorrow before this gets looked at.

Comment 4 Doug Knight 2010-06-24 00:01:46 UTC
I am not aware of any way for users that do not have the configuration administrator role modify any kickstart scripts.  So yes, I believe that to be true.

Comment 5 Jonathan Smith 2010-06-24 00:10:02 UTC
Given the multiple organizations feature of Satellite, it is possible for users who aren't trusted by the Satellite administrators to have the configuration role. We have that issue at UA, where other departments and ancillary groups have access to their own kickstart configs, but don't (or at least, shouldn't) have access to the Satellite itself.

Comment 11 Devan Goodwin 2010-07-20 11:18:45 UTC
05:41pm <@akesling> alright, so here's the plan (as per a discussion with shenson a moment ago):  set up a subprocess, which will run as a non-privileged user, once in the process lower set ulimit such that it won't be able to spawn any processes... 
05:42pm <@akesling> also go ahead and read in all snippets required (the only thing we need on disk), and then reduce the allowable file descriptors as low as 
possible (can we set that to 0?  Will it just prevent the process from 
creating _new_ descriptors, or close open ones?), and _then_ execute the Cheetah code.

Comment 12 Doug Knight 2010-07-23 20:12:40 UTC
Created attachment 434056 [details]
patch to disable execution of python code in Cheetah templates

I'm attaching a patch for cobbler that should configure Cheetah to not allow python code to be embedded.  Is there a functional requirement that is preventing us from doing something like this?

I think that configuring cobbler so that it can be run as cobbler:cobbler instead of requiring root privileges would go a long way toward mitigating security risks by itself.  Is it reasonable to disable PSP execution to address this issue, and pursue executing cobbler as a non-privileged user as a separate enhancement.

Comment 16 Jan Lieskovsky 2010-10-18 13:38:33 UTC
For what is worthy regarding addressing this deficiency in Spacewalk
systems management tool -- the relevant flaw needs to be addressed in
the versions of the cobbler package, as shipped with Fedora release of
12 and 13. Particular tracker bug for cobbler package in Fedora is here:

[1] https://bugzilla.redhat.com/show_bug.cgi?id=607662#c11

So closing this bug.