Blender is subject to symlink attack when the user closes the app without saving their changes. The consequences are that an attacker determined file owned by the victim is overwritten with a .blend file, destroying whatever data was in the file in the process. Version 2.49.2~dfsg-2 isn't vulnerable to this attack since it uses ~/.blender/quit.blend instead of /tmp/quit.blend. I would suggest this behaviour be restored before Blender 2.50 is released. pabs@chianamo:~$ sudo ln -s /home/pabs/foo /tmp/quit.blend [sudo] password for pabs: pabs@chianamo:~$ ls -l /tmp/quit.blend /home/pabs/foo ls: cannot access /home/pabs/foo: No such file or directory lrwxrwxrwx 1 root root 14 Jun 5 13:51 /tmp/quit.blend -> /home/pabs/foo pabs@chianamo:~$ file /tmp/quit.blend /home/pabs/foo /tmp/quit.blend: symbolic link to `/home/pabs/foo' /home/pabs/fooo: ERROR: cannot open `/home/pabs/foo' (No such file or directory) pabs@chianamo:~$ blender Ob 'Camera' - Successfully removed 0 keyframes *bpy stats* - tot exec: 5728, tot run: 0.4375sec, average run: 0.000076sec, tot usage 1.4299% Saved session recovery to /tmp/quit.blend Blender quit pabs@chianamo:~$ ls -l /tmp/quit.blend /home/pabs/foo -rw-r----- 1 pabs pabs 78K Jun 5 13:53 /home/pabs/foo lrwxrwxrwx 1 root root 14 Jun 5 13:51 /tmp/quit.blend -> /home/pabs/foo pabs@chianamo:~$ file /tmp/quit.blend /home/pabs/foo /tmp/quit.blend: symbolic link to `/home/pabs/foo' /home/pabs/foo: Blender3D, saved as 64-bits little endian with version 2.50.0007 pabs@chianamo:~$ echo foo > /home/pabs/foo pabs@chianamo:~$ ls -l /tmp/quit.blend /home/pabs/foo -rw-r----- 1 pabs pabs 4 Jun 5 14:00 /home/pabs/foo lrwxrwxrwx 1 root root 14 Jun 5 13:51 /tmp/quit.blend -> /home/pabs/foo pabs@chianamo:~$ file /tmp/quit.blend /home/pabs/foo /tmp/quit.blend: symbolic link to `/home/pabs/foo' /home/pabs/foo: ASCII text pabs@chianamo:~$ blender *bpy stats* - tot exec: 648, tot run: 0.0677sec, average run: 0.000104sec, tot usage 0.4556% Saved session recovery to /tmp/quit.blend Blender quit pabs@chianamo:~$ file /tmp/quit.blend /home/pabs/foo /tmp/quit.blend: symbolic link to `/home/pabs/foo' /home/pabs/foo: Blender3D, saved as 64-bits little endian with version 2.50.0007
Hi Paul. Paul Wise <pabs@debian.org> (05/06/2010): Requires authentication. Yay for closed projects. http://git.debian.org/?p=collab-maint/blender.git;a=blob;f=debian/NEWS;hb=experimental Mraw, KiBi.
Closing. Feel free to re-open the report if the issue persists. Thanks for your time and efforts.
Control: reopen -1 Control: found -1 2.63a-1 Sorry I didn't notice this bug closing, but did you check that this problem was fixed? It certainly is not fixed on wheezy (see below). This bug has occurred and been fixed before (#298167) and it is a bit disappointing that it was fixed in 2.37a-1 and then again by a different maintainer and the maintainer after that didn't preserve those fixes. Security team, can we get a CVE assigned for this? Perhaps that would get people to fix it for good. The consequences are arbitrary file creation or overwrite on a multi-user system: pabs@chianamo ~ $ dpkg -l blender Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=============================-===================-===================-=============================================================== ii blender 2.63a-1 amd64 Very fast and versatile 3D modeller/renderer pabs@chianamo ~ $ sudo ln -s /home/pabs/foo /tmp/quit.blend pabs@chianamo ~ $ ls -l /tmp/quit.blend /home/pabs/foo ls: cannot access /home/pabs/foo: No such file or directory lrwxrwxrwx 1 root root 14 Sep 5 22:01 /tmp/quit.blend -> /home/pabs/foo pabs@chianamo ~ $ file /tmp/quit.blend /home/pabs/foo /tmp/quit.blend: broken symbolic link to `/home/pabs/foo' /home/pabs/foo: ERROR: cannot open `/home/pabs/foo' (No such file or directory) pabs@chianamo ~ $ blender Blender quit pabs@chianamo ~ $ blender Saved session recovery to /tmp/quit.blend Blender quit pabs@chianamo ~ $ ls -l /tmp/quit.blend /home/pabs/foo -rw-r----- 1 pabs pabs 170K Sep 5 22:02 /home/pabs/foo lrwxrwxrwx 1 root root 14 Sep 5 22:01 /tmp/quit.blend -> /home/pabs/foo pabs@chianamo ~ $ file /tmp/quit.blend /home/pabs/foo /tmp/quit.blend: symbolic link to `/home/pabs/foo' /home/pabs/foo: Blender3D, saved as 64-bits little endian with version 2.63 pabs@chianamo ~ $ echo foo > /home/pabs/foo pabs@chianamo ~ $ ls -l /tmp/quit.blend /home/pabs/foo -rw-r----- 1 pabs pabs 4 Sep 5 22:03 /home/pabs/foo lrwxrwxrwx 1 root root 14 Sep 5 22:01 /tmp/quit.blend -> /home/pabs/foo pabs@chianamo ~ $ file /tmp/quit.blend /home/pabs/foo /tmp/quit.blend: symbolic link to `/home/pabs/foo' /home/pabs/foo: ASCII text pabs@chianamo ~ $ blender Saved session recovery to /tmp/quit.blend Blender quit pabs@chianamo ~ $ file /tmp/quit.blend /home/pabs/foo /tmp/quit.blend: symbolic link to `/home/pabs/foo' /home/pabs/foo: Blender3D, saved as 64-bits little endian with version 2.63
Hi Paul, At the time of triaging this bug, I did a test and the bug did appear to me. But now I realize that it isn't fixed as I didn't understood the process to reproduce it (ie. I didn't create the symbolic link *before* running blender) As far as i remember it as been dropped on 2.50-alpha because the debian patch was a bit hacky : - the blender executable was wrapped by a script that checked ~/.blender directory existence and created this directory otherwise. - there was also a debian patch that made blender save the quit.blend in the ~/.blender directory. I've spent some time and try to produce a decent patch without result and as i didn't manage to reproduce the bug, i didn't try further (my bad :-( ).
Today I've contacted upstream developers (via IRC channel on Freenode) and asked about this long-lasting security bug. They pointed me to: https://developer.blender.org/rB367722470aa2eada43614cd558f468b4beea851d where it's clear that the issue has been fixed with that commit. So, I'm (finally) closing this bug report. Cheers.
Today I've contacted upstream developers (via IRC channel on Freenode) and asked about this long-lasting security bug. They pointed me to: https://developer.blender.org/rB367722470aa2eada43614cd558f468b4beea851d where it's clear that the issue has been fixed with that commit. So, I'm (finally) closing this bug report. Cheers.
Control: reopen -1 I'm sorry but this does not resolve the issue, it simply turns the results from an arbitrary file overwrite to a denial of service (prevent other users from autosaving). Saving in /tmp at all is completely the wrong solution. The right thing to do is to either use a random path in $TMPDIR using mkstemp etc or to use somewhere under $HOME, preferably following the XDG basedir spec: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
Dear maintainer, Recently you fixed one or more security problems and as a result you closed this bug. These problems were not serious enough for a Debian Security Advisory, so they are now on my radar for fixing in the following suites through point releases: squeeze (6.0.8) - use target "oldstable" Please prepare a minimal-changes upload targetting each of these suites, and submit a debdiff to the Release Team [0] for consideration. They will offer additional guidance or instruct you to upload your package. I will happily assist you at any stage if the patch is straightforward and you need help. Please keep me in CC at all times so I can track [1] the progress of this request. For details of this process and the rationale, please see the original announcement [2] and my blog post [3]. 0: debian-release@lists.debian.org 1: http://prsc.debian.net/tracker/584621/ 2: <201101232332.11736.thijs@debian.org> 3: http://deb.li/prsc Thanks, with his security hat on: -- Jonathan Wiltshire jmw@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51
Hi Jonathan Out of curiosity: is this mail template still up-to-date? squeeze is now EOL. Shouldn't the mail point people to https://wiki.debian.org/LTS and instructions to provided fixes via squeeze-lts? Cheers