Closed Bug 258173 Opened 20 years ago Closed 20 years ago

Insecure tempfile creation during build process

Categories

(SeaMonkey :: Build Config, defect, P1)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: nordhaus, Unassigned)

References

Details

Attachments

(1 file, 1 obsolete file)

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.
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)
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.
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.
Severity: critical → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Priority: -- → P1
Attached patch Use _conftest instead of /tmp (obsolete) — Splinter Review
"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 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?
Attachment #158219 - Attachment is obsolete: true
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.
Attachment #158255 - Flags: review+
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.
Attachment #158255 - Flags: approval1.7.x?
Attachment #158255 - Flags: approval-aviary?
Comment on attachment 158255 [details] [diff] [review]
fix abs path test

a=mkaply for both
Attachment #158255 - Flags: approval1.7.x?
Attachment #158255 - Flags: approval1.7.x+
Attachment #158255 - Flags: approval-aviary?
Attachment #158255 - Flags: approval-aviary+
The patch has been checked in on the Mozilla trunk, the Mozilla 1.7 branch & the
aviary-1.0 branch.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Blocks: sbb?
No longer blocks: sbb?
Blocks: sbb-
(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.
(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.
Product: Browser → Seamonkey
Group: security
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: