Vulnerability Spotlight: Multiple Unpatched Vulnerabilities in Blender Identified

…okay, fair statement when you think about it, but you gotta admit it’s bad optics, really bad optics.

Ton’s statement

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 followed up with this statement later on…

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.

eh fair enough.

I don’t think the security flaws are a big deal either,

You should treat files you downloaded from a random site, like candy from a stranger.

You probably shouldn’t be doing it in the first place, but when you do, scan it.

If similar security issues are present in the internal file formats of other DCC apps. (Maya, Modo, ect…), then I’m not sure if they should be treated as a big deal if the commercial vendors are also not doing anything.

Though since Blender is free and open source, it would attract a large audience that otherwise can’t afford to work in 3D (meaning that a large chunk of Blender users aren’t as computer-savvy as the average Maya user). Having basic security measures in the .blend file format may not be a bad thing.

What might that mean for public render farms though? There I cannot control, what kind of blend runs on my computer… :confused:

Good point…

So why is .jpg still in ‘widespread’ use? :eyebrowlift: I’m more & more certain other interests are behind all this…

So if I’ve been reading this right, they aren’t talking about any old .blend file with some included script that could do bad things, they are talking about some sort of ‘crafted’ .blend file.

I assume by that they mean it’s not even something you could create just by using Blender, a hacker would have to manually create/code a .blend file that the software would load and not just reject or crash outright and aside from what may or may not show up in the viewport, some extra type code would also run, and access data/files, etc outside of the Blender software. To then I assume download/install an extra root kit and the like.

And at this stage only the possibility that Blender allows this to happen has been identified, there’s no actual proof of concept yet, let alone any actual attack experienced in the wild?

Is all of that basically correct?

If so I say they work on patches as part of the 2.8 development, unless an actual confirmed attack happens, then all other work stops till an emergency patch of 2.79 is released.

While it pains me to agree with Ace he does have a point. Autodesk does indeed have the same security flaws as do the biggest proprietary programs. And, to patch each and every flaw would be a nightmare is my understanding.

Now as a Blender user i don’t download Blend files except from maybe a trusted friend in the community. But, do however download an occasional add - on. And, if they have the same capability as a blend file maybe some check could be devised for them. That being said I understand much of the feedback in the community is based on actually seeing a blend file. Which has been encouraged in our community for many years and why not. ‘Show me your blend file’ Which is the most efficient way to help out a fellow blender head in distress.

And, while we have also been warned for many years a blend file can be a disaster it was a means to a end. Problem solving by screen shots and dialog is way less efficient. So where does this leave us after someone has announced to the world how flawed this might be. Sharing it with the world if you will.

I have not a clue since the developers would be the minds to ponder that. And, the last time I checked the developers are way to busy for hanging out on the BA forum. Nor, engaging in trying to bullet proof a 3d program which is exactly the way i would have it. Just a thought I was mulling over this morning.


Any program with scripting access is going to have these vulnerabilities. Treat a .blend with the same respect you’d treat a .py, .lua, or .exe and you’ll be fine.

blender verse / network sockets could run clients whom had no script level access,
(to share work without really sharing the .blend)

I think blender verse / scripting permission system / editing privlage sandbox could be nice for a teaching env.

admin has all privlage, and can grant privlages temp or permanent on a server.

If it comes to render farms - most of them don’t allow to contain the scripts within your .blend file or they trim it out.

Files don’t have to be specially coded - if you only enable run autoscripts python included in .blend can harm your OS straight away during the on-scene-loading trigger. That’s all folks. That’s why run autoscripts is disabled by default - the whole story ends here.

My advice is to keep the autorun option disabled, trigger it manually on each file if you’re confident about it and never run blender as administrator especially if you work with unknown blend files because this may give malicious script unlimited power, I guess.

Best Regards!

These vulnerabilities are not to do with scripting… but other methods of injecting code. That run autoscripts option would not protect against these vulnerabilities (which includes image loading & loading old multires objects)

