Ubuntu

insecure file access (breezy, dapper, edgy, gutsy, hardy, intrepid)

Reported by Anton Gyllenberg on 2006-01-11
266
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Blender
Incomplete
Undecided
Unassigned
blender (Debian)
Fix Released
Unknown
blender (Fedora)
Fix Committed
Unknown
blender (Ubuntu)
Medium
Unassigned

Bug Description

Reproduced in versions:
    2.37a-1ubuntu1.1 (breezy?)
    2.41-1ubuntu4 (dapper)
    2.42a-linux-glibc232-py24-i386-static (blender.org binary)
    2.42a-1ubuntu1.1 (edgy)
    2.44-2ubuntu2 (gutsy)
    2.45-4ubuntu1 (hardy)
    2.46+dfsg-4 (intrepid)

Blender writes to files in /tmp/ in an insecure fashion. For example, launching blender and then selecting "Render > Render Animation", writes to the file /tmp/0001.jpg.

This can be exploited by a malicious user to overwrite arbitrary files of another user using blender:

mallory@myhost$ ln -s /home/bob/thesis.tex /tmp/0001.jpg

CVE References

# Automatically generated email from bts, devscripts version 2.8.10
tags 298167 patch

Source: blender
Source-Version: 2.36-1

We believe that the bug you reported is fixed in the latest version of
blender, which is due to be installed in the Debian FTP archive:

blender_2.36-1.diff.gz
  to pool/main/b/blender/blender_2.36-1.diff.gz
blender_2.36-1.dsc
  to pool/main/b/blender/blender_2.36-1.dsc
blender_2.36-1_i386.deb
  to pool/main/b/blender/blender_2.36-1_i386.deb
