Firefox invocation allows unintended root access
This is possibly not a SuSE specific problem, but since the two systems involved are both running 9.2 Pro, and it's their integrity that's at stake, and since I've no idea what the underlying mechanism is, I thought I'd start here ;) The situation: PC1 - SuSE 9.2 Pro AMD32 PC2 - SuSE 9.2 Pro AMD64 Run Firefox as root@PC2 for browsing local files (the files are only readable by root). Still on PC2, run ssh -X to get a shell as normal-user@PC1. Start Evolution on PC1, opening on PC2's display. Click on an http link in an email. A Firefox window opens with the link displayed. By chance, I noticed that the Adblock extension was missing and I happened to click on the About menu. I was surprised to see that it claimed to be the x86_64 version. Further investigation revealed that Evolution had connected to the root-invoked Firefox on PC2, rather than starting a fresh instance by normal-user@PC1 displaying on PC2. Had I not noticed this, it would have been easy for me to enable java/javascript and installed plugins etc., in the belief that the browser was running as normal-user@PC1. Note that Evolution is an innocent party here, just starting Firefox directly from the ssh session produces the same effect. The reason for mentioning it is that a link in an email can be a seductive way to trap the unwitting user. Also note that the situation does not appear to occur if the remote connection is not involved. I.e. when root@PC2 runs Firefox, then user@PC2 starts Firefox, this results in 2 instances of Firefox. IMHO, Firefox should only connect with an already running instance if that instance was started by the same user on the same host. It is questionable whether normal-user@PC1 should even be aware of the existence of the root@PC2 instance. Phil
On Tue, Mar 29, 2005 at 10:40:14PM +0100, Phil Betts wrote:
This is possibly not a SuSE specific problem, but since the two systems involved are both running 9.2 Pro, and it's their integrity that's at stake, and since I've no idea what the underlying mechanism is, I thought I'd start here ;)
The situation:
PC1 - SuSE 9.2 Pro AMD32 PC2 - SuSE 9.2 Pro AMD64
Run Firefox as root@PC2 for browsing local files (the files are only readable by root). Still on PC2, run ssh -X to get a shell as normal-user@PC1. Start Evolution on PC1, opening on PC2's display. Click on an http link in an email. A Firefox window opens with the link displayed.
By chance, I noticed that the Adblock extension was missing and I happened to click on the About menu. I was surprised to see that it claimed to be the x86_64 version.
Further investigation revealed that Evolution had connected to the root-invoked Firefox on PC2, rather than starting a fresh instance by normal-user@PC1 displaying on PC2.
Had I not noticed this, it would have been easy for me to enable java/javascript and installed plugins etc., in the belief that the browser was running as normal-user@PC1.
Note that Evolution is an innocent party here, just starting Firefox directly from the ssh session produces the same effect. The reason for mentioning it is that a link in an email can be a seductive way to trap the unwitting user.
Also note that the situation does not appear to occur if the remote connection is not involved. I.e. when root@PC2 runs Firefox, then user@PC2 starts Firefox, this results in 2 instances of Firefox.
IMHO, Firefox should only connect with an already running instance if that instance was started by the same user on the same host. It is questionable whether normal-user@PC1 should even be aware of the existence of the root@PC2 instance.
Your remote side can do even more things, like snooping or inserting keyboard input into the main X session. If you are on the same X Server you have basically full user access. I do not see this is as a problem, but workin as intended. Ciao, Marcus
On Wed, 2005-03-30 at 11:27 +0200, Marcus Meissner wrote:
Your remote side can do even more things, like snooping or inserting keyboard input into the main X session.
If you are on the same X Server you have basically full user access.
Of course, but that's not what one expects of a browser whose reputation is built, at least partly, on security. If you invite your trustworthy neighbour in for a drink, you'd be pretty upset if he took control of the TV remote, emptied your fridge and rearranged the furniture!
I do not see this is as a problem, but workin as intended.
Hmm, "as intended" != "correctly" (except perhaps in Redmond). If by "intended", you mean that there should only ever be one instance of firefox per X display, then firefox is broken, because two different users on the _same_ box start independent firefox instances, each with their own set of bookmarks, cookies, extensions etc. Why should this policy be different when running a firefox from a session on a second box? The fact remains that I clicked on a link in an email message as an unprivileged user on my web-facing machine, but found that I had connected to the web as root on a machine that normally only connects to the web for system updates. I would NEVER have connected to the web for any other purpose using my root account (on either box) by choice. If the link I had clicked was actually to a page containing some malicious exploit, I would have been completely stuffed. I can't believe that this is "as intended". Also, regardless of the security implications, if I start a session on a remote box and start firefox, I do this because I want THAT user's set of bookmarks etc., not those of some arbitrary user on a different machine. As it stands, the only way to achieve this is to shut down all prior instances of firefox first, which is neither intuitive, nor desirable. As I mentioned in my original post, I don't know the details of the underlying mechanism, as it involves the interaction of X, ssh and firefox. If you have more knowledge on this, I'll be happy to raise it with the most appropriate party. My guess would be the firefox developers, but for all I know, they may just be using some connect_to_existing_instance() routine in an independently written shared library, which could mean that many apps may be subject to the same problem. Phil
Of course, but that's not what one expects of a browser whose reputation is built, at least partly, on security.
Never rely on reputation when it comes to security.
The fact remains that I clicked on a link in an email message as an unprivileged user on my web-facing machine, but found that I had connected to the web as root on a machine that normally only connects to the web for system updates.
*Never* click on a link in an email. You should have known that it's dangerous :-)
Also, regardless of the security implications, if I start a session on a remote box and start firefox, I do this because I want THAT user's set of bookmarks etc., not those of some arbitrary user on a different machine. As it stands, the only way to achieve this is to shut down all prior instances of firefox first, which is neither intuitive, nor desirable.
If you run different X applications (or instances) on the same X session, they may influence each other. As a side note, the start script of the Mozilla applications even prevent that you start instances of Firefox and Mozilla at the same time. So if you have a running firefox and start mozilla, you get another firefox instance. Surely not intuitive, but this alone is not a security risk.
As I mentioned in my original post, I don't know the details of the underlying mechanism, as it involves the interaction of X, ssh and firefox.
It depends on how you started your root session. A simple "su" for example leaves much of the original users' shell environment intact in the root session. The firefox start script may use some of this remnants. If the X authorization is shared (often done with "sux" or "ssh -X"), root operates on the *same* X session as your unprivileged user. This is completly different than two independent console logins. So from a security point of view, you shouldn't use Xwindows applications with root. Use a text mode browser instead. -- Michel Messerschmidt, lists@michel-messerschmidt.de
participants (3)
-
Marcus Meissner -
Michel Messerschmidt -
Phil Betts