[Bf-committers] Blender 2.5 malicious scripting

[Aurel W.]

We could do some whitelisting for script objects in a blendfile. Like
if there are any scripts, warn the user and ask if the scripts should
be allowed for the session or permanently. Then take the source and
compute the SHA2 hash and store it in the users config.

Another feature which would help, is a quick way to export all embeded
scripts to files, so checking them for malicious code is straight
forward. This is an option, which should be avaible from command line,
to be able to check with external programs/scripts.

Aurel

On 23 February 2010 12:28, Campbell Barton <ideasman42 at gmail.com> wrote:
> Some kind of "Do I trust this blend file" option on file load would be good,
> especially for looking at files in the bug tracker. its crazy to think
> how easy it would be for someone to wipe my home dir or upload my
> firefox passwords to an FTP.
>
> Each OS can deal with scripts differently, on *nix for eg, we can use
> /usr/shared/blender-2.5/scripts this means at least they cant be
> tampered with.
>
> On Tue, Feb 23, 2010 at 11:33 AM, Benjamin Tolputt
> <btolputt at internode.on.net> wrote:
>> <snip alot of details & suggestions>
>>
>> It is my impression that to properly secure a machine against malicious
>> Python scripts - you would need to build a sandbox. This is not possible
>> with CPython (there are known methods around all the serious sandbox
>> attempts I could find) and this is what is used by Blender. Not only
>> this, but a solid portion of the use-cases for Blender require access to
>> files on the user's hard-drive (for import & export purposes). As such,
>> sand-boxing Python is not really the solution either.
>>
>> In my opinion, the security of Blender in this regard is down to two
>> things. Firstly, opening a Blender file should not run embedded scripts
>> until the user has been warned/asked about it and, secondly, there needs
>> to be some user education on the safety aspects (or lack thereof) in
>> running unknown scripts. Python is simply too flexible (and hence
>> "insecure" in the current context) to do anything else.
>>
>> On a side note: the only properly secure method of sand-boxing Python
>> seems to be a complicated use of PyPy-C and running all non-safe
>> accesses through a separate "sandbox" process. It is not really a
>> language/platform designed with security in mind. One of the reasons I
>> would have liked a move to Lua or similar language where one can lock
>> down the script's environment. Totally understand why it didn't happen
>> though (the momentum of existing skills & scripts is hard to push aside,
>> even for a better solution).
>>
>> --
>> Regards,
>>
>> Benjamin Tolputt
>> Analyst Programmer
>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>
>
> --
> - Campbell
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>