Blender security vs. usability

A bug in the Blender 3D graphics rendering program, which was recently fixed in Gentoo and Fedora, may not really be a bug at all, depending on who you listen to. Even though it has been assigned CVE-2009-3850, there is a vocal segment—perhaps an overwhelming majority—of longtime Blender users who don't want to see problems like this fixed because it can seriously affect their workflow. It is an example of the classic tradeoff between usability and security, and it would seem that usability is winning out—at least for mainline Blender development.

The problem stems from Blender's use of Python as its scripting language. A malicious script has access to all of the power of Python running as the user, so it could completely compromise the user's account. It is essentially the same problem that various macro languages in office suites have had, but those languages are generally less powerful than Python—or are at least meant to be. An attacker could put up an enticing .blend file, which promised to provide some interesting 3D representation or effect, that instead (or in addition) installed a virus, botnet client, or spam-ware. Other nasty effects are possible too, of course.

For office suite macros and other similar application scripting languages, there is often a dialog before running the code contained in a file, so that users can decide whether or not to run it. Or users can disable scripting entirely via the application preferences. For Blender, though, the default is that code inside .blend files is run, without prompting, making it easy to craft attacks if users can be enticed to open the file. That feature can be turned off in the preferences, but that doesn't affect Blender when it is running in background mode.

Background mode is a GUI-less version of Blender that is meant to be run on "render farms" (multiple machines that render different parts of the scene or animation). As might be guessed, scripts are used to control what gets rendered by Blender running in background mode, so disabling scripts by default in background mode would be fairly pointless for hardcore Blender users. But, for Blender neophytes—who are typically running in GUI mode—grabbing a file from the internet to try out the program is probably not something they expect can lead to system compromise.

The problem was discovered by CoreLabs Research in October 2009 and communicated to the Blender team, but there has been no real fix made in the mainline since then. It was reported in the bugzillas for both Red Hat and Gentoo in November 2009, but very little action was taken by either distribution until Sebastian Pipping started looking into it in April of this year. It would seem that both distributions were assuming that a fix would be coming from upstream, but none materialized.

As Pipping points out in his analysis in the Gentoo bug report, upstream is indifferent, at best, to changing the default. A long thread in the blender-committers mailing list from April 2010 makes it clear that many of the users and developers of Blender find that security fixes are just getting in their way. Part of the problem is that the "trusted source" fix made for Blender 2.50 was not fully baked and caused problems for many—including many hours of wasted rendering time.

But distributions sometimes have different priorities than application projects, and protecting the uninitiated from non-obvious ways to compromise their system is generally high on any distribution's list. So, Pipping created a patch for Gentoo and alerted Fedora about it, which resulted in the Fedora fixes released on July 13. So far, Gentoo has not put out an advisory, though the fix is in its repositories.

The fix itself is fairly straightforward, though there are a few wrinkles. Part of the problem is that Blender uses different mechanisms to control scripting depending on whether you are in GUI or background mode. So enabling scripting in GUI mode does not affect what happens with background mode and vice versa, which is one of the problems that Blender users were complaining about when 2.50 was released. In addition, the flags used for controlling scripting (-y and -Y) have changed senses between 2.49 and 2.50. So, Pipping chose -666 as the flag to disable scripting in GUI mode. Security-conscious users (or distributions) can put that flag in the .desktop file to disable scripting in GUI mode, but leave background mode (where running code from untrusted sources is unlikely) alone. Users who wish to run scripts in GUI mode can still enable that through the interface.

One does wonder why Blender doesn't just make the defaults different for the two different modes. If GUI mode defaulted to "scripting off", the problem would largely go away, without adversely affecting the power-users who are largely rendering in background mode. The minor inconvenience of turning on the feature, once, in their GUI session would seem like a reasonable tradeoff.

In the end, it is a fairly minor problem, overall, and it's hard to imagine that there are legions of attackers out there crafting malicious Blender scripts—the payoff is just too small. Targeted attacks might be more plausible, but finding targets with Blender installed and no understanding of the potential danger of scripts in .blend files might be something of a stretch. But users do not expect that opening a spreadsheet will compromise their system, and they should expect no less of opening a file in another kind of application. Since it seems that Blender isn't interested in fixing the problem, distributions are obviously right to step in and do so.