[Bf-committers] Blender security paranoia
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
> 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
> 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.
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers