Blender Security Issue

General discussion about the development of the open source Blender

Moderators: jesterKing, stiv

Post Reply
kirpre
Posts: 11
Joined: Wed Oct 16, 2002 4:09 am
Location: New York

Blender Security Issue

Post by kirpre » Tue Dec 20, 2005 10:49 pm

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
Posts: 289
Joined: Wed Oct 16, 2002 2:38 am
Contact:

Re: Blender Security Issue

Post by z3r0_d » Wed Dec 21, 2005 2:03 am

kirpre wrote: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
Posts: 96
Joined: Fri Jan 10, 2003 6:41 pm
Contact:

Post by joeri » Wed Dec 21, 2005 11:48 am

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
Posts: 0
Joined: Wed Jul 21, 2004 12:15 am
Location: Munich | Germany | Europe
Contact:

Post by konrad_ha » Wed Dec 21, 2005 1:07 pm

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
Posts: 0
Joined: Thu Aug 05, 2004 4:28 pm

Post by ysvry » Wed Dec 21, 2005 3:23 pm

its a good point raised , well done kirpre

SirDude
Posts: 233
Joined: Sun Oct 13, 2002 7:37 pm
Location: University of Minnesota (USA)
Contact:

Post by SirDude » Wed Dec 21, 2005 5:22 pm

I just commited a fix for this to cvs.

Thanks,

Kent

an-toni
Posts: 0
Joined: Wed Mar 17, 2004 5:20 pm

Post by an-toni » Thu Dec 22, 2005 1:32 am

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
Posts: 96
Joined: Fri Jan 10, 2003 6:41 pm
Contact:

Post by joeri » Thu Dec 22, 2005 11:46 pm

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
Posts: 53
Joined: Mon Oct 14, 2002 5:24 am

Post by MrMunkily » Sat Dec 24, 2005 6:53 pm

can't gpg do that?

(well, the opposite of it anyhow.)

Post Reply