New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
command injection on the host via the xmlrpc api #141
Comments
|
On Fri, Apr 20, 2012 at 9:28 AM, jdstrand
This is an overall issue with Popen, and not something that's easy to The solution I proposed on the dev list a while back was to send that The other possible solution is for people to change all of their power |
|
Blacklisting what username and passwords can be provided via the API is not a good solution. |
|
Obviously this is an undesirable thing. That being said, a cobbler API handle can basically control what every machine on your network is going to install. It should be handed out with the same level of concern as the root password to the cobbler server. It's basically root equivalent because it has to be. That being said, this issue should still be addressed, but it's not a world ending problem considering what the API handle is generally capable of anyway. |
|
I believe this is ready to be tested, but since it's a pretty major change I'm not going to merge it in quite yet: https://github.com/jimi1283/cobbler/tree/powerpipe I've also started trying to address issue #71 with this, though I'm not sure how consistent the output from the status commands will be so I'm not sure exactly how to address the issue completely. |
|
Closing this as the new code has been merged into the master branch and should be available in the next major release. |
This is forwarded from https://launchpad.net/bugs/978999:
"It appears as if the power_system method exposed in the xmlrpc api is vulnerable to command injection through either the system handle(I am not sure about this one :-)) the provided password or the username.
The api.py code features the following:
def power_on(self, system, user=None, password=None, logger=None):
"""
Powers up a system that has power management configured.
"""
return action_power.PowerTool(self._config,system,self,user,password,logger=logger).power("on")
and in action_power.py the following code is found under the 'power' method
while the shell=False is passed (eventually) through to the subprocess.Popen method, as the shell /bin/sh[1] has been provided in front of the command passed in shell meta-characters will be actually be a problem. As far as I can tell the template cmd rendering will not strip out shell meta-characters and opens up a command injection attack vector.
[0] utils.subprocess_sp(found in utils.py) just does the following -->
def subprocess_sp(logger, cmd, shell=True):
if logger is not None:
logger.info("running: %s" % cmd)
try:
sp = sub_process.Popen(cmd, shell=shell, stdout=sub_process.PIPE, stderr=sub_process.PIPE, close_fds=True)
...
[1] To verify that this is the case you test it out -->
Comment #1:
"Without hitting the xmlrpc directly(just using a local python test script) I was able to inject shell commands by providing the following user-name:
";my command goes here ;" (when the power_rsa.template file was the selected power template)."
The Launchpad bug is currently private. I would be happy to give you access if you have a Launchpad account.
The text was updated successfully, but these errors were encountered: