There are several security issues for python plugin code

[Oleksandr Balenko]

1. Analyze plugin code of fuel-plugin-xenserver-3.1-3.1.2-1.noarch.rpm with bandit tool
https://wiki.openstack.org/wiki/Security/Projects/Bandit

Actual result:

There are several security issues http://paste.openstack.org/show/wzjqm2PKyPxauAqKUxcv/

Expected result:
No security issues.

[Bob Ball (bob-ball)]

17:26:06 >> Issue: [B411:blacklist] Using xmlrpclib to parse untrusted XML data is known to be vulnerable to XML attacks. Use defused.xmlrpc.monkey_patch() function to monkey-patch xmlrpclib and mitigate XML vulnerabilities.

I am not aware of a way this could be exploited. The XML is all returned (and created) by XAPI, so is not from an untrusted source. Even if a plugin were to return some XML content, this would be wrapped by XAPI. The caller of XenAPI.py would potentially be affected, but the code in XenAPI.py should not be exploitable.

17:26:06 >> Issue: [B404:blacklist] Consider possible security implications associated with subprocess module.
17:26:06 >> Issue: [B603:subprocess_without_shell_equals_true] subprocess call - check for execution of untrusted input.

We’re not invoking subprocess with any user-supplied input; I therefore can't currently see a way for this to be exploited?

17:26:06 >> Issue: [B108:hardcoded_tmp_directory] Probable insecure usage of temp file/directory.

As this is running in the deployment context, this is by definition being run by an administrator. I believe there should not be any possible access (other than by a known-trusted administrator) to the compute nodes during deployment, therefore I believe this shouldn’t be exploitable.

17:26:06 >> Issue: [B506:yaml_load] Use of unsafe yaml load. Allows instantiation of arbitrary objects. Consider yaml.safe_load().

Since we are loading a yaml file either written by MOS or modified by an administrator, I think this should be considered a trusted source.

We have already started on a patch, in public, to address some of these issues:
https://review.openstack.org/#/c/326802/

As we are not aware of any way these issues can be exploited, I suggest we remove the private label and work on this in the open?

[Oleksandr Balenko (obalenko)]

ok, make the issue as public.

[Irina Povolotskaya (ipovolotskaya)]

Bob, please specify the Closes-Bug tag in your commit message here: https://review.openstack.org/#/c/326802/
and mark the bug status as In Progress.
thanks

[Bob Ball (bob-ball)]

John will update the commit message to reference this bug.