Thank you for the list of potential risks. I cannot judge how difficult it is to solve all of them and make it safe for a user to open an untrusted blend file, but it seems it is much harder than I expected.
If it is too hard, do you think it is easier to better communicate to users that opening an untrusted blend file in Blender is a dangerous operation? As the community of Blender grows, it seems that more and more people are downloading blend files made by someone they do not know, and this trend is likely to continue. Many users reasonably expect that “just” opening a blend file is a safe operation, unlike opening an executable file. The security problem here is the mismatch between user’s expectation and the actual behavior rather than the behavior itself. I hoped the actual behavior could be changed to match user’s expectation, but now I am less hopeful (although from Campbell Barton’s reply it seems all hope is not lost). Then changing user’s expectation to match the reality might be an easier way to resolve this mismatch. If users know they should handle downloaded blend files just like downloaded executable files, this will no longer be a vulnerability. On Tue, Jun 4, 2013 at 3:38 PM, Brecht Van Lommel <brechtvanlom...@pandora.be> wrote: > On Tue, Jun 4, 2013 at 7:58 PM, David Jeske <dav...@gmail.com> wrote: >> The decision at the time was that no, we do not. Also note that even >>> disabling scripts does not make Blender secure, there's dozens of >>> other ways to create malicious .blend files. >>> >> >> What are the other "dozen" ways blender could >> read/destroy/send-files-to-the-internet/install-viruses with python scripts >> disabled? > > Some examples: > > * Animation rendering, compositor file output node, point caches, etc > all write to disk. When set to certain paths they can overwrite > important files. > * Blend files can contain user preferences and those will be loaded > automatically. > * Keyboard shortcuts can be bound to arbitrary operators which can be > used to do pretty much anything. > * We don't generally keep up with the latest security fixes for jpg, > png, .. libraries. > * Auto Start for games. > * Specially crafted screen setup so user executes code in the python > console editor without noticing. > * Buffer overflows are easy to achieve with the current .blend file > reading code. > > Scripts of course make it easier, but even without that it's still > fairly easy to do damage. > > Brecht. > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers