Bug 607340 - CVE-2010-2235 Spacewalk (cobbler): Code injection flaw (ACE as root) by processing of a specially-crafted kickstart template file
CVE-2010-2235 Spacewalk (cobbler): Code injection flaw (ACE as root) by proce...
Status: CLOSED NOTABUG
Product: Spacewalk
Classification: Community
Component: Server (Show other bugs)
1.1
All Linux
high Severity high
: ---
: ---
Assigned To: Justin Sherrill
Red Hat Satellite QA List
: Security
Depends On:
Blocks: CVE-2010-2235 space12
  Show dependency treegraph
 
Reported: 2010-06-23 16:42 EDT by Doug Knight
Modified: 2012-03-06 05:12 EST (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-10-18 09:38:33 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)
patch to disable execution of python code in Cheetah templates (3.95 KB, patch)
2010-07-23 16:12 EDT, Doug Knight
no flags Details | Diff

  None (edit)
Description Doug Knight 2010-06-23 16:42:10 EDT
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 18:40:06 EDT
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-23 20:01:46 EDT
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-23 20:10:02 EDT
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 07:18:45 EDT
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 16:12:40 EDT
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 09:38:33 EDT
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.

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