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

[Anton Gyllenberg]

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

[Justin Pryzby (justinpryzby-users)]

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

[Masayuki Hatta (mhatta)]

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-----

[Martin Dickopp (martin-zero-based)]

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

[Masayuki Hatta (mhatta)]

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-----

[Anton Gyllenberg (antong)]

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

[Martin Bergner (martin-bergner)]

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)]

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.

[Vincent Legout (vlegout)]

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.

[Anton Gyllenberg (antong)]

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)]

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

[Kees Cook (kees)]

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 ?

[Till Ulen (tillulen)]

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/>?

[Till Ulen (tillulen)]

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)]

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?

[Lubomir (lubomir-redhat-bugs)]

Common Vulnerabilities and Exposures assigned an identifier CVE-2008-1103 to the following vulnerability:

Multiple unspecified vulnerabilities in Blender have unknown impact and attack vectors, related to "temporary file issues."

References:

http://lists.opensuse.org/opensuse-security-announce/2008-04/msg00011.html
http://www.securityfocus.com/bid/28936

[Anton Gyllenberg (antong)]

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

[Kees Cook (kees)]

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).

[ideasman42 (ideasman42)]

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)]

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)]

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.

[Kees Cook (kees)]

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.

[ideasman42 (ideasman42)]

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

[Anton Gyllenberg (antong)]

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.

[Tomas (tomas-redhat-bugs)]

Noted in SuSE advisory:

  Since we do not think that Blender is not used in security critical settings
  with network input data we fixed this problem only for future products.

The temporary file issue is not currently fixed in SuSE packages.

Further details regarding this are covered in Ubuntu and Debian bug reports:

https://bugs.launchpad.net/ubuntu/+source/blender/+bug/6671
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298167

Problematic files in /tmp are:
- /tmp/quit.blend
- /tmp/0001.jpg, /tmp/0002.jpg, ...

First issue seems to have been fixed in the past in Debian packages, first using
O_EXCL in open(), later replaced with move of temporary directory to user's
$HOME. Debian patches attached in following comments.

[Tomas (tomas-redhat-bugs)]

Created attachment 304747
First Debian patch

Occurred in:

http://packages.debian.org/changelogs/pool/main/b/blender/blender_2.45-5/changelog#versionversion2.36-1

[Tomas (tomas-redhat-bugs)]

Created attachment 304748
Second Debian patch

Moves quit.blend to $HOME, first occurred in:

http://packages.debian.org/changelogs/pool/main/b/blender/blender_2.45-5/changelog#versionversion2.37a-1

[Jochen (jochen-redhat-bugs)]

I have checkin blender-2.45rc3 on rawhide. On this version I could apply the
first patch, but the second one failed. Perhaps anyone may have a look on it,
bacause I have no idea how I should modified this patch for the next blender
release.

[Tomas (tomas-redhat-bugs)]

Jochen, I believe either one of the Debian patches should be sufficient to
address quit.blend issue. Does it also address the other issue with 000X.jpg?

[Jochen (jochen-redhat-bugs)]

Maybe, Unfortunately, I'm unsure and have contact the updatream.

I think, I should build a package for rawhinde with the first debian patch and
wait on the response of the upstream.

[Tomas (tomas-redhat-bugs)]

Second issue -- /tmp/000X.jpg -- still affects new blender-2.45-14 packages,
confirmed with blender-2.45-14.fc8.

[Tomas (tomas-redhat-bugs)]

Secunia assigned CVE id CVE-2008-1103 to the Multiple Temporary File Security
Issues and the description is now available here:

  http://secunia.com/advisories/29842/

  [ ... ]

  The security issues are caused due to Blender handling temporary files in
  an insecure manner (e.g. creating "/tmp/quit.blend" when quitting Blender,
  using easy to guess file names and insecure file permissions to store
  temporary render frames, and insecure file permission when auto saving
  files). This can be exploited to e.g. conduct symlink attacks and overwrite
  arbitrary files with the permissions of the user running Blender or
  disclose potentially sensitive information.

Besides the two issue already described in the comment #1, there is the third
issue covered by this CVE id:

- insecure file permission for auto saved files

[Daniel T Chen (crimsun)]

Is this symptom still reproducible in 8.10 alpha?

[Anton Gyllenberg (antong)]

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"?

[Adam Buchbinder (adam-buchbinder)]

Anton Gyllenberg: nope. Marking Confirmed.

[Stefan (stefan-redhat-bugs)]

There is still an issue with regards to the /tmp/000x.jpg files being created which could cause symlinks attacks. Is anyone addressing this or know if it has been addressed?

[Stefan Lesicnik (stefanlsd)]

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.

[Jochen (jochen-redhat-bugs)]

I'm to get a anser of the bf-commiter mailing list.

[Jochen (jochen-redhat-bugs)]

Sorry, I would write: 'I'm trying to get an answer on the bf-commiter mailing list'

[Jochen (jochen-redhat-bugs)]

I have got the following anser:

"People can change the temp path in user settings if they disagree with the default value."

But I think this is not the expected solution, so I have poke again on bf-commiters.

[Stefan (stefan-redhat-bugs)]

Thanks for chasing this Jochen. I agree with you, I don't think it is great default behaviour and default should be somewhere more sane.

I also opened a bug on the blender bug tracker http://projects.blender.org/tracker/index.php?func=detail&aid=18174&group_id=9&atid=125

[Marc Deslauriers (mdeslaur)]

Reported upstream as bug #18174 (login needed)

[Festor (festor-deactivatedaccount)]

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

[Chris Coulson (chrisccoulson)]

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

[Red (red-redhat-bugs)]

Reporter changed to <email address hidden> by request of Jay Turner.

[Jan (jan-redhat-bugs)]

Stefan, Jochen,

(In reply to comment #16)
> Thanks for chasing this Jochen. I agree with you, I don't think it is great
> default behaviour and default should be somewhere more sane.
>
> I also opened a bug on the blender bug tracker
> http://projects.blender.org/tracker/index.php?func=detail&aid=18174&group_id=9&atid=125

Was this second issue solved yet? (I doesn't seem to be able to access
above ticket, as getting "Invalid Artifact ID").

Thanks, Jan.

[Stefan (stefan-redhat-bugs)]

Hi,

Im not sure if this issue was ever solved. Don't remember getting an update, and I am getting the same error as you. I guess it doesn't help either that search is disabled...

Stefan

[rusivi2 (rusivi2-deactivatedaccount)]

Thank you for reporting this bug.

Does this problem occur in Lucid?

[Anton Gyllenberg (antong)]

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