CVE-2009-3850 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-3850): Blender 2.34, 2.35a, 2.40, and 2.49b allows remote attackers to execute arbitrary code via a .blend file that contains Python statements in the onLoad action of a ScriptLink SDNA.
Although I'm sure it won't surprise anyone, I just want to state that I confirmed this bug in 2.49a too. Cheers.
Any news?
2.57 stable? http://www.blender.org/development/release-logs/blender-257/ I don't know if it actually fixes it, though. It would be great if we could find the upstream report of this bug.
(In reply to comment #3) > I don't know if it actually fixes it, though. For this issue it's easy to find out. The proceedure at 7. Technical Description / Proof of Concept Code http://www.coresecurity.com/content/blender-scripting-injection is easy enough to follow. I used import os os.system("notify-send 'Hello from CVE-2009-3850, blender'") for the script and the popup showed up as expected. Scary! So I have a file CVE-2009-3850.blend now that I can test Blender 2.57 against once it is packaged. I will not upload that file here - better make your own: it's easy.
Created attachment 270713 [details, diff] Proposed patch for CVE-2009-3850 against Blender 2.49b (v3) Let me start with a word of warning: I am rather new to Blender and to security analysis. Please bare with me if you find any mistakes in this report and propose corrections for me to learn. Thanks! Blender 2.49b ============= Analysis v3 ----------- Blender operates in two modes: background (without GUI) and foreground (with GUI). Either modes do execute Python code embedded in a .blend file unless that features is disabled. By default all embedded code is executed. In general there are two ways to disable execution of these so-called scriptlinks: A) Passing "-y" on the command line B) Un-checking "Auto Run Python Scripts" under "User preferences", "System". Their implementation is not perfect: 1) Both of these methods do not fully disable script execution though, as two of the post-render event handling sections are missing proper guards: - BPY_do_all_scripts(SCRIPT_POSTRENDER, 0); + if (G.f & G_DOSCRIPTLINKS) + BPY_do_all_scripts(SCRIPT_POSTRENDER, 0); 2) When passing "-y" on the command line in foreground mode, the config from ~/.B.blend may still set G_DOSCRIPTLINKS flag later. Thus, parameter "-y" is no guarantee to be safe. In addition, the current stable version of Blender implements parameter "-y" with the opposite effect: Blender 2.49b: -y Disable automatic python script execution (scriptlinks, pydrivers, pyconstraints, pynodes) [-Y Show message and quit] Blender 2.57: -y or --enable-autoexec Enable automatic python script execution (default) -Y or --disable-autoexec Disable automatic python script execution (pydrivers, pyconstraints, pynodes) 3) By design, in backround mode config file ~/.B.blend is not processed. Therefore, disabling "Auto Run Python Scripts" in the preferences alone does not make the background mode any safer. Fixing ------ For a fix I consider these requirements to be reasonable: 1) Preserve the freedom to turn scriptlinks on to those who wish without putting anyone at risk by default 2) Offer a command line parameter (new or existing) that controls script execution in background mode in without any GUI configuration interfering For (2) I decided against abusing "-Y", "--enable-autoexec" and "-enable-autoexec". A new parameter "-666" serves the purpose of (2), instead. When in -666 mode disabling "Auto Run Python Scripts" in the GUI will intentionally turn off scriptlinks in GUI mode. This will allow risk-aware people to put -666 in their .desktop file to control trust in files for the GUI mode in the GUI while still being safe on the command line. Blender 2.57 ============ While Blender 2.57 does not execute scriptlinks (of Blender 2.4x), using the checkbox "Register" in the text editor pane you can produce exploits for Blender 2.57 just as easily. A chat in #blendercoders today made clear that upstream's defaults on script execution still are not safe and are not expected to change anytime soon. Blender's user base seems to want it that way, see <http://markmail.org/message/cu2xdhngcudl27cr> for a sample. The general user base of a Linux distribution may have stronger focus on security though, think of a hobbyist playing around with a few .blend files downloaded from somewhere in the internet. In my point of view a GNU/Linux distribution owes this user protection and safe defaults. I do not have a ready patch for Blender 2.57 at this time. I would like to thank <ideasman_42> on #blendercoders for being of great help. Nevertheless, any mistakes in this report are mine. Sebastian
Sebastian, thanks for doing all this. (In reply to comment #5) > > > Fixing > ------ > For a fix I consider these requirements to be reasonable: > > 1) Preserve the freedom to turn scriptlinks on to those who wish > without putting anyone at risk by default > > 2) Offer a command line parameter (new or existing) that controls > script execution in background mode in without any GUI configuration > interfering > > For (2) I decided against abusing "-Y", "--enable-autoexec" and > "-enable-autoexec". A new parameter "-666" serves the purpose of (2), > instead. > This sounds like a very good approach from my side, fwiw.
+*blender-2.49b-r1 (21 Apr 2011) + + 21 Apr 2011; Sebastian Pipping <sping@gentoo.org> +blender-2.49b-r1.ebuild, + +files/blender-2.49b-CVE-2009-3850-v3.patch: + Integrate patch for CVE-2009-3850 (bug #293130) +
(In reply to comment #5) > Fixing > ------ > For a fix I consider these requirements to be reasonable: > > [..] > > 2) Offer a command line parameter (new or existing) that controls > script execution in background mode in without any GUI configuration > interfering > > [..] > > When in -666 mode disabling "Auto Run Python Scripts" in the GUI will > intentionally turn off scriptlinks in GUI mode. This will allow > risk-aware people to put -666 in their .desktop file to control trust > in files for the GUI mode in the GUI while still being safe on the > command line. I notice that the above statements can be understood as contradicting. Unpatched when run in background mode Blender 2.49b would do if ((U.flag & USER_DONT_DOSCRIPTLINKS)) bfd->globalf &= ~G_DOSCRIPTLINKS; although U.flag has not been initialized from ~/.B.blend as it's not processed in background mode. That is what I had in mind when saying "without any GUI configuration interfering". From a user point of view scriptlinks are enabled when this expression is true: Parameter -666 given AND ( background mode (parameter -b given) OR ( foreground mode (GUI, no -b given) AND option "Auto Run Python Scripts" enabled ) ) Interpret this as math, no lazy-evaluation tricks.
(In reply to comment #7) > +*blender-2.49b-r1 (21 Apr 2011) > + > + 21 Apr 2011; Sebastian Pipping <sping@gentoo.org> +blender-2.49b-r1.ebuild, > + +files/blender-2.49b-CVE-2009-3850-v3.patch: > + Integrate patch for CVE-2009-3850 (bug #293130) > + Great, thank you. Can we move forward to stabilize =media-gfx/blender-2.49b-r1?
(In reply to comment #9) > Can we move forward to stabilize =media-gfx/blender-2.49b-r1? I guess so. If anyone got time to do a draft of a GLEP 42 news item for this it would be welcome. If we don't tell our users, they will need to find the -666 parameter themselves.
Created attachment 270983 [details, diff] Diff between v3 and v4 I noticed that despite patch v3 and no -666 parameter given a user could still do this: 1) Open a trusted file, play around 2) Check toggle button "Enable Script Links" (panel "Buttons Window", sub panel "Scripts") which turns on the G_DOSCRIPTLINKS bit globally 3) Open a malicious file --> Code gets executed Therefore I now disable that toggle button unless run in -666 mode. As the Glender UI code does not seem to support disabling a button easily, I turned the toggle button into a normal button which makes it pop back when pressed without changing state. I prefer that over removing the button altogether to not have people look for it with no end. For details please check the patch attached. A combined patch will follow in a second.
Created attachment 270985 [details, diff] Proposed patch for CVE-2009-3850 against Blender 2.49b (v4) +*blender-2.49b-r2 (23 Apr 2011) + + 23 Apr 2011; Sebastian Pipping <sping@gentoo.org> +blender-2.49b-r2.ebuild, + +files/blender-2.49b-CVE-2009-3850-v4.patch: + Bump to CVE-2009-3850 patch v4 (bug #293130) +
Stabilization of media-gfx/blender-2.49b-r2 is happening in 349847.
GLSA request filed.
@security: blender is now package.masked and older versions has been removed. Your call what do you want to do from here.
This issue was resolved and addressed in GLSA 201311-07 at http://security.gentoo.org/glsa/glsa-201311-07.xml by GLSA coordinator Sean Amoss (ackle).
