A vulnerability has been discovered in Blender allowing for user-assisted arbitrary code execution. We suspect that this issue affects Blender 2.42 on all platforms.
Security Advisory
Synopsis
A vulnerability has been discovered in Blender allowing for
user-assisted arbitrary code execution.Affected packages
-------------------------------------------------------------------
Package / Vulnerable / Unaffected
-------------------------------------------------------------------
1 media-gfx/blender < 2.43 >= 2.43Description
Stefan Cornelius of Secunia Research discovered an insecure use of the
"eval()" function in kmz_ImportWithMesh.py.Impact
A remote attacker could entice a user to open a specially crafted
Blender file (.kmz or .kml), resulting in the execution of arbitrary
Python code with the privileges of the user running Blender.Workaround
There is no known workaround at this time.Resolution
All Blender users should upgrade to the latest version:# emerge --sync
# emerge --ask --oneshot --verbose ">=media-gfx/blender-2.43"
The original report can be found at Help Net Security.
36 Comments
Sooooooo, for those who security retarded like me, does that mean a hacker through that .py can enter my computer and open any blender file he wants to? I don't understand exactly what this risk means, what should I do?
From what I gather, someone could send you an .kml file, which is an XML format. You wouldn't expect it to be dangerous, but because of the eval() bug, an attacker could inject malicious code and do whatever they like.
I suspect that this issue is not limited to Gentoo though, so if you're using .kml files you should upgrade to Blender 2.43 (you can laugh, but I found I was still using 2.42 at my computer @ work to test files ;-)
I've also raised the following issue before, but I'll try it again: how secure is Blender's Python implementation, really? I'm always reluctant to open .blend files because of the possibility of embedded malicious Python in them. Is the Python implementation sandboxed, or could an attacker read all my email correspondence with aunt Mathilda and automatically post it on digg.com?
The original advisory (at http://secunia.com/advisories/18176/) does not state that this is Linux (resp. Gentoo) related, which in my opinion means that Windows users are affected, too.
Especially the ones running their system as an admin user (the majority, I presume).
Who cares about emails to aunt Mathilda when the system performs a "format c:"? ;)
@quiss42: The advisory that you're referring to is not related to this one and it was fixed in 2.40 (see http://www.blendernation.com/2006/01/07/secunia-issues-blender-security-warning/ )
@bart:
Ooops, posted the wrong link, sorry.
Nevertheless, the correct one (http://secunia.com/secunia_research/2007-40/advisory/) doesn't state anything like "this is Gentoo only" either.
AFAIK if the user has full python installed then everything can be done by python embedded in blend-file. It is the same if you run any bash-script you find in the net. One must be a little bit careful.
@quiss42: noted, thanks. I've updated the article.
@bart:
The post does no longer appear on the main page (blendernation.com)... :P
@quiss42: how odd! Somehow it was reverted to being 'unpublished'. Of course that sort of thing only happens when you post about security issues ;-)
"how secure is Blender's Python implementation, really?"
I never get these "ALERTS" stuff. Any blender file, specially if you have the full python installed, gives total control to your system. Not just the eval(). Any .blend can contain any .py that can be executed on onLoad.
An included .py (or .txt or whatever) can install (write code) itself on your disk and remove itself (unlink) from the .blend file and you would never know what happend.
To prevent this: turn off "Enable Script Links" in the Script Button window, ScriptLink tab and save this setting in your user .blend (ctrl-U). Loaded .blend files will now not automatic run .py .
To check if a .blend has scripting (or text) without opening the .blend you can use the Lib-Link feature (shift-F1). Look in the Text.
@Joeri: right, that was my fear, too. Thanks for the howto. In the case of this issue, however, you can use a 'clean' blender. Reading an infected XML file would cause problems. Even careful users might not expect that XML code could contain a virus or other malware, so this problem is a bit different from reading a .blend with embedded evil Python code.
@Bart: Joeri is definitely right. I've thought of this and tried it with a fake malware script. On Mac and Linux your home directory is completely vulnerable, and on Windows, probably the whole system (Vista might be an exception. I don't know).
As with anythig you download on the net, do it only from sources you trust. And use a virus scanner / malware blocker. It keeps you on the safe side.
If, for some reason, Blender or python tries to do something on my system it is not allowed to, my F-Secure will not only tell me, but also give me options to choose what I let them to do. So far either of those have never tried to communicate over the net or alter the startup or system files. If they someday try to do so, I will most definitely not let them.
And I'm running 2,43.
Fear is a mindkiller.
As far as I can tell the scope of this threat it for the user executing the code. Under Linux/Gentoo that should be a restricted user. Under Windows it is by default a user with full admin rights in the Administrators group. That is one of the major reasons Windows is virus/malware infested.
* ccherrett puts on his asbestose suit and prepares for the Windows boys to tell him it is because Linux is not popular enough and just wait! :)
I'd like to upgrade, but running a amd64 gentoo that won't work. Now I can chose between this issue and a version producing files I might not be able to read in a later version. :(
Is a 2.42b for 64bit users planned, which fixed this problem?
@64bituser: I'm running Suse (10.1, I believe) 64-bit and I'm able to run all the *official* releases of Blender (32-bit binaries). You've probably already tried, but if you haven't, you might attempt to run a 32-bit version and see if it works.
I'm not a Linux guru, though (as you probably guessed from my post), so if anyone has better advice, please post!
I'm somewhat at a loss as to why this script is using eval() at all, it's a known security issue in every dynamic language that has a similar construct, and furthermore, it's use is very strongly discouraged in the Blender scripting guidelines.
Sadly, turning off scriptlinks won't stop this 'security hole', the way to fix it is for the author to be more responsible and write decent code - the scope of effective uses for eval is extremely limited, and this is not one of them.
@Clean3d: I can install a 64bit version and it runs, but there is a known bug, that files written by 2.43/64bit are broken/incompatible. There even is a warning about this on every startup of blender, calling me an idiot if I continue. So I didn't play around much in 2.43 and reinstalled 2.42a instead. I could theoretically install 2.43/32bit, but I avoid installing 32bit software on my 64bit system whenever possible. I don't like the idea to have a mixed up system, especially with gentoo. Gentoo usually compiles everything from scratch, optimizing it to my system/needs, but with binary packages this is obviously not possible.
Anyway, since I don't use blender that much and never seen a .kmz or .kml file before I'll stay with 2.42a until the next version is available.
The Python script is no longer distributed with Blender, solution - get Blender 2.43
Nice to see you guys are paying attention to security. Note that we fixed this for version 2.43 and that the problem is with a SCRIPT, not something internal to Blender.
This is NOT a linux specific problem.
If you cannot upgrade to 2.43 for some reason, use the fixed kmz_ImportWithMesh.py. Available in the 2.43 bundle or from CVS.
Wow... I'm really glad you found this. I'm going to upgrade to the bug proof version as soon as I can.
"I can install a 64bit version and it runs, but there is a known bug, that files written by 2.43/64bit are broken/incompatible."
64bituser: Actually, I think the bug has existed in Blender for a long time, not just in 2.43. Version 2.43 is just the first version that actually makes an explicit warning about it, and requires a certain override in order to build properly. There's really no reason to stick with 2.42.
This is a big deal for me too, and hopefully, once Ton announces that this bug is taken care of, it should make a headline either here or on the forums.
knellotron: Didn't know that. Now I looked around and found an email dating back to March 2006 with a warning about 64bit issues. :O
http://projects.blender.org/pipermail/bf-committers/2006-March/013814.html
I still don't know if 2.43 is more broken or if my 2.42 files are already doomed, though. So let's just hope for a repair tool when this bug is fixed...
ha! finally blender is powerful enough to have serious security holes.
Yeah, the security issues of having "onLoad" scriptlinks are a bit more severe than this eval() thing I think. The "autostart" game option poses the same risk as "onLoad". The security risks of Python are the very reason that NaN disabled certain Python capabilities (the socket and file functions) in the Blender web plugin. The official reason given in the documentation is that this was done to prevent the plugin from being used as malware.
What can you do about it though? Any program you download or run on your computer could have some hidden code in it that is changing things without your knowledge. I mean, for all you know, Windows Vista could be keeping hidden records of your personal data "just in case" (records that you can't see or delete). Sony could be installing hidden rootkit programs onto your computer that make it so you can't play a CD until they've verified your right to use it.
So just be sure the Blender content you download from the internet is from a reliable source, and investigate it if you're not sure, but still want/need to use the file. (Search it from another file with Append and read the Python scripts. If it is a runtime created with Blender, extract the .blend file using the Python extractor which is publicly available on blenderartists.org and investigate the file.)
Hasn't this issue been known for some time already, a couple of weeks or so?
Shouldn't there be a watch organized for such problems so the 'general' user would be warned as soon as possible?
Shouldn't a better fix than disabling a feature of Blender and having to hand search for potential malware (hello workflow!) be found to the problem of the .py, especially since it is intended that a full Python install will become necessary on Windows starting with the next version?
Shouldn't the fixed version of the .kmz import script be somewhere more accessible to the average user than in the CVS?
Regards,
Jean
The trouble with this issue is the user.
Downloading things on your computer is as "safe" as the limits to your knowledge.
It's not a real issue with "images" but gets more of an issue with "documents".
Operating systems do their best not to help you in any way as to what kind of "document" you are downloading. Windows finds everything a possible risk, making it a useless warning.
When documents are scripts things get serious. How is a user to know that some script contains a system.exec that downloads things to exec (or eval?). So I think exec and eval should be sandboxed or off by default, making some bad written scripts useless for the people who don't know the risks.
This will become even more of an issue with the macros blender will be able to execute within a version or two.
@IamInnocent
I would imagine that it's been known only by those that actively write python scripts, not by those who just use python scripts. I wasn't aware of it and got wind of it via a GoogleAlert. The article was written immediately.
I think the best solution to these types of problems is to implement, in the Blender codebase, a filtering mechanism that simply scrubs a script's code before loading, alerting the user of any potentially harmful code...an anti-malware feature. I have something like this for Visual Basic and it works great. The potential for problems will only skyrocket when Blender gets macro capability. However, I'm sure the developers are on top of this issue.
Just to clarify my point, the filtering mechanism I mentioned would NOT have to analyze the script's code, that's ridiculous. It would only need to search for keywords like EVAL, EXEC, etc. If anything is found, a simple dialog is displayed with a textbox listing the line number and the potentially harmful keyword found on that line (options to print, save to text file). At that point it's up to the user to determine the validity of the code. If the user isn't qualified to analyze the validity of the code, then it would be in their best interest to only download from well-established and trusted sources that ensure their visitors that the files have been validated.
This is a serious issue because the more capable that Blender becomes, the more toes it will begin to step on. And, because the door is truly wide open, it COULD become an easy target because of jealousy, envy, pranks, or those whose bottom line is being effected.
Today's word is: proactive (Acting in advance to deal with an expected difficulty; anticipatory)
"If anything is found, a simple dialog is displayed"
Although I total agree with you I think in this case this is a bit more difficult.
As I understand it the harm is done in the downloading of a (model) file.
Because the language of model file is in xml it could contain instructions that can be "evaluated".
Or did I get this wrong?
( Thats like loading an image on the psp that causes an overflow and installs a hack. )
It will be pretty hard for a user to figure out that the model he is trying to view/import is actualy installing harmfull software.
@Joeri: yes, but I suppose you COULD scan all the .py files that Blender tries to load and 'securify' potentially dangerous functions such as eval().
(Note how easy it is for me to say what other people could do, being someone who's never coded a line of Blender code in his life ;-)
"Note how easy it is for me to say what other people could do, being someone who's never coded a line of Blender code in his life"
I don't think that stating an idea on how to solve an issue is the same as telling people that they should be doing something for you... Of course if nobody picks it up then we can always point to this article.
This will probably only gets solved after a large user group has been attacked and lost lots of data...
That's how these things work in my experience.
It's not an easy task to communicate to people who don't know how to check for harmfull elements how to check for harmfull elements. Just stating: "This script contains an eval() that might harm your data somewhere in the future" might not cut the cake.
Another option could be to have a security tab in the info/user settings window. With toggles "Blender: No automatic script execution (scriptlink)", "Python: No exec", "Python: No eval()", "Macro: No delete", "Macro: No save". Etc, all active by default :)
Joeri, I agree with you that it is difficult to communicate how to avoid these issues to most people. I use Blender mainly as a game programmer, and I'm fluent in Python, but I still have trouble reading other people's scripts sometimes. Beyond that, there could be security issues other than eval() and exec() that we haven't considered. What about Python's socket capabilities, or functions which execute commands in the web browser?
To be honest, I don't have a real solution to the problem. I need execv() in my games in order to set up display options menus that will run the blenderPlayer on the game file with appropriate flags. If the exec() functions were disabled by default (and especially if they were take out of Blender completely), then my games would not function properly in other people's Blenders. And what about the issue of the blenderPlayer? Should the functions be disabled there as well? And how will you protect someones computer when they have a full Python installation with a Python Path specified? Even if Blender disabled the functions in its Python package, the script would revert to the standard Python installation and wreak its havoc. (BTW, not everyone with Python Path specified is a Python Guru. Some people do it just to be able to use special scripts, like Ter2Blend for example.)
Like I've said, anything that you download can be hazardous to your computer, and sometimes there just isn't much knowing ahead of time. I don't know if there is a real solution to this issue, but I think that the warnings system is perhaps a good start.
I think there are several levels of security, each with their own risk.
Downloading and running a game will always be a risk, blender used or not.
But if downloading and using a model can start being a risk ( because of poor programming ) then that's a bridge to far.
I wonder if simply running Blender in a "sandbox", when testing unknown scripts, would be a surefire way to eliminate any potential threats? Could the solution be that simple? There's a free utility called Sandboxie that could easily do this, if this would be a good solution.
I guess it would. But why not run Blender in a sandbox by default, unless you need a script which you *know* will need filesystem or network access and which you trust? That would bring us back to Joeri's suggestion of including options to disable such access and turn them on by default - I really like that idea.