Cenzic 232 Patent
Paid Advertising
web application security lab

Firefox Remote Variable Leakage

Ronald just posted an interesting PoC code that quickly enumerates a huge chunk of the variables inside Firefox. Basically, by including the JavaScript from the plugins, and the chrome in the page, by iterating over the list, you get all the variables out of the plugins. Here’s his writeup. Depending on what security information lives in those plugins, you could theoretically find some really nasty stuff.

As it stands this is only for recon, but plugins tend to do lots of dangerous things, like store personal information, or give access to the drive, or what have you. By being able to access those functions and variables directly, that could give an attacker all the tools necessiary to pretty much hose a machine depending on what you’ve got installed. Ouch. The PoC lives here. It doesn’t steal the variable information in the PoC but it easily could. Very nice work by Ronald!

16 Responses to “Firefox Remote Variable Leakage”

  1. David Says:

    This is nothing new though, and has been posted on this very blog before: http://ha.ckers.org/blog/20070516/read-firefox-settings-poc/

  2. Giorgio Maone Says:

    https://bugzilla.mozilla.org/show_bug.cgi?id=292789

  3. sirdarckcat Says:

    Is this really a dangerous behavior?

    The script loaded from any site (chrome://content, http://www.google.com, ftp://, etc..) is executed in the context of the document.. so by including this scripts, you are not doing anything, you can’t already do.

    Am I wrong?

  4. Ronald van den Heetkamp Says:

    @David
    Not quite, the res:// scheme could not read all Javascript files (only a couple) whereas chrome:// can. Mozilla blocked the res:// as a result next.

    This is complete chrome access, I can’t think you can do better then that. Because it not only let’s me read all variables and objects, I can launch functions too.

    The reasons why no one noticed or thought about the impact is that they did not see all variables, objects, functions that became accessible through it. Security through obscurity, the asset of a great browser.

  5. mybeNi websecurity Says:

    I agree with sirdarckcat, I see no malicious opportunities coming with these includes?!

  6. Dan Veditz Says:

    @Ronald
    There is nothing “obscure” about it. You can include script from anywhere and it runs in the context of your page. The extension functions may have special powers in a “chrome” context, but including them in your page through can do nothing more than writing out the function in-line in your page by copying the source files. And since the browser and most extensions are “Open Source” (and even those that are not are still plain text) there are no secrets in the javascript to keep hidden.

  7. RSnake Says:

    Dan - I think what Ronald is saying is that there are functions/variables in the addons themselves with sensitive information in them.

  8. Spikeman Says:

    One could theoretically find a vulnerability in an extension, and by using this you could check if said extension is installed. As far as I know, what’s so bad about vulnerabilities in extensions is that the code runs in chrome://, which allows access to restricted things that you wouldn’t otherwise be able to access with scripts. Of course most of these attacks are rendered useless thanks to Noscript, but if you could somehow exploit an extension without using Javascript, it would be bad news.

  9. Ronald van den Heetkamp Says:

    Yes indeed, that’s why I said that it could lead to future attacks on extensions and plugins.

    Today I was able to remotely trigger functions from FoxyProxy (Tor).
    And… *cough* that doesn’t seem to be a good idea Dan. If I wasn’t so lazy I threw up a PoC :) Yeah, great feature. It’s the best feature Firefox has.

    Well, I don’t care what anyone calls it, Let’s be real and think about the clueless users who think they run a secure browser. I think it sucks that this is possible. I should not have access to chrome:// in anyway.

  10. Joe Says:

    “Firefox Remote Variable Leakage” sounds really serious and
    https://bugzilla.mozilla.org/show_bug.cgi?id=292789 starts to
    be really annoying to my inbox.

    But:
    Where is the bug? I can’t find it. As long as it’s not possible to
    cross the border between content and chrome there is no need
    for “pseudo panic”.

    BTW: Bug 292789 was reported in march 2005.

    Is there any really poc? I can’t find a poc that deserves its name.

  11. sirdarckcat Says:

    Ronald:

    Are you saying that you were able to execute a javascript code that had access to the Plugin ?

    If you have, that’s a extremely dangerous behavior, if you pass as a variable a monitored variable ( http://www.sirdarckcat.net/jse2.html ), you could be able to execute javascript code in the context of chrome.

    Any way, there are some plugins that do allow me to execute code (for example, Firebug) but the code is executed in a safe context, because “I am inside a Sandbox”, any way, Firebug is the only code I know that inputs the code inside a Sandbox, if you are actually able to pass code to a plugin, then you have a chrome privilege escalation bug, that can lead to complete browser compromise.

    Any way.. as far as I can tell, it’s impossible to get inside plugins scripts, just by executing the same code that chrome executes..

    Try this:
    1.- Copy the javascript code of any plugin.
    2.- Paste it inside script tags.
    3.- Compare the results of that with the PoC using script src=chrome

    The result should be exactly the same.

    Greetz!!

  12. Wladimir Palant Says:

    RSnake, unless the extension author does something extremely stupid you don’t get any sensitive information by including a script file from chrome://. These are static files containing browser/extension source code, they don’t contain any dynamic information that you might be interested in. So you can only use this for extension detection - but we had this already, right?

  13. RSnake Says:

    @Wladimir - according to Ronald, he has found some stupid extensions. ;)

  14. Ronald van den Heetkamp Says:

    @sirdc

    Oh you can include anything from the chrome, I figured everyone would understand that, and did not bother to throw up a PoC. I don’t have unlimited time to write nice PoC’s you see.

    @Wladimir Palant
    Oh yes it was known, so were the Java popups and a million other bugs, but no one seem to bother to fix it. Everything is “known” well, if everything is known, why does it headlines The Register.

    You know what, I keep this stuff for myself from now on, cause “everything” is already known, yes to arrogant pricks everything is known.

    I love you guys :)

  15. Wladimir Palant Says:

    RSnake, he didn’t. The “password” he got is not the one used by the extension - he just included the code that generated a new (worthless) password.

    Ronald - sorry but your post generated way too much buzz. I mean, inclusion of chrome:// files was discussed here in much detail a year ago, and you were there. Your current post now assumes that you can read dynamic information through this mechanism - that’s a misunderstanding, you really cannot. Meaning that this feature/bug is annoying (http://adblockplus.org/en/faq_internal#protectchrome) but not really the huge hole that you are trying to show us.

  16. Anthon Says:

    As long as there’s no real PoC
    your “Firefox Remote Variable Leakage” is FUD.