| Summary: | blender new security issue CVE-2012-4410 | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | David Walser <luigiwalser> |
| Component: | Security | Assignee: | David Walser <luigiwalser> |
| Status: | RESOLVED OLD | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | davidwhodgins, dmorganec, ed_rus099, fundawang, oe, qa-bugs |
| Version: | 3 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://lwn.net/Vulnerabilities/516717/ | ||
| Whiteboard: | |||
| Source RPM: | blender-2.63a-1.2.mga2.src.rpm | CVE: | |
| Status comment: | |||
|
Description
David Walser
2012-09-18 18:17:59 CEST
David Walser
2012-09-18 18:18:11 CEST
Whiteboard:
(none) =>
MGA2TOO
David Walser
2012-09-18 22:09:10 CEST
URL:
(none) =>
http://lwn.net/Vulnerabilities/516717/
Manuel Hiebel
2012-09-25 23:03:29 CEST
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 =>
2 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_rus099 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-bugs
David Walser
2012-12-21 14:25:40 CET
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
David Walser
2013-11-21 22:52:17 CET
Version:
2 =>
Cauldron
David Walser
2013-11-21 23:05:17 CET
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) 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 =>
3 Closing due to Mageia 3 EOL: http://blog.mageia.org/en/2014/11/26/lets-say-goodbye-to-mageia-3/ Status:
NEW =>
RESOLVED |