258173 - Insecure tempfile creation during build process

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect, P1)

Description

[Stefan Nordhausen]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113
Build Identifier: http://lxr.mozilla.org/mozilla/source/configure.in#2570

The "configure.in" script (line 2570) insecurely creates temporary files in /tmp
when Mozilla is compiled under Linux. This allows an attacker to easily replace
these files with his own files. One of these files is a program that is then run
by configure.in, hence you have a local compromise of the account used to
compile Mozilla.

The insecure instruction is "cp -f conftest1.so conftest /tmp". The --force
option is used, but this will not work if Mozilla is being compiled by a normal
user: he cannot overwrite the attacker's file. If Mozilla is compiled by root,
the attacker can block /tmp/conftest with a directory. "cp -f" will not delete
directories, so this still leaves a big race condition.

If Mozilla is then installed (requires root privs) this will even lead to local
root compromise. This is especially dangerous with regard to compile-yourself
Linux distributions like Gentoo: Whenever a new Mozilla is released, you have a
great opportunity to compromise the entire system.

Reproducible: Always
Steps to Reproduce:
1. As user foo, create a shell script called "/tmp/conftest", chmod it to 755.
Fill it with:
  #!/bin/bash
  echo "this is a mozilla exploit" > /tmp/mozilla.exploit

2. As user bar, build Mozilla with "gamke -f client.mk"
3. Abort the build process after ~1 minute. The file /tmp/mozilla.exploit has
appeared which means the attacker's script got run.




This bug is also present in Thunderbird 0.7.3, where I originally found it. It
may also be present in other related software.

Comment 1

[Benjamin Smedberg]

There is an exploit here, but there isn't really a root exploit, since why in
God's name would you compile mozilla as root? "make install" doesn't run configure.

cls, is /tmp/conftest a hardcoded path, or could we just as easily use a path in
the objdir? (/me imagines $objdir/config/conftest)

Comment 2

[Stefan Nordhausen]

When you install mozilla from sources, the binaries and the other stuff will
have to be copied to /usr/wherever. This requires root privileges. So the 
program that eventually installs Mozilla _must_ have root privileges.

Now who tells this program _what_ files to copy and _where_ to place them? The
Mozilla sources do. And once you have taken control of the account that was used
to compile Mozilla you will be able to modify the sources. As a result you can
tell the install program to create SUID root binaries all over the place.


To make a long story short: "make install" needs root privs, parses the Makefile
and will do whatever the Makefile says. Since the attacker can manipulate the
Makefile, he owns the root account.

Comment 3

[cls]

Yes, /tmp/conftest is a hardcoded path but it really doesn't need to be.  I'm
sure briano picked it out of habit.  All of the standard autoconf macros use the
cwd so that should be fine for our custom test.

To revise the long story, writing to /usr needs root privs, not "make install".
 I use "make install" all of the time without root ever being involved.  The bug
is exploitable so it will be fixed.  Full stop.

Comment 4

[cls]

Attachment: Use _conftest instead of /tmp

Comment 5

[Stefan Nordhausen]

"make install" doesn't need root privs on your dev-box since you install to
/home or another place you have write access to. Gentoo users on the other hand
install to /usr since they want to use the software in production. So Gentoo
users need to run make install with root privs and will certainly not see this
bug as "minor".

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 158219 [details] [diff] [review]
Use _conftest instead of /tmp

>-  dlopen("./../tmp/conftest1.so",RTLD_LAZY);
>-  dlopen("/tmp/conftest1.so",RTLD_LAZY);
>-  dlopen("/tmp/../tmp/conftest1.so",RTLD_LAZY);
>+  dlopen("./_conftest/conftest1.so",RTLD_LAZY);
>+  dlopen("./_conftest/../_conftest/conftest1.so",RTLD_LAZY);

Can you use ${curdir} here to keep this equivalent to what the old code was
testing?

Comment 7

[cls]

Attachment: fix abs path test

Comment 8

[Benjamin Smedberg]

Comment on attachment 158255 [details] [diff] [review]
fix abs path test

Is variable expansion in heredoc not portable? Seems like we're overkilling
with the perl substitution, but either way is fine.

Comment 9

[cls]

Comment on attachment 158255 [details] [diff] [review]
fix abs path test

Substitution inside the heredoc didn't work with bash-2.05b from FC2.  I didn't
try any other shells.

Comment 10

[Mike Kaply [:mkaply]]

Comment on attachment 158255 [details] [diff] [review]
fix abs path test

a=mkaply for both

Comment 11

[cls]

The patch has been checked in on the Mozilla trunk, the Mozilla 1.7 branch & the
aviary-1.0 branch.

Comment 12

[Christopher Aillon (sabbatical, not receiving bugmail)]

(In reply to comment #1)
> There is an exploit here, but there isn't really a root exploit, since why in
> God's name would you compile mozilla as root? "make install" doesn't run
configure.

You have to be root in order to build RPMs with default settings.

Comment 13

[cls]

(In reply to comment #12)
> You have to be root in order to build RPMs with default settings.

That's an extremely poor reason for building as root given how easy it is to
setup a rpm build heirarchy for a non-root user:

echo "%_topdir ${HOME}/src/redhat" >> ~/.rpmmacros
mkdir -p ~/src/redhat/{SPECS,SOURCES,BUILD,SRPMS,RPMS/{i386,i686,noarch}}

Yes, there are some rpms that require root to build (qmail comes to mind) but
the Mozilla rpms shouldn't be one of them.  If they do, they're broken.