Fedora has issued an advisory on September 9: http://lists.fedoraproject.org/pipermail/package-announce/2012-September/086193.html Mageia 2 is also affected. This is a re-ocurrence of CVE-2008-1103 from Blender 2.49b, which we already have a patch for in Mageia 1. Here is Fedora's patch for 2.63a: http://pkgs.fedoraproject.org/cgit/blender.git/plain/blender-2.63a-cve.patch
Whiteboard: (none) => MGA2TOO
URL: (none) => http://lwn.net/Vulnerabilities/516717/
CC: (none) => dmorganec, fundawang
Here's a working link for the patch :o) http://pkgs.fedoraproject.org/cgit/blender.git/plain/blender-2.63a-cve.patch?h=f17&id=21d6b5274519b60b98f6cf8c25a7dedd4257b092
This is fixed upstream in 2.64a, which is now in Cauldron.
Version: Cauldron => 2Whiteboard: MGA2TOO => (none)
Patched package uploaded for Mageia 2. Advisory: ======================== Updated blender package fixes security vulnerability: An insecure temporary file use flaw was found in the way 'undo save quit' routine of Blender kernel of Blender, a 3D modeling, animation, rendering and post-production software solution, performed management of 'quit.blend' temporary file, used for session recovery purposes. A local attacker could use this flaw to conduct symbolic link attacks, leading to ability to overwrite arbitrary system file, accessible with the privileges of the user running the blender executable (CVE-2012-4410). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4410 http://lists.fedoraproject.org/pipermail/package-announce/2012-September/086193.html ======================== Updated packages in core/updates_testing: ======================== blender-2.63a-1.2.mga2 from blender-2.63a-1.2.mga2.src.rpm
Assignee: bugsquad => qa-bugs
Trying to test this package in a VM (Mageia 2 i586) while moving the cube, the menus are blinking. I will try to test it in Mageia 2 64 bits. Also, I didn't find any POC.
CC: (none) => ed_rus099Source RPM: blender-2.63a-1.1.mga2.src.rpm => blender-2.63a-1.2.mga2.src.rpm
Possible PoC: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584621
David, please see also here: http://seclists.org/oss-sec/2012/q3/411
That makes 3 CVEs that been assigned for this same issue. It was originally CVE-2008-1103 (fixed in our Mageia 1 package), which upstream has refused to fix. Our Mageia 1 patch is one of three patches I can find that fixes it for that version. Updating the advisory. Advisory: ======================== Updated blender package fixes security vulnerability: An insecure temporary file use flaw was found in the way 'undo save quit' routine of Blender kernel of Blender, a 3D modeling, animation, rendering and post-production software solution, performed management of 'quit.blend' temporary file, used for session recovery purposes. A local attacker could use this flaw to conduct symbolic link attacks, leading to ability to overwrite arbitrary system file, accessible with the privileges of the user running the blender executable (CVE-2010-5105, CVE-2012-4410). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-5105 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4410 http://lists.fedoraproject.org/pipermail/package-announce/2012-September/086193.html ======================== Updated packages in core/updates_testing: ======================== blender-2.63a-1.2.mga2 from blender-2.63a-1.2.mga2.src.rpm
Testing mga2 i586 Before ------ $ echo foo > test/foo $ ln -s ~/test/foo /tmp/quit.blend $ file test/foo test/foo: ASCII text $ file /tmp/quit.blend /tmp/quit.blend: symbolic link to `/home/claire/test/foo' $ blender Saved session recovery to /tmp/quit.blend Blender quit $ file /tmp/quit.blend /tmp/quit.blend: symbolic link to `/home/claire/test/foo' $ file test/foo test/foo: Blender3D, saved as 32-bits little endian with version 2.63 After ----- $ echo foo > test/foo $ file test/foo test/foo: ASCII text $ file /tmp/quit.blend /tmp/quit.blend: symbolic link to `/home/claire/test/foo' $ blender Saved session recovery to /tmp/quit.blend Blender quit $ file /tmp/quit.blend /tmp/quit.blend: symbolic link to `/home/claire/test/foo' $ file test/foo test/foo: Blender3D, saved as 32-bits little endian with version 2.63 I'm not noticing any difference between the two David, could you check this please?
Ouch, I'll have to see if I can reproduce it and check Fedora too. I'll have to let them know if their patch doesn't fix it. If it doesn't, I can try just adding O_EXCL to the open flags like the patch in our Mageia 1 package does.
Whiteboard: (none) => feedback
strace doesn't show any kind of stat before opening and writing to /tmp/quit.blend either. $ strace -fo strace.out sh blender Saved session recovery to /tmp/quit.blend Blender quit $ less +G strace.out ... 14621 open("/tmp/quit.blend", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 5 14621 write(5, "BLENDER_v263RENDH\0\0\0\264E\342\277\0\0\0\0\1\0\0\0"..., 1188) = 1188 14621 write(5, "SC\0\0@\v\0\0\320F5\v\253\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 3980) = 3980 14621 write(5, "CA\0\0\250\0\0\0(X5\v\26\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1012) = 1012 14621 write(5, "WO\0\0\244\1\0\0\250\\5\v\216\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 492) = 492 14621 write(5, "OB\0\0\200\4\0\0\310^5\v\201\0\0\0\1\0\0\0008d5\v\0\0\0\0\0\0\0\0"..., 4056) = 4056 14621 write(5, "MA\0\0\0\3\0\0Po5\v'\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0A\v\0"..., 9824) = 9824 14621 write(5, "ME\0\0@\4\0\0p\2265\v2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 74684) = 74684 14621 write(5, "SDNANAME:\r\0\0*next\0*prev\0*data\0*f"..., 32768) = 32768 14621 write(5, "_heat_scale[2]\0vgroup_flow\0vgrou"..., 32768) = 32768 14621 write(5, "\4\0\233\f\4\0\234\f\4\0\235\f\4\0\\\0\4\0\33\0\4\0\236\f\2\0\237\f\2\0\240\f"..., 1172) = 1172 14621 write(5, "ENDB\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 20) = 20 14621 close(5) = 0 14621 fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 1), ...}) = 0 14621 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb1699000 14621 write(1, "Saved session recovery to /tmp/q"..., 42) = 42 ...
gdb would probably be more informative in this case, but I wonder if they actually meant to use O_EXCL in their patch and just forgot, considering they test for EEXIST.
I added O_EXCL to the open flags in the patch. blender-2.63a-1.3.mga2 is building now.
IIUC won't that mean it can only ever create one recovery file?
How exactly does this recovery file work? I know it puts it in /tmp so it's only supposed to be temporary. Does it remove it when you start blender the next time? Basically the O_EXCL does make open() fail if it already exists, so yes, it won't overwrite an existing one. That's how the patch in our Mageia 1 package protects against this same symlink attack.
I'm not sure how it's supposed to work but it does write it each time.. $ blender Saved session recovery to /tmp/quit.blend Blender quit $ ll /tmp/quit.blend -rw-r--r-- 1 claire claire 161964 Oct 31 17:28 /tmp/quit.blend $ blender Saved session recovery to /tmp/quit.blend Blender quit $ ll /tmp/quit.blend -rw-r--r-- 1 claire claire 161964 Oct 31 17:29 /tmp/quit.blend
It doesn't remove it when blender is opened next time. If the project is saved before quitting it shows $ blender Total files 0|Changed 0|Failed 0 Blender quit $ date Wed Oct 31 17:35:43 GMT 2012 $ ll /tmp/quit.blend -rw-r--r-- 1 claire claire 161964 Oct 31 17:29 /tmp/quit.blend
Actually it was correct to add O_EXCL, Fedora did forget it and went back and added it: http://pkgs.fedoraproject.org/cgit/blender.git/plain/blender-2.63a-cve.patch?id=d1524bfb4e5077e70dc9aded216bd8ca5e7718e5 The bug is still reproducible though o_O
Assigning David :D Please reassign to QA when ready. Thanks
CC: (none) => qa-bugsHardware: i586 => AllAssignee: qa-bugs => luigiwalserWhiteboard: feedback => (none)
CC: (none) => oe
OpenSuSE has issued an advisory for this today (February 15): http://lists.opensuse.org/opensuse-updates/2013-02/msg00047.html This uses the 2010 CVE, so it got a new LWN page: http://lwn.net/Vulnerabilities/538440/ They used the same broken patch from Fedora.
Below is the response I received from Vincent Danen of RedHat about this. The current upstream version of Blender (2.67) is still vulnerable. ================= Has upstream developed a new patch to fix this, or is it still vulnerable? I can assign a new CVE for this, but it would also be nice to have a better patch. I suppose the bit where O_CREAT is stripped could be removed but, honestly, I'm not sure why something like mktemp() isn't being used here (unless subsequent invocations of blender require the same temporary file (it saves state I guess?), in which case it should be using an application-specific temporary directory). In other words, if blender needs this temporary file to persist across sessions, /tmp is probably a bad place to begin with (many systems will clean /tmp on boot), but if that isn't a real concern, then it could do something like securely create /tmp/blender-user with 700 permissions and then securely create the file inside that directory. If the directory exists make sure it's owned by the uid of the user running blender. I suppose instead of stripping the O_CREAT flag, blender could also delete the file and then create a new one (i.e. if /tmp/foo is my file and I read state from it when I start blender, blender should either immediately remove it (preferable, if it's not to be read from anymore, why keep it?), or if it tries to save state and goes "oh, /tmp/foo already exists", it could delete it (after checking ownership) and then recreate it. So, a few things I think could probably be done better: - when blender reads the state file, delete it - check file ownership - why is the file being created mode 0666? isn't that excessive? - use a per-user temporary directory - possibly use /var/tmp instead of /tmp if these files are intended to persist across reboots I agree with David that this probably requires a fourth CVE, but I'd like to know if a patch to correctly fix it is available and make sure a CVE hasn't been assigned elsewhere. Thanks. -- Vincent Danen / Red Hat Security Response Team
Over 3 months later. Anything happening with this?
CC: (none) => davidwhodgins
Nope. Still waiting.
Maybe they can use the O_TMPFILE thing from kernel 3.11: http://news.softpedia.com/news/Linux-Kernel-3-11-Has-Been-Officially-Released-379998.shtml
Version: 2 => CauldronWhiteboard: (none) => MGA3TOO
Blocks: (none) => 11726
Removing this from the Mageia 4 tracker. It still is the same upstream and I don't have any hope that it will be fixed.
Blocks: 11726 => (none)Whiteboard: MGA3TOO => MGA4TOO, MGA3TOO
The last point under Distribution Hardening here is interesting: https://lists.debian.org/debian-devel-announce/2014/03/msg00004.html /proc/sys/fs/protected_symlinks is enabled in Mageia as of Mageia 4, and if I understand the feature correctly: https://lwn.net/Articles/503660/ would render this and many other similar issues moot, and in fact in the first link you see that Debian plans to ignore them going forward.
Version: Cauldron => 3Whiteboard: MGA4TOO, MGA3TOO => (none)
Closing due to Mageia 3 EOL: http://blog.mageia.org/en/2014/11/26/lets-say-goodbye-to-mageia-3/
Status: NEW => RESOLVEDResolution: (none) => OLD