[Bf-committers] Blender security paranoia

Erwin Coumans erwin.coumans at gmail.com
Wed Mar 24 14:46:46 CET 2010

 >>leaving auto-execute on.

You meant switching it on?

As far as I know, auto-execution of python scripts when loading .blend  
files is turned off by default in SVN trunk.

And I'm glad it is.

On Mar 24, 2010, at 6:30, Roger Wickes <rogerwickes at yahoo.com> wrote:

> So, a little logic to this paranoia, and hopefully a process of  
> elimination. Also,
> confirmation of what security we do have in place already, to make  
> everyone rest easier.
> I agree that while however slight, the chance of having your PC  
> wiped by a malware script
> is troubling because there is no recourse against the evildoer. That  
> there is money made
> from it is no doubt. I discovered that I had malware sending my hard  
> drive contents to Russia.
> We can all agree that having a pop-up stop and force you to
> confirm automatic script
> executionisn't automatic script execution
> and therefore defeats the purpose of the option in the first place:)
> So if your all your scripts, like all programs installed on your PC,  
> are all from trusted sources,
> you can enable auto-execute. Just like when I start OpenOffice, my  
> OS does not popup and
> ask me if I want to execute OpenOffice. That would be just as  
> painful as the current
> set of delete confirmation popups in Vista.
> The only way for a script to become part of the blender install is  
> for a trusted dev
> to accept the patch. There has never been a case where malware patch  
> has been
> accepted, and highly unlikely to ever be. Commit rights are only  
> granted to trusted devs.
> That leaves the possibility of someone hacking SVN, someone with  
> commit rights, or
> somehow hacking into the blender.org or graphicall.org servers and  
> inserting a bad
> script (or compiled C code) without detection. That is a server  
> security issue, not a sandbox problem.
> There is both physical access and username/password security  
> protecting them.
> So that leaves someone posting a script in like BA that no one knows  
> and it may
> or may not do something bad. In that case, you are getting a program
> from an untrusted source. You can be a trusting person and just run  
> it, or,
> since you got a new blend file from an untrusted source, you disable  
> auto
> script
> execution and open it up. Look at it, see what it does, and execute it
> if you like.
> Just as likely is someone building an evil Blender and posting the  
> build somewhere for people
> to download. That is the general problem with software available for  
> the internet,
> and the only way to stop that is user education, unexpired  
> certificates, and OS protection.
> If it is malware, community response will be immediate and vengeful,  
> for either Blender exe
> or scripts. AFAIK scripts cannot be signed; they are text files.  
> Perhaps pyc files can be, but
> distributing source is the practice.
> That really leaves only one remaining possibility. I think you guys  
> are worried about the noob
> that is one of the very first to find the malware, and then proceeds  
> to
> run un-human-readable stuff (compiled code, pyc files) on their PC,
> or blindly runs source py files and does not read them or cannot  
> understand them,
> or downloads and opens a blend file, leaving auto-execute on.
> That is the same issue as downloading any kind of
> program and running it; it is impossible to protect a user from  
> their own stupidity.
> Therefore, there is nothing further that can reasonably be done, and  
> no additional processes
> or procedures need to be implemented.
> Therefore, the safest route is to ship Blender with auto-execute  
> turned off, and let the user decide
> to turn it on, or instead, run scripts after reviewing them. Either  
> way, the process and existing
> security measures guard the pipeline and the contents of the pipe.
> --Roger
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

More information about the Bf-committers mailing list