[Bf-committers] Blender 2.5 malicious scripting

[j.bakker at atmind.nl]

Hi all, 

yesterday there was a discussion on security aspects of Blender. Especially
in the area of scripting. I am no devils advocate, but there are some
aspects that has to be discussed.

I have done a quick security check on the next parts. The security risk is
that virus-makers can place malicious scripting in blend files on blendswap
or whatever. what can be loaded by blender users and will do harm to the
user. I don't think it is much different than Blender2.49 except that in
blender25 we deliver a full blown python api, and as I read correctly
Campbell has some uncommitted code also has some risks :)

As blender will be used more professional I think we should have an idea of
these risks and should have a first comment or implementation against
malicious scripting. I did the next part in a short time, so this certainly
is not complete. I will try to talk to a security expert on the subject. 

I have performed the next tests 
1. can an autostartable script influence the objects in a different blend
file.
tactic:
Create a blend file with an automatic internal script file. inside this
script a timer is created what waits till other blend files are loaded.
When this happens it will modify this blend file and automatically save.

results: a python threaded timer is not killed when new file is loaded.
could change new loaded file without the knowledge of the user. the timer
is only killed when quitting blender.

2. can an autostartable script do something that influences all blend
starts.

tactic:
can an autostartable script create a different script inside the scripts/ui
or scripts/op. This generated script is always be loaded and executed when
blender is loaded.

result: is possible.

3. can an autostartable script make blender unusable

tactic:
Can an autostartable script override UI scripts.

result: ui scripts can be overwritten and will make blender unusable when
reloading scripts or restarting blender
 
4. can an autostartable script do something outside blender

tactic:
create an autostartable script that will delete a file owned by the user.

result: is possible

all tests test have failed and the next questions raise:
Q1. Who is responsible to protect the user from their doings or, what to
what part are we responsible for?
Q2. On what level and how do we act on this? 

Solutions (these are not choices):
S1. make script directories by default not writable (shall be done by the
package maintainer). For un-experienced users this can solve test 2 and 3.
Users who customized scripts will 

S2. other software tooling uses security zones. (non-secure, normal, heavy,
max). non-secure it the responsible of the user. normal: a question is
asked. heavy only certified locations will be executed. Max, only certified
scripts will be executed. 

S3. make some python calls not possible for un-certified scripts. (like the
android platform)

S4. black vs whitelisting, but no API calls to them? should be a challenge
:)

malicious.blend can be retrieved on demand.

Regards, 
Jeroen.

--------------------------------------------------------------------
mail2web.com - Microsoft® Exchange solutions from a leading provider -
http://link.mail2web.com/Business/Exchange