Vulnerabilities in Blender: What’s the Impact?
Earlier this week security researchers from Cisco disclosed a number of vulnerabilities in Blender that can theoretically lead to security risks when opening .blend files. There was a bit of an uproar as they presented in such a way that it suggested the Blender Foundation is not interested and will not act, but it turns out this is not the entire story.
Let’s start at the beginning. Talos, Cisco’s ‘Intelligence Group’, wrote:
Today, Talos is disclosing multiple vulnerabilities that have been identified in Blender. These vulnerabilities could allow an attacker to execute arbitrary code on an affected host running Blender. A user who opens a specially crafted file in Blender that is designed to trigger one of these vulnerabilities could be exploited and compromised.
Talos has responsibly disclosed these vulnerabilities to Blender in an attempt to ensure they are addressed. However, Blender has declined to address them stating that “fixing these issues one by one is also a waste of time.” As a result, there currently is no software update that addresses these vulnerabilities. Additionally, Blender developers believe that “opening a file with Blender should be considered like opening a file with the Python interpreter, you have [to trust] the source it is coming from.”
The article then continues with a quote from Brecht (one of many on the Blender Developers threat about this issue) – presenting it in such a way that the Blender Foundation would not be interested in solving security issues.
There are of course hundreds of developers in the Blender community and they don’t represent the foundation – only Ton does. Even though he has been in touch with Cisco about these issues for weeks, they neglected to quote him and went for a random inflammatory statement instead.
Ton wrote about this:
The quoted developer is giving his own opinion here. If you look at all discussions, we took their reports very seriously and spent a lot of time on it already. I don’t think it’s fair to publish it with such a negative accusation. I’ve asked Cisco to correct the text.
Meanwhile: the issue has been recognised and we hope we can tackle it with Cisco’s help.
Brecht in turn responded with:
Right, I am not speaking for the Blender Foundation. Nor am I saying vulnerabilities should not be taken seriously, but rather that if anyone is serious about making loading arbitrary .blend files in Blender secure, fixing these issues reported by TALOS will not get us much closer to that. Users should understand that loading untrusted scene files in Blender and similar CG software is not secure, and not get the false impression that software developers addressing the occasional reported issue means it is secure.
For background on security and arbitrary code execution in CG software in general, see this article.
What is the actual issue here?
After talking to Ton, what I understand is this: It is theoretically possible to craft a malicious .blend file that causes ‘overflows’ that can lead to the injection of code that would then be executed. In other words, just opening a .blend file could lead to data theft or corruption on your local system. This is NOT the same as Python scripts that can also access local data – when opening a .blend file that contains any script you have to manually activate them.
This risk is similar to downloading software from an untrusted source and executing it, even though you might not recognise it as such – after all, a .blend is not an ‘executable’.
I’d like to stress that while this is theoretically possible, no ‘proof of concept’ implementation of such exploits is available to date.
How should you protect yourself?
As always, when downloading anything from the web you should apply a good amount of common sense: did an unknown source email this to you, or post this online? What’s the reputation of the creator?
Answer these questions first before opening anything – Blender content is no different.
What will the Blender Foundation do?
The current consensus seems to be that, yes, there are security issues in Blender and they should be addressed. However, it is not clear how big a threat these are, and how they should be prioritised. After all, the Blender community is small fry compared to larger audiences like Windows users etc, and it’s not likely that hackers will be going after them on a large scale.
The fact that these issues have been identified also does not mean that these are actually the biggest risks – other, harder to identify issues might be more important to address first. Solving this initial list of 20 issues could lead to a false sense of security, more careful research is needed.
The big dilemma is of course how many resources to spend on this. The 2.8 project is behind as it is, and working on these issues would introduce an unknown additional delay.
It says it all –
“After all, the Blender community is small fry compared to larger audiences like Windows users etc, and it’s not likely that hackers will be going after them on a large scale.”
So i’d opt for keeping work on 2.8
I agree. Hackers have no interest in a “small community”. It would be a waste of time for them to address them. But if the vulnerability is easy to exploit, then there should be at least some security warnings before executing a python script inside blender which contains potential dangerous operations.
Those issues are not due to pyhton scripts. Loading auto-running script is already a user controllable choice. This can happen just by loading some kind media file, or old blender files, or even newer ones, using some commoncommand/feature.
Yep. This warning could be an add on, that runs only in your computer, if you activate it.
That’s a fallacy. A well-crafted blend file would be enough to infect a whole 3D graphics company, including potentially a renderfarm or two. Then they could use these computers as bots or mine cryptocurrency or do even more evil stuff.
Small fry has been targeted, and they paid dearly.
I currently work at the marketing department on a financial services company. Even tough my team is mostly trained in blender (we worked independently before being incorporated into the company) we had to switch to paid alternatives such as Maxon C4D bc the security flaws involved were too big to play with. I deeply consider Blender a much better software than C4D but when security is at stake, we must always play safe. Okay, Blender community may be a small fry but it only takes one person with bad intentions within the company to mess the whole thing.
Blender 2.8, we need it
maybe they can spy out our best renders then and make some illegal screenshots. the largest danger of getting malware and spied on in the internet are definately blender files. i hope you don t spend the blender cloud money on sh… like this. cisco can go home.
Some people just can’t handle what is made from bottom up.
There is some clear evidences here that this security guys don’t know how reputation is built in the Blender community.
For the newcomers, that is a very nice advice, (Thank you Bart!):
“How should you protect yourself?
As always, when downloading anything from the web you should apply a good amount of common sense: did an unknown source email this to you, or post this online? What’s the reputation of the creator?
Answer these questions first before opening anything – Blender content is no different.”
I never liked Cisco anyway.
The take away for me on this is that Blender is now big enough and main-stream enough that security companies feel they should take notice of it.
It’s a shame the article seemed biased towards the alarmist, but it’s positive that they looked at all!
@Bart Veldhuizen This is really biased article as @Ammusionist mentioned. You shouldn’t take such a strong stance writing a news that is pretty important. You shouldn’t take any stances writing news or any other informational articles it’s kinda Journalism 101.
Back to the case. I’m strongly against what Brecht said and what Ton wrote to Cisco:
“That being said, it’s not something we ignore, but the investment of resources (using volunteers?!) in fixing this, would not really justify the benefits.” – Ton.
How do the hell you can compare user safety to justifying benefits? It’s like from the “Fight club”:
“A new car built by my company leaves somewhere traveling at 60 mph. The rear differential locks up. The car crashes and burns with everyone trapped inside. Now, should we initiate a recall? Take the number of vehicles in the field, A, multiply by the probable rate of failure, B, multiply by the average out-of-court settlement, C. A times B times C equals X. If X is less than the cost of a recall, we don’t do one.” – The narrator.
And this also sums up what Brecht said. Blender has vulnerabilties but (!!!) other software also. Our car is not safe but other cars too! You should take care of yourself and don’t blame faulty system. After all, you don’t need to use it, right?
I can’t resist to use another metaphor (fresh one):
Google Zero: – Hey Intel, you have problem with Meltdown/Spectre!
Intel: – Yeah, but AMD too.
AMD: – And what? ARM also has it.
All of them: Let’s do nothing, this would not really justify benefits.
In the spirit of Brecht comparison (check the presentation he posted from 2011) to big players. For any of them saying that patching vulnerabilities doesn’t justify benefits would be PR nightmare.
It is savest not to drive a car at all ! If you can’t drive then don’t do it.
It is good to be aware of the riscs. But that’s the case for all you do on the internet. It’s all a matter of knowing the riscs and the impact of a vulnerability. And sometimes those security guys make a fuss over nothing.
And as stated before, very proud of the attention given to Blender.
@MAR and if I can drive a car but it has flaws which manufacturer call minor and won’t fix them because everybody should be theoretically safe? Who than is responsible for accident? I and those bad trees beside the road?
To start off, Blender 3D is not a car.
The meltdown/spectre reference isn’t really applicable either, as Blender’s vulnerabilties allow the execution of arbitrary code whereas meltdowns/spectre gives hackers access to the kernels and other process’s protected memory.
Not that I’m saying the vulnerabilties shouldn’t be fixed, all I’m saying is people need to be more understanding that the Blender Foundation doesn’t have the resources to immediately deal with 20 big issues just dropped on them.
I fully agree.
Luke: don’t lift out quotes from me without context. Cisco dropped 20 issues on our desk. That’s what I responded to. Good and sensible security is always a user benefit.
Also keep in mind that you can safely use Blender for all your work. It’s only opening untrusted files that has a *tiny* security risk (with the recent publicity it’s a bit more).
To go back to the car analogy: you can use the car safely, but if you borrow your car to others they can sabotage it in a way that makes driving for you unsafe.
For a car rental service that’s essential, for the average driver it isn’t. So… what to do. Not simple, right?
I’m no expert in coding or programming here, so keep this in mind, but:
Cisco actually specified where are the problems they found, and how to solve them. Is it hard to change the code accordingly?
@Ton Roosendaal: Ok, let’s be fair, your full reply to Cisco:
“Sorry for being unclear. I mean that the situations are not practical; as in, created in a practical situation of using Blender.
The vulnerabilities are “theoretical” as in “unlikely to happen, only by purposed sabotage”.
That being said, it’s not something we ignore, but the investment of resources (using volunteers?!) in fixing this, would not really justify the benefits.
Would you help us fixing this?”
Does this change anything? I believe not.
I’m myself Blender Stack Exchange user (LukeD there) and that’s why I’m so concerned about this topic. Many questions from BSE couldn’t be answered without downloading files provided by users. This is only way by now I can contribute to the wonderful Blender community as a non-developer and I’m trying as hard as I can to be able to “pay debt” for such a great piece of software.
We are standing on different sides of the fance. For you there is a *tiny* chance that small percent of users can be compromised and fixing it isn’t beneficial. For me there is a chance to lost my work, my time, be attacked by ransomware or even lost money if someone could get to my online banking. There are a lot of possibilities here and saying that it’s always dangerous out there/here isn’t helping. We should always try to be as safe as possible and developers should help us and not to blame us for opening blend files. We are gonna do this. We are gonna share our work. We are gonna use somebody else work. That is something unstoppable.
I don’t really get your analogy. It’s not the case here because car has around 20 holes.
From my point of view security of the users is the most important thing. One case of a user or a company which would suffer because of those vulnerabilities will backfire tremendously. The message will be: “xxx was attacked trough Blender” not “Blender had some tiny, irrelevant vulnerabilities but stupid user opened untrusted file and brought it on itself”.
So the message from you, from BF and main developers should be: “We are working as hard as we can to keep your safe because we care for you and for our software” and certainly not trying to make vulnerabilities less important.
@LUKE_D
my 2c – this whole situation begs the question whether to immediately address this issue or keep developing the 2.8 project – it’s not about dropping the security problem altogether. If you take up both, you’ll end up having too many irons in the fire. I for one check any file I download through Virustotal though I do rely on my AV of choice.
If your worried about the vulnerabilities you could try sandboxing blender?
I agree with all of luke_d (I’m BSE user too and sharing files often is the only way to help users, and even blender bug tracker requirs a demo file…), but I’ll add something.
Of the 20 issues, most (if not all) of them are integer overflows:
– 9 are about loading some external media format: at least this could meanwhile maybe be mitigated alerting users before loading files that include external media that will be loaded.
– 2 are about image loading/preview: at least the preview could meanwhile be disabled (at least as an option by default, with a warning if activating it)
– 5 about managing/upgrading old .blend versions: meanwhile warn the user if they’re using something that could trigger the issue
– 4 various ones: those should be fixed asap, imho (maybe even retrofitted to some old version).
…since it seems that an integer size check would solve most issues, I would like something addressing that to be put into development schedule.
At least a revision of how those issues are considered in the code design would make any next version address those open issues. And, I would communicate that clearly.
Also many users use even old blender releases, sometimes for valid reasons. So, at least I would warn users even downloading, or maybe add a security section on the website to inform/alert users on past, present, future versions.
Another possible mitigation feature could be a .blend/media file-checker, maybe. If standalone, it could check files even for users of older version. Just ideas.
Yes, imho blender needs to consider those security issues, somehow, not hope that hackers will not target its (relatively) small user base.
Maybe adding security-focused tasks, even if this slows down new cool things (they are new so they could bring even new cool integer overflows….).
It would imho get much appreciation and respect from most of its growing base users (think about 101 too).
There is always the possibility to send such security risk information directly to the company / foundation responsable for the development of that specific software, without misusing such information for making advertisment for themselves. In the meantime some newbie hacker will try the security risk out by writing some “test files”. Thank you CISCO, you are so discrete and so trustworthy.
I don’t see anything new here, you can change any file extension to a blend file anytime, for example, I can take any viruses file and I can put an extension with .blend
Definitely an over-reaction. Who opens random .blend files?
Also, that seems about the worst way possible for someone to spread a virus — unless they had a personal vendetta against Blender users. Even then, I can’t imagine what .blend file would get nearly enough downloads to make it worth doing.
Precisely. If a hacker had a particular hatred for 3D designers, he’d surely ‘craft’ a bad SolidWorks or ProE file, and hold many large corporations to ransom.
@RUSSELL WULFENSTEIN did you ever heard about blenderartists.org or blender.stackexchange.com, even here on BN you have posts linking for free stuff on different servers.
adding to what @luke_d said above, blend swap? a ton of “free models” sites out there?
So one reason Blender and other CG software make an attractive target is that it is frequently run on machines with powerful graphics cards and decent CPUs. It’s not too hard to imagine that someone would want to use that power to do something like mine a crypto currancy (whenever you’re not using the machine to avoid detection). Security issues should be placed fairly high on development priority lists for all forms of software regardless of userbase size because security by obscurity isn’t really a thing with computers.
Not every software need to do this, That’s why there is anti-viruses software specialized in this.(and they are actually good at this)
If blender would direct the resources in security will be a loss of resources and money instead of improving Blender.
Dude, seriously…
If someone has such machine and doesn’t know what VPN and Linux are, this person don’t have the right to blame the Blender Foundation for security issues.
Artists are not necessarily computer experts. “Users ought to know better” is often a true statement but never good rational for not prioritizing proper security. If you use Preview on Mac or Photos on Windows or EoG on Linux to look at a jpg downloaded from imgur, it’s not an unreasonable user expectation that those applications should not read the file in such a way that could lead to arbitrary code execution. The only difference between jpg and blend files here is that blend files do a whole lot more and properly checking/sanitizing them takes many more checks.
Since you are such an expert, go there and fix the code, then submit the patch. If this is a number one priority in your list, don’t shove it down the throats of others.
Francisco: Dude: That reply is just rude. This is a discussion. Personal attacks and name calling are outside the acceptability tolerances here. You should also remember to not “shove it down the throats of others.” You opinions just may be wrong, too.
Got it?
Blender should first switch to TDD (test driven development) and unit testing, to enable more reliable code and increase confidence in the software.
Second, Blender should use STL for management of all data structures and not use home brew implementations, even though these work.
Third, Blender should use garbage collection (using third party libraries) for memory management. Blender is much too complex for any developer to do manual memory management.
These measures will all but eliminate the chance of buffer overflows and arbitrary code execution.
Blender is open source and its developers are very open to external patches. If you feel so strongly that Blender should be doing those things, don’t you think that you “should” be implementing them yourself?
While I’m not denying that it would be great if some of these things were done, changing something like garbage collection isn’t as easy as “#include newgc” and using find and replace. This is further compounded by the fact that most modern ray tracers use crazy acceleration structures that further complicate the issue.
Also correct me if I’m wrong, but I was under the impression that no pbrt based renderers used STL as STL just wasn’t designed for hpc applications?
These suggestions are more about general development practices which the Blender Foundation should encourage developers to use, especially the ones it hires.
I believe that anyone who’s serious about the quality of software should use unit testing and TDD, and I’m absolutely sure that includes the Blender Foundation. It will cost you in the short term, but will more than pay for itself in the long run. You have to ask yourself: what objective measurement do I have that tells me that the code adheres to the specs? You can test the code, but you change one line of code and it fails. You need continuous automated testing to keep the quality constant. And it saves you a lot of sleep later on! And usage of TDD is also known to result in better software architecture design.
The GC including might take some effort, and doesn’t need to be used throughout the entire application. Highly performance based code could be excluded from garbage collection.
I don’t see a reason why STL couldn’t be used in PBRT. It’s optimized for performance and extremely well tested. If PBRT renders don’t use it it’s more than likely ignorance and unwillingness to move away from C based development towards C++. The Blender code base was developed in C originally and later moved to C++, but I still see a lot of C style coding.
This ‘revelation’ that Blender has insecurities will not, in any way, affect my use of Blender. The only effect of the Cisco report’s wording is to seriously lessen my respect for Cisco. In the vanishingly small scenario that:
a) A hacker had wasted his time ‘crafting’ a bad .blend file, rather than a world-popular file format or a file that will run on mobile phones;
b) I had chosen to download that particular file,
… I would then hope my AV software would detect its actions and kill it.
We WANT .blend become a “world-popular file format”… no? At least in the GC domain.
So security is a quite important element.
Yes, I see the point that, in the end, is the user’s responsability not to download any file you find on the web, but as you said it in another post, file-sharing is part of the Blender experience, so security should be something to be focused if we want Blender to become more popular.
That’s a fallacy. Creativity is about openness.
The paranoid control is not the solution, is just someone trying to sell a service that is not necessary.
I associate with CISCO snobs using snob hardware and snob software developed and designed by snobs. Why do they care anyway?
This is like SONY removing videos of Blender Community from Youtube, without a reason and without begging for pardon for their misbehavior.
Due to Blender open nature, sharing of .blend files is quite common (e.g. see blendswap, tons online tutorials with downloadable .blend examples, libraries, materials etc.).
For this reasons, me too I think that close the identified vulnerabilities “just-open-and-you-are compromised” is to be placed high on development priority.
Blender is FOSS, so malicious users can easy find ways to exploit vulnerabilities. “Open” is good, I like it, but the other face is this kind of risks. I don’t think is a really bad idea to ignore/postpone fix to already know vulnerabilities.
Of course, executing scripts (addons or included in .blends) is NOT to be considered a “vulnerability”: this is a user choice and responsibility. Overflows and arbitrary code executions no.
Due to Blender open nature, sharing of .blend files is quite common (e.g. see blendswap, tons online tutorials with downloadable .blend examples, libraries, materials etc.).
For this reasons, me too I think that close the identified vulnerabilities “just-open-and-you-are compromised” is to be placed high on development priority.
Blender is FOSS, so malicious users can easy find ways to exploit vulnerabilities. “Open” is good, I like it, but the other face is this kind of risks. I don’t think is a really bad idea to ignore/postpone fix to already know vulnerabilities.
Of course, executing scripts (addons or included in .blends) is NOT to be considered a “vulnerability”: this is a user choice and responsibility. Overflows and arbitrary code executions no.
Meanwhile, competing software consider arbitrary code execution to be a feature, and it will not be fixed because it’s useful in production.
CVE-2009-3578 Autodesk Maya ‘Script Nodes’ Lets Remote Users Execute Arbitrary Code
https://securitytracker.com/id?1023228
First of all, there’s no such thing as perfect 100% security. Secondly, even if there were, you’re still relying on how secure your hardware is. And we all know what has already happened.
Good morning Vietnam!
Good Morning CIA!
xD
Lol
I definitely think the team should focus on Blender as there are some nice regressions showing up in master that seems to be locking up my Debian system over the past two days.
Why not work on the security aspect of blender after 2.8 is released. Maybe as an addon. Please do not halt production of Blender 2.80 because of somebody else’s concern.
AFAIK, signalled vulnerabilities patching is already in progress.
Especially about TIFF, PNG, IRIS, DPX, HDR and AVI loading, thumbnail file reading and mesh code.
Many thanks to Brecht Van Lommel and the developers team. :)
Isn’t this solved by the “Auto Run Python Scripts” box. By keeping it unchecked as it is by default and by not running the scripts from untrusted files if they prompt you to do so we should be protected, right?
no, that is useful to be safe against malicious python scripts, but in this case is different. Some of those issues don’t need a malicious .blend file, but just a malicious .avi, .tif, .png, .bmp or else. You could get those even separatedly, but if you load them even in your default file in blender, they trigger the issue.
but you could also get a .blend with such malicious images “packed” (blender feature) or linked from a folder. Loading those images or viewing preview thumbnails triggers the issue.
If you get an old (malicious) blender file, your new blender will perform some task on it, and you get the issue.
the same goes for newer malicious .blend fields that use some standard blender features (curves to polygons, text rendered as a font converted into a curve, drawing a Particle object, applying a particular object modifier to a Mesh)
This may happen if you get .blend files and/or media files that are loaded into them, from a malicious other user.
I read through some of the issue writeups, and for the amount of detail they’ve gone into for each vulnerability I’m surprised they didn’t just submit patches. It almost looks like they’re trying to push the Snort software more than they’re trying to make other software better. The last paragraph of the summary article on Talos actively pushes the purchase of Snort, which kinda confirms my suspicion.
The advisories say “Included with this advisory is a generator for the vulnerability” but there are absolutely no proofs-of-concept attached to any of them.
In any case, I see that most of these are now issues in the Blender issue tracker, so it’s a bit “move along, nothing to see here.”
For the non-technical, these issues have nothing to do with running Python scripts, the fixes aren’t going to delay 2.8 for months, and these vulnerabilities only exist in the context of Blender. This means that unless you’re running Blender with admin privileges, the potential code execution doesn’t have elevated privileges.
For the somewhat technical people commenting, switching to STL and garbage collection will change absolutely nothing about these issues. Unit testing and TDD aren’t magic bullets, and wouldn’t catch these problems either.
I think these issue are useful only for a hacker to target a specific computer/user.
To put a malicious .blend either on blendswap or stackexange, the hacker need to do two things : to corrupt the .blend and also provide 3D content interesting enough so many people would download it. Otherwise it’s waisted energy…
In fact , how many people would download the last .blend with awesome content VS something targeting a bigger part of internet users, like something with cute cats or porn ?
As Brecht pointed out, even with these security fixed it’s easy for a hacker to found others. And even if blender is secure that doesn’t mean every piece of software we are using is too.
As pointed out by others, if I was a hacker I would better target Maya or AE because it’s at least better used.
Anyway I found that news great because it’s always good to remember that anything can be hacked, but that won’t change the way I use blender.
Maybe just try to sandbox Blender if you’re concerned:
https://www.raymond.cc/blog/no-more-worries-when-running-untrusted-programs/
https://askubuntu.com/questions/292925/how-to-sandbox-applications
One explanation:
https://en.wikipedia.org/wiki/Sandbox_(computer_security)
The biggest threat I see is to rendering clouds, due to the number of non-natively developed blend files seen. The fact that they have a credible income when it comes to the direct use of blender could make them a popular target. That Blender P2P rendering networks are becoming a thing makes a Blender Botnet possible. But are there other less popular free/freemium software packages available that are already targeted? See CCleaner.
At the least, users should be made aware that a risk exists with opening blend files from external sources. Is there a way for Blender to detect whether a blend file has been produced non-natively? If so, an Excel-like warning regarding macro-enabled workbooks should be more than sufficient, no?
Well the lesson that stays for me over here, in this blogpost is what follows:
Please do not fed the security trolls.
Thank you again Bart.
You are the guy.
:)