blender_2.36.orig.tar.gz
  to pool/main/b/blender/blender_2.36.orig.tar.gz

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Masayuki Hatta (mhatta) <email address hidden> (supplier of updated blender package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Fri, 11 Mar 2005 00:55:14 +0900
Source: blender
Binary: blender
Architecture: source i386
Version: 2.36-1
Distribution: unstable
Urgency: high
Maintainer: Masayuki Hatta (mhatta) <email address hidden>
Changed-By: Masayuki Hatta (mhatta) <email address hidden>
Description:
 blender - Very fast and versatile 3D modeller/renderer
Closes: 285578 288882 288883 298167
Changes:
 blender (2.36-1) unstable; urgency=high
 .
   * The "Back From The Gig" release.
   * Urgency is set to high, since this release fixes a security issue. Woody doesn't have free Blender.
   * [02_fix_insecure_writing_to_quit_blend] added a dpatch to prevent a symlinkattack - closes: #298167
   * New upstream release - closes: #288883
   * Acknowledged NMU, sorry for delay and thanks guys - closes: #288882
   * Now fully updates the plugins every time blender is launched - closes: #285578
Files:
 5c78abcbfe5277a84d951a345ca7c4ac 736 graphics optional blender_2.36-1.dsc
 8e2237c86b12e6061935632495aec875 6912828 graphics optional blender_2.36.orig.tar.gz
 5cb1bb355513b45b618f169544cc4029 12285 graphics optional blender_2.36-1.diff.gz
 95e3594d330cf86e15b873b02573e159 3932958 graphics optional blender_2.36-1_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCMIHBy2+jQOcHWlQRAg5KAKC/1/r5BnO6+d1aQPBZuF6AWZoXFACgoIDW
7zWzUMl5YFTOdWMR3OcatFM=
=kfjy
-----END PGP SIGNATURE-----

reopen 298167
tags 298167 - security
severity 298167 wishlist
retitle 298167 blender: please revert writing quit.blend with O_EXCL and make U.tempdir default to a userdir instead
thanks

Hi,

Creating quit.blend with the O_EXCL flag has a major drawback: after the
file has been written for the first time, all further attempts to write
it again will fail. This makes the feature quite useless, IMHO.

A much better solution, IMHO, would be to make U.tempdir default to a
directory that is not world-writable, e.g. the user's home directory.
Note that the user can configure the value of U.tempdir within Blender,
so she or he can change it to a directory of her or his liking.

This solution would also be more robust with respect to future security
bugs, should future Blender versions use U.tempdir for other purposes
than just creating quit.blend there.

I therefore suggest replacing this code

        if (BLI_streq(U.tempdir, "/")) {
                char *tmp= getenv("TEMP");
                strcpy(U.tempdir, tmp?tmp:"/tmp/");
        }

with

        if (BLI_streq(U.tempdir, "/")) {
                strcpy(U.tempdir, BLI_gethome());
        }

in source/blender/src/usiblender.c.

Thanks,
Martin

Source: blender
Source-Version: 2.37a-1

We believe that the bug you reported is fixed in the latest version of
blender, which is due to be installed in the Debian FTP archive:

blender_2.37a-1.diff.gz
  to pool/main/b/blender/blender_2.37a-1.diff.gz
blender_2.37a-1.dsc
  to pool/main/b/blender/blender_2.37a-1.dsc
blender_2.37a-1_i386.deb
  to pool/main/b/blender/blender_2.37a-1_i386.deb
blender_2.37a.orig.tar.gz
  to pool/main/b/blender/blender_2.37a.orig.tar.gz

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Masayuki Hatta (mhatta) <email address hidden> (supplier of updated blender package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Tue, 6 Sep 2005 17:52:51 +0900
Source: blender
Binary: blender
Architecture: source i386
Version: 2.37a-1
Distribution: unstable
Urgency: low
Maintainer: Masayuki Hatta (mhatta) <email address hidden>
Changed-By: Masayuki Hatta (mhatta) <email address hidden>
Description:
 blender - Very fast and versatile 3D modeller/renderer
Closes: 285577 298167 304567 313676 316524 319307
Changes:
 blender (2.37a-1) unstable; urgency=low
 .
   * Works had been done at Codefest Asia 2005 in Colombo, Sri Lanka.
   * New upstream release - closes: #316524
   * Bumped Standards-Version 3.6.2.1 (no physical changes).
   * Now the package include blenderplayer - closes: #304567
   * Now it should be built on amd64 with gcc-4.0 - closes: #285577, #319307
   * Now quit.blend is created in the user's homedir - closes: #298167
   * Fixed de.po - closes: #313676
Files:
 1cad4af1a7c382dac16d089a30bceea7 740 graphics optional blender_2.37a-1.dsc
 2af6afdb01c1d297c43602982d9a919c 7885589 graphics optional blender_2.37a.orig.tar.gz
 ae9f4939702135e2b738e26b88886736 3388 graphics optional blender_2.37a-1.diff.gz
 4a1b7a229e084686024e76545a00c91d 4239716 graphics optional blender_2.37a-1_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDHnxNy2+jQOcHWlQRAuMAAJ924sjh9SrQWhSMCvblyAHVdp3EtwCgoBHF
uk8ORn3vzHQbBGTJ97mI7WM=
=DBe9
-----END PGP SIGNATURE-----

Version: 2.37a-1ubuntu1.1

Blender writes to files in /tmp/ in an insecure fashion. For example, launching blender and then pressing 'a' (for animation?) writes to the file /tmp/0000.jpg.

This can be exploited by a malicious user to overwrite arbitrary files of another user using blender:

mallory@myhost$ ln -s /home/bob/thesis.tex /tmp/0000.jpg

description: updated

Do you know if this is still a problem with the 2.42 release of blender? If so, could you please report the bug upstream at http://projects.blender.org/tracker/?group_id=9&atid=125 ?

Anton Gyllenberg (antong) wrote :

I did a quick test with the binary from blender.org: blender-2.42a-linux-glibc232-py24-i386-static, and yes, it seems it does the same thing.

But, the 2.42a binary I downloaded also has a similar vulnerability for /tmp/quit.blend, something that I think was fixed long ago in debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298167

I just ran the binary from the unpacked tar file, I did not try to install it in any way.

description: updated

You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Thanks in advance.

Changed in blender:
importance: Undecided → Medium
status: New → Incomplete
description: updated

Vincent, I upgraded to 7.10 and verified that the bug is still present in the 2.44-2ubuntu2 version. I updated the bug description accordingly.

This is not a huge issue for me personally as I only run blender on my personal machine where I am the only user. At least if run on a multi-user system I would consider this is a security issue.

Daniel Hahler (blueyed) wrote :

Can somebody report this upstream, please - if it's still in 2.45 (Ubuntu Hardy)?

Changed in blender:
importance: Medium → High
status: Incomplete → Triaged
description: updated
description: updated

I don't see this behavior. The "render directory" setting by default is //render which is the homedirectory, not /tmp. Perhaps you have an older .blender directory that contains settings for /tmp ?

Changed in blender:
assignee: nobody → keescook
status: Triaged → Incomplete

Is this the same issue as CVE-2008-1103, an unspecified insecure temporary file creation vulnerability reported in a recent SUSE advisory <http://lwn.net/Articles/279763/>?

It seems that Launchpad has automatically added a CVE reference to this bug without asking me for a confirmation. I'll remove the reference now to prevent possible confusion. If you know that this problem and CVE-2008-1103 are in fact the same issue, please add the CVE reference again.

Anton Gyllenberg (antong) wrote :

I created a new user for testing this, no ~/.blender directory or ~/.B.blend file. Still happens for me.

Kees, do you have a ~/.B.blend file that would override the renderdir?

Anton Gyllenberg (antong) wrote :

Reproduced on a fresh installation (hardy desktop). I don't believe this is due to some old configuration files left behind.

Kees Cook (kees) wrote :

Ah-ha! .B.blend was the key. Yes, this is a bad default -- thanks for staying on this bug. It had gotten lost (it was marked "security" but didn't have "ubuntu-security" subscribed to it).

Changed in blender:
assignee: keescook → nobody
importance: High → Medium
status: Incomplete → Confirmed
ideasman42 (ideasman42) wrote :

regarding "ln -s /home/bob/thesis.tex /tmp/0001.jpg"

Should this problem be resolved by first removing the file before writing?
That or checking if the file is a symlink, if so remove the symlink?

Mauro Vale (maurovale) wrote :

Blender should use a random file name every time it needs to render.

This way it is impossible to overwrite anything with a symlink ;)

ideasman42 (ideasman42) wrote :

Blender needs to be able to access rendered image sequences so it can play them back. random names could work, but only while blender was running. people often work on an animation over many days/weeks, so only allowing them to play their animation during a single session is not good.

basically if bob isnt sure who's tempering with his temp directory, he should not render to it. or give people read only access to his home dir.

I think removing symlinks is a reasonable solution to this. rendering to /tmp is a bit weak, so failing that, we could define a render dir for blender to use, perhaps in their home directory.

On Thu, May 01, 2008 at 10:24:51AM -0000, Mauro Vale wrote:
> Blender should use a random file name every time it needs to render.

Well, use of /tmp should be only by mkstemp().

> This way it is impossible to overwrite anything with a symlink ;)

Alternatively, require that the files not exist first, using open with
O_CREAT and O_EXCL.

In this case it seems blender should have its own scratch directory like the gimp does.

Anton Gyllenberg (antong) wrote :

One possibility to consider would be to create a temporary directory under /tmp and use that in every place where /tmp is currently used.

You cannot remove the symlinks as they are not owned by you.

Daniel Hahler (blueyed) on 2008-05-28
Changed in blender:
status: Confirmed → Triaged
Daniel T Chen (crimsun) wrote :

Is this symptom still reproducible in 8.10 alpha?

Changed in blender:
status: Triaged → Incomplete
description: updated
Anton Gyllenberg (antong) wrote :

Daniel T Chen wrote on 2008-09-14:
> Is this symptom still reproducible in 8.10 alpha?

Reproduced in 2.46+dfsg-4 (intrepid). I updated the bug description to reflect that. Is there something else needed to get the bug status to not be "incomplete"?

Anton Gyllenberg: nope. Marking Confirmed.

Changed in blender:
status: Incomplete → Confirmed
Stefan Lesicnik (stefanlsd) wrote :

Hi Guys,

I've had a look at the problem and i can reproduce it. It also still exists in Blender 2.48a.

Perhaps someone with some blender experience and rendering could advice. I see that blender has an option to change the rendering output directory (-o).

Would it work (blender wise / process etc) if we put the renderings in $HOME/.blender/render?

We could easily output the files there in the current users home directory which I believe would solve the issue.

Marc Deslauriers (mdeslaur) wrote :

Reported upstream as bug #18174 (login needed)

Changed in blender:
status: Unknown → Fix Committed

No login needed:

http://projects.blender.org/tracker/index.php?func=detail&aid=18174

It seems that 02_tmp_in_HOME patch solves this problem, no?

02_tmp_in_HOME patch:

http://patches.ubuntu.com/b/blender/extracted/02_tmp_in_HOME

Changed in blender:
status: Unknown → Fix Released
Chris Coulson (chrisccoulson) wrote :

This one has been fixed in ubuntu for a while now with debian/patches/02_tmp_in_HOME

Changed in blender (Ubuntu):
status: Confirmed → Fix Released

Thank you for reporting this bug.

Does this problem occur in Lucid?

Changed in blender:
status: New → Incomplete
Anton Gyllenberg (antong) wrote :

rusivi1, No, I think it was fixed for Jaunty.

To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.