OpenStack represents one of the largest open source projects both by lines of code and number of active contributors. Although its sheer size represents tremendous growth, it also presents a unique security challenge: How can you find existing security defects in a code base of that size and prevent the introduction of new defects?
In this article, we’ll introduce a common Python security issue, show how to set up Bandit, run Bandit to find the issue and then show the proper process for reporting a security bug.
Let’s say we’re implementing a simple application programming interface (API) that stores files for users. We allow users to be created with a simple API:
POST /v1/users - Create a user (username, password)
When our application receives a request, it creates a new directory to store the user’s files:
subprocess.Popen('mkdir %s' % user_name, shell=True)
Easy enough, right? What happens if somebody creates the following user?
'something; rm –rf /'
Since subprocess is using a shell to execute the command (because of the shell=True parameter), the shell interprets “;” to be a separator character between two commands: the intended directory creation and the unintended attacker-supplied command. We use “rm” here as an example, but in reality the command could be anything the attacker chooses. This attacker-supplied command will be run with the privileges of the application.
Bandit to the rescue
But there is good news. Bandit can find this issue. The easiest way to install Bandit is to use the “pip” command to install from PyPI:
pip install bandit
That’s it! We can now run Bandit:
bandit –r path/to/example
>> Issue: [B602:subprocess_popen_with_shell_equals_true]
subprocess call with shell=True identified, security issue.
Security: High Confidence: High
6 subprocess.Popen('mkdir %s' % user_name, shell=True)
Bandit quickly recognizes this as a high-severity issue and shows the offending code. Each plug-in, such as the “B602” plug-in shown above, is explained in great detail in the included Bandit documentation. In many cases, quick references to resources that show the safer way of performing these actions are included in the links section.
Reporting security bugs in OpenStack
Security issues should be responsibly disclosed. Before disclosing security issues though, please take the time to understand the impact. Although reporting instances of insecure coding practices is useful for maximum value, it’s best to file a complete report. If possible the report should include things like:
- Analysis of the program flow
- The source of any relevant values (config file, user input, etc.)
- Locations input has been sanitized
- Mitigating factors
If you feel like you may have found something but require assistance with triage, please ask for assistance in the #openstack-security channel on IRC. It’s important not to publicly disclose details of possible security issues so please don’t put details in the public channel.
Once you’ve properly triaged and understood the issue, the next step is to file a “private security” bug for the relevant project in Launchpad. You should see an option to mark the bug as a “private security” bug. Please choose this.
After reading this, you should be familiar with a basic security issue in Python code, be able to install Bandit and use it to find this (and other) issues, know the steps required to triage a security bug, and be able to responsibly disclose security issues for OpenStack projects.
Another really good resource for developers is the "Secure Development Guidelines" which are aimed at explaining common security issues and the safer way to perform common actions.
Bandit is actively developed and maintained by the OpenStack Security Project. If you have questions or you’d like to contribute to Bandit, please send an email on the OpenStack-dev mailing list (use the “[bandit]” tag) or drop by our IRC channel #openstack-security on Freenode.
Travis McPeak, who currently works at IBM, is a member of the OpenStack Security Project. This article first appeared in the print edition of Superuser magazine, distributed at the Austin Summit. If you’d like to contribute to the next one, get in touch: [email protected]