A look at security in Blender

A few moons ago security researchers at Cisco made waves in the Blender community after disclosing a number of vulnerabilities that could allow an attacker to run arbitrary code. All the of them were fixed by 2.79a but it’s still possible to make Blender run arbitrary code. In fact, it has always been possible.

Beyond the exploits

Blender embeds a full Python interpreter with no restrictions. All of Python is available, including the os and subprocess modules. You can even install PIP for Blender’s Python and install third-party libraries with it. This lack of limits is necessary since Blender uses Python scripts for quite a few things:

  • Setting up the UI layout
  • Drivers (animation)
  • The game engine (pre-2.8, RIP in 2.8)
  • Keymaps
  • Operator presets
  • Addons
  • Actual python scripts (of course)

To be clear: unrestricted access means the same level of access to the system and files that you (or the other applications you run) have. Any of these scripts can access your files, read them, delete them, etc. Almost a primordial soup for malware.

“As far as I’m concerned, opening a file with Blender should be considered lie opening a file with the Python interpreter, you have the trust to the source it is coming from.”

Brecht Van Lommel

This issue isn’t unique to Blender of course, nearly all CG applications run scripts of some kind in these and other ways. Hold the tinfoil hats though! There are no know attacks or cases of malware using Blender, and protecting yourself from any future or possible attacks isn’t hard.

Let’s see how and when Python code gets run

Some code runs automatically when you open Blender or a blend file while some code has to be run manually (by pressing a button in an addon, for example). 

Drivers are run everytime the current frame changes. That includes scrubbing through the timeline, rendering and opening a blend file (since it has to set a current frame). Of course if a driver is disabled it won’t run.  Scripts in text blocks can be run in both ways. If it has the register option toggled on the script will be run when you open the blend file, otherwise it can be run manually by clicking the run button (or calling the run operator through Python).

The active Keymap is run everytime you start Blender, some of them (like the Maya keymap) will register new operators to help create a specific workflow. Addons will run code everytime you open Blender to register their panels, properties, operators, etc. This part of the code is always located in the register() function in the __init__.py file (in case you want to peek). Addons will also run another function when being disabled, the unregister() function. And of course, addons will also run code when you use them.

Finally the code to setup the UI is run constantly through a timer. However those scripts are bundled with Blender and you’ll never have to touch them. In case you’re wondering, themes are XML files which is a data format so they have no code.

Staying safe

Blender can prevent blend files from auto running python code and, in fact does it by default. When you load a non-trusted blend file that wants to run code you will be prompted to authorize it by reloading it as a trusted file (or not). This will prevent drivers and scripts set to register from executing, however this can be annoying when working with one’s own files so it’s common to set the default to always allow auto-run and forget about it but doing this opens you to attacks embedded in blend files.

We can find a balance between security and convenience by allowing auto-run but also setting an excluded folder (or several) to keep unsafe blend files. Files in the excluded folder will not be trusted and won’t auto-run. Both the Auto Run Python Scripts  and Excluded Folders settings can be found in the File tab of the User Preferences. It’s a good idea to set this to your downloads folder, but you can also add other directories.

(“tmp” is my downloads folder)

That’s only the first line of defense though, you could still allow a script to run and turn out to have malicious code. That’s why it’s important to consider where you got the blend file you’re opening. Blendswap, the Blender Cloud and sites from well-known blenderheads are always a safe bet. Be cautious when opening blend files from BlenderArtists, BlenderExchange or any other third party site/forum.

(Oh yeah , this site is a safe bet too!)

When you open one of those files and it tries to run some code consider whether it should really be doing that. Is the file supposed to have a rig? Is it supposed to be an animation? Did the author mention it had drivers or some other script? Try giving it a closer look before allowing scripts.

The same applies when adding third-party keymaps or presets, though I haven’t seen many of those. A final tip: if you find that some blend file or keymap has malware, please report it! Talk about it in the Blender community through the forums, twitter or IRC. That way, if malware ever shows up we can catch it early.

If all this talk about security has peaked your interest, check out this presentation by Ralph Echemeddia as well as the classic ”Hacking Hollywood” by Nick Freeman.