[Bf-committers] Please turn off Auto Run Python Scripts by default

Dima Glibitsky dima.glib at gmail.com
Sat Jun 8 19:26:13 CEST 2013


I guess I'll barge in the discussion too :)
I'm not sure that I see the full picture, but here's how I see the
actual use-cases (mostly reiterating the points I've read here):

1) A user gets a .blend from somewhere or someone. Most of the time,
the user knows what kind of content is supposed to be there. Either
(s)he expects no scripts at all (e.g. it's supposed to be only a
model/scene with everything already baked), or (s)he knows there might
be some interactive elements (e.g. it's a complex rig or explicitly a
script setup). In the latter case, a honest .blend author would
(should?) warn that the .blend contains scripts and/or drivers. The
idea is, the user usually knows whether there *should* be any scripts,
and will get suspicious if they are where they shouldn't be.
1.a) The .blend came from a generally trusted source (Blender Cookie,
Blend Swap, fellow artist). If the file does something malicious, it
won't spread, since the source is known and can be quickly taken down.
1.b) The .blend is of unknown origin or came from some shady site (I
suppose that's the situation Ton is afraid of -- the proliferation of
.blends due to the Blender's popularity). In this case, the "takedown"
approach isn't really possible, but the user *should always* be
suspicious if such file contains any bit of Python code, and probably
avoid such files at all (just like with the .doc files).

So, as I see it, normal users are generally safe if they stick to
trusted sources and know whether any .blend contains Python code.
Perhaps a big warning at the Blender download page "Don't open .blends
with Python if you don't trust the source!" would help.
Of course, a targeted/random one-time attack might still cripple a
couple of blenderheads' systems, but, as it was already mentioned
before -- who would bother? (Obsessive blenderhead-hating trolls are
the only ones I can think of.)
Even if .blends would become as ubiquitous as pictures (e.g. due to 3D
printer sitting in every household, or BGE becoming more popular than
Unity), this scenario still avoids .blend-trojans/viruses if users are
properly warned and have a bit of computer common sense.

2) The case of Blender developers or similar folks who *have* to open
.blends from unknown people. They are more susceptible to the targeted
attacks, and "This file contains Python!" warning won't help them
much. But these folks are well aware that every user-submitted .blend
they open might do something bad, and they are tech-savvy enough to
take defensive measures (inspect the Python code before allowing it to
run, or even open the .blend in a virtualized environment).

Summing up: it's simply a matter of Pareto principle. "Shifting
responsibility to users" is an obvious (and easy to implement) first
step to security, which takes care of 90% of (currently purely
hypothetical) Python-based attacks. Properly forking/sandboxing Python
decreases the number of vulnerabilities, but requires a considerable
undertaking by the Blender devs. Switching to an inherently safer
language (Lua) would probably require at least as much effort, and
leave the userbase smaller and quite displeased. The question is,
where to draw the line?

Hope this makes some sense :-)
Dima.


More information about the Bf-committers mailing list