I agree. In my eyes it is not appropriate to narrow the discussion down to .blend files with python scripts.

If I understood the post from Cisco correctly, many of the issues (nearly half of them) are about opening images like .tiff, .bmp, .png, .hdr or dealing with .avi and even the thumbnail viewer for directory browsing is vulnerable. Therefore I think it is not so much about script access. The point is, that it doesn’t need a .blend file with a script to make use of the vulnerabilities. A prepared image file could be enough. And, a prepared image file, which leads to a buffer overrun when loaded, is a well known attack vector. Much easier to exploit than, for example, spectre and meltdown.

And yes, attackers do make use of these vulnerabilities. It’s their “job” to do so and it’s a multi million dollar business.

I work in the Internet industry. And whenever we have to decide which software should be used for a client project we do look at how committed the respective “vendor” is to closing vulnerabilities, no matter if it’s open source or commercial software. That’s always a major point in the discussion. Every CTO in a studio will take that into account also, when a new software shall be integrated into the pipeline. Management of risks is about both questions: How likely is it, that the event of an attack will happen, and how big is the impact if it happens. Imagine a malicious attacker would introduce a crypto trojan through that. Tight budgets and deadlines don’t need that - even if there are backups.

So, I think these issues should be addressed and fixed by the BF. Perhaps with 2.8 and maybe ported back to 2.79 then.

The actual plan of the developers is to fix many of these issues for 2.79a, as I read on Blender Nation after my post. That’s good news :slight_smile:

Security salesman: Hello, we have investigated the security of your house, as a free service to you.
House owner: Hello, that’s interesting, I’d like to know more.
Security salesman: We have determined that there are 21 weak spots in this wall. When any of them is hit with sledgehammer, an intruder can walk right in. We strongly suggest you fortify this wall.
House owner: There’s so many other ways someone could break in with less effort, seems like a waste of time to fortify that one wall.
Security salesman: But you are putting your family in danger if you don’t do it.
House owner: We live in a pretty safe neighborhood, our neighbors don’t even have locks on their doors. Fortifying our entire house would be very expensive and take years, and I’m not sure my family would want me to cancel our vacations to pay for it.
Security salesman: You were warned, we have informed the world that you decline to protect your family from this danger.
House owner: Fine, I’ll fix the damn wall …

By the way, I do think image file vulnerabilities should have higher priority. However in practice it’s not clear these vulnerabilities can actually be exploited, and the files would need to be crafted specifically to target Blender. It’s not that much easier to trick a Blender user to download an malicious image file than a .blend file.

And of course, at this moment there are published OpenEXR image vulnerabilities that affect almost all installed 3D software, but the industry as a whole does not appear to be particularly worried about that kind of thing.

is rigify drivers safe to run anymore?

btw I recently encounter a weird phenomena where a script I wrote to only run in the game engine decided to autorun when I load the blend, the intercepted file have not imported bpy/os module whatsoever and I was very confused

I make a new copy, delete and unlink the problem file and the new copy stops autorun, has this happened to anyone before?

can these suspicious blend and image files be detected by antivirus?

The reported issues have nothing to do with scripting. As such, running Rigify or any other script is exactly as secure as it was before.

No. Those kinds of issues exist with many file formats and applications and it is practically impossible for antivirus software to catch those.

If there is enough time for it, it would be great to run the benchmark from there: with new gcc/retpoline . It seems intel processors can have some pretty significant slowdowns . It would allow to have a better idea of what the performance of different processor will look like when all 3 hardware vulnerabilities are fixed/worked around.

There is no reason to compile Blender itself with retpoline, that’s only for software that supports some kind of sandboxed code execution.

Mainly we could be affected by fixes in the driver and kernel, but so far compute heavy software like Blender and Cycles seems to do fine.

good to know, thanks for the quick answer.