Your message dated Fri, 18 May 2012 15:02:47 +0200
with message-id <20120518130247.GA21769@localhost>
and subject line Re: Bug#332413: CAN-2005-3151: Bufferoverflow in blenderplayer
arg parsing
has caused the Debian Bug report #332413,
regarding CAN-2005-3151: Bufferoverflow in blenderplayer arg parsing
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
332413: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332413
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: blender
Version: 2.37a-1
Severity: normal
Tags: security
A buffer overflow has been found in the args parsing of blenderplayer.
This is a minor security problem, as it would need to trick someone
into playing a file with really quite noticably manipulated file names,
but has been assigned CAN-2005-3151 by MITRE anyway. A demo exploit
is available at http://www.securiteam.com/exploits/5BP0T2KGVA.html
Cheers,
Moritz
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-rc1
Locale: LANG=C, LC_CTYPE=de_DE.ISO-8859-15@euro (charmap=ISO-8859-15)
Versions of packages blender depends on:
ii gettext [libg 0.14.5-2 GNU Internationalization utilities
ii libc6 2.3.5-6GNU C Library: Shared libraries an
ii libfreetype6 2.1.10-1 FreeType 2 font engine, shared lib
ii libgcc1 1:4.0.2-2 GCC support library
ii libglu1-xorg 6.8.2.dfsg.1-7 Mesa OpenGL utility library [X.Org
ii libjpeg62 6b-10 The Independent JPEG Group's JPEG
ii libpng12-01.2.8rel-4 PNG library - runtime
ii libsdl1.2debi 1.2.7+1.2.8cvs20041007-5.3 Simple DirectMedia Layer
ii libstdc++64.0.2-2The GNU Standard C++ Library v3
ii libx11-6 6.8.2.dfsg.1-7 X Window System protocol client li
ii python2.3 2.3.5-8An interactive high-level object-o
ii xlibmesa-gl [ 6.8.2.dfsg.1-7 Mesa 3D graphics library [X.Org]
pi xlibs 6.8.2.dfsg.1-7 X Window System client libraries m
ii zlib1g1:1.2.3-4 compression library - runtime
blender recommends no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Package: blender
Version: 2.63a-1
Hi Dan!
On Tue, May 15, 2012 at 02:20:53AM -0400, Dan McGrath wrote:
> Well, I did some testing (on Ubuntu 12.04, but with multiple versions
> of blenderplayer) and thought I would add to the report a bit.
>
> Personally, I think this might be gone, but I will leave this up to
> you guys. Here is what I found in some tests with the exploit code.
>
> Looking at the shell code, it seems to ultimately end in "/bin/sh", so
> I would assume it give me a shell upon successful invocation. While I
> was never able to get a sh shell, I did notice some versions would
> give telltale output.
>
>
> blender-2.37a-linux-glibc2.2.5-i386-static gave:
>
>
> Loading /bin/sh failed: No error
>
>
> (gdb reports: warning: Selected architecture i386 is not compatible
> with reported target architecture i386:x86-64)
>
>
> blender-2.60a-linux-glibc27-x86_64/blenderplayer gave:
>
> Loading /home/dan/blender-build/build/linux/bin/failed:
> Error: Unable to open
> "blenderplayer/blenderplayer/blenderplayer/blenderplayer/blenderplayer/blenderplayer/blenderplayer/blenderplayer/blenderplayer/blenderplayer/blenderplayer/blenderplayer/blenderplayer":
> Not a directory.
>
> Bus error (core dumped)
>
>
>
> blender-2.61-linux-glibc27-x86_64 gives
>
> Loading /home/dan/blender-build/build/linux/bin/failed:
> Error: Unable to open
> "blenderplayer/blenderplayer/blenderplayer/blenderplayer/blenderplayer/blenderplayer/blenderplayer/blenderplayer/blenderplayer/blenderplayer/blenderplayer/blenderplayer/blenderplayer":
> Not a directory.
>
> Bus error (core dumped)
>
>
>
> So it seems that despite not being able to get an sh shell (cpu NX
> protection perhaps?), the suspicious errors ("no error" in 2.37a, and
> core dumps in the others), that the problem seems to be gone (no core
> dumps or buss errors) in 2.62 release and up (including the latest svn
> revision).
>
> If need be, I can probably poke around and try find the revisions this
> was fixed, if you need to cheery pick the patch for this bug for the
>
