247412 - when firefox is running as root, other users on the same display can gain root privileges

Status: RESOLVED INVALID

(Firefox :: General, defect, P2)

Description

[Florian Wilhelm]

User-Agent:       Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7) Gecko/20040617 Firefox/0.9
Build Identifier: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7) Gecko/20040617 Firefox/0.9

If you start firefox as a normal user and root is already running a firefox
instance, the firefox started by the normal user gains root privileges. 

Reproducible: Always
Steps to Reproduce:
1. open an X terminal as normal user
2. type su and login as root
3. start firefox 0.9 as root
4. open another terminal
5. start firefox as normal user

Actual Results:  
firefox can read/write with root privileges although startet as normal user.

Expected Results:  
firefox should start a new instance of firefox instead of attaching to the
currently running root firefox process.

firefox should never be run as root, but it is much easier to install global
search engines and themes as root. When run as root, another (bad) user could
use this bug to gain root access and to compromise the system.

Comment 1

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Verified on Linux, FF 0.9.

I installed it as root into /usr/local/firefox, and the installer started FF
automatically. While it was running, I opened FF as a normal user, but it seems
like it gave me an instance of the root FF because I was able to write into
root's home directory using FF which I am not able to do from the command line,
for example.

I tested this on Windows, but when I launched FF as a non-Administrator user it
presented me with a profile selection dialog (on Linux it did not do this) and I
was unable to even start with the same profile because it notices it is locked.
So Windows seems safe.

Comment 2

[Heikki Toivonen (remove -bugzilla when emailing directly)]

*** Bug 253083 has been marked as a duplicate of this bug. ***

Comment 3

[Tom Unger]

(In reply to comment #1)
> 
> I tested this on Windows, but when I launched FF as a non-Administrator user it
> presented me with a profile selection dialog (on Linux it did not do this) and I
> was unable to even start with the same profile because it notices it is locked.
> So Windows seems safe.
In my opinion Windows is not safe. Firefox does not start an extra instance.

Comment 4

[Blake Ross]

-> bryner

Comment 5

[Brian Ryner (not reading)]

shaver and I discussed this and we don't think this is really a security
vulnerability, based on the fact that you must already have access to the X
display where the root browser is running.  So it doesn't allow a user at a
particular display to gain any privileges they didn't already have in an
already-open browser.  Or are you claiming that this somehow takes a browser
running as root on a separate display and opens a window of it on a non-root
user's display?

Comment 6

[Tom Unger]

(In reply to comment #5)
I do not know what to say to the situation to linux. 
I can say something to the windows-world. It's generally the same question but
different user-behaviour. The problem i had was, i wanted to run the browser in
a user-env with even lower rights compared to the current account (restricted user).
I would expect that the instance fired up via runas inherits the given
user-rights which is the expected behaviour if you use sudo or runas.

BTW: if u use "fast userswitching" of XP then the problem does not show.

Comment 7

[Heikki Toivonen (remove -bugzilla when emailing directly)]

(In reply to comment #5)
> shaver and I discussed this and we don't think this is really a security
> vulnerability, based on the fact that you must already have access to the X
> display where the root browser is running.  So it doesn't allow a user at a

But isn't it possible to configure your system so that everyone will always have
access to your X display? Not advisable, but possible. 

(I think we used to have machines configured like that in my university until a
sysadmin noticed this and closed the hole. It was fun to run trick programs on
your friend's screen though - my favorite was when the display would slowly dim
over time making it harder and harder to read, but the progress being so slow
that it took a while to realize you were being played with.)

Comment 8

[Ben Goodger (use ben at mozilla dot org for email)]

Not a "blocker"

Comment 9

[Jesse Ruderman]

Bryner says this isn't really a security hole, and Ben says it's not a release
blocker, so I think this bug should be made public.

Someone who understands this bug better should update the summary to mention the
(mis)configuration necessary for this bug to appear.

Comment 10

[Daniel Veditz [:dveditz]]

Agreeing with comment 9, removing confidential flag.

Comment 11

[Ben Bucksch (:BenB)]

However, it is a security bug to automatically start Firefox as root and lead
people to browse as root.

Comment 12

[Ben Bucksch (:BenB)]

(I was referring to comment 1 - the installer)

Comment 13

[Ben Bucksch (:BenB)]

I filed bug 267303 about comment 11 / 12.

Comment 14

[Foske]

Bug still valid in 1.0. Guys... I thought some Redmond company has already
showed us a combination of "not dangerous" bugs can lead to problems. The
attitude here regarding this issue really is scaring me. Sure, it's a hard one
to exploit but, as hackers learned us in the past, never say impossible.

Comment 15

[Christopher Blizzard (:blizzard)]

Although the summary on this bug makes it Big and Scary, it's not really a bug.
 There are no elevated privileges involved here.

The first instance of firefox, the one run as root, has access to your X display
(your screen) as you would expect.  The second copy of firefox that you run is
running as the user (not root) and it looks at the X display to see if there's
an already running instance of firefox already running.  There is (the one
running as root) so it makes a request to that already running instance to open
a new window.  Then the second instance exits.  So it never elevates its privileges.

This is a trick of the environment.  Note that the reporter uses the command
'su'.  From the info page for the command 'su':

   "By default, `su' does not change the current directory.  It sets the
environment variables `HOME' and `SHELL' from the password entry for
USER, and if USER is not the super-user, sets `USER' and `LOGNAME' to
USER.  By default, the shell is not a login shell."

When the reporter used 'su' firefox uses what's set in LOGNAME to determine what
user ran it.  It sets that value on the window that's displayed on your screen.
 In this case, the LOGNAME was actually set to the _original user who ran the
command 'su'_.  So when that second instance is fired up, it looks at the
already running instance and says "oh, it's the same user" and just asks it to
open a new window.

If you want to avoid this problem what you can do is make sure that you always
use the command 'su -' instead of just plan old 'su'.  'su -' will run a login
shell which will set LOGNAME to root and the second instance of firefox will
open an entirely new instance when the usernames don't match.

As an interesting side note, if you tried to run firefox as an entirely
different user against the same display it would have fired up a new instance
instead of asking the current instance to open a new window since the usernames
would not have matched.

So simply put, this isn't a security bug, but is just due to the way that 'su'
works.  If you want to use 'su' and then run X commands (like firefox) make sure
that you make it give you a 'login shell' via 'su -' or 'su -l'.

X allows programs with different privileges to communicate over the X protocol
without any knowledge of who is doing that communication.  At least in part,
this is part why this problem shows up.  You have to use heuristics like using
LOGNAME to try and figure that information out.

Comment 16

[Jesse Ruderman]

Continued discussion in bug 353203.