Thursday, May 21, 2009

pwning FireFox via "extension-jacking"

This post is a follow-up to my previous post called "FireFox Plug-In Design Flaw Yields ffspy PoC"; and yes, another "{click|side|extension|whatever}-jacking" phrase comes at you.  Not that I particularly like the idea of having a browser extension "jacked" but if you think about it carefully, as I have been for the last several hours, the whole point is essentially m00t.  One of the folks who read this previously and commented, Steve Pinkham, had an interesting point - sadly I have to say that when I got caught up in the sheer pandelerium of this fun new exploit, I didn't really think about the bigger picture...
"I agree, this isn't really novel.
It's an interesting POC, but if I have local access to your file system, there's tons easy ways to own you...

We just don't have systems that were designed to stand up to local access, case closed. An attacker could just as easily modify one of firefoxs own executables or libraries, your proxy settings, etc...
"

So to Steve, thanks for setting me straight - and now with the "Big Picture" in mind I'm writing this as a 49,998ft view of the whole mess.

Let's think about this logically, since there are many things at play here.  First off there's the use of XUL by FireFox for things like an extension manifest... which allows for arbitrary script tags!  Granted most of the .xul files I first-hand witnessed were "chrome://xxxxx" but it could have just as easily been 'https://malicious.tld/malicious.js" or something of that nature.  To say that this is a bad way of doing it is an understatement -but what's the real issue?  The real issue is that Mozilla went for simplicity, speed, and extensibility over security - an obvious choice many times over.  Next, let's look at the amount of effort it would take to somehow change this mechanism...  Even if Mozilla did decide to change the way extensions function and MD5sum that file, and store it somewhere... or whatever they did - it would automatically break every since extension immediately... granted that Mozilla developers are famous for beaking extensions from version to version (even on minor revs??!!) but this would anger more than just a few people.

Next, let's think about the problem in a macro-chosm of nastiness on the web.  We are taught not to trust the web, or anything that comes from a source you don't explicitly trust.  But how do we know what to trust?  I personally have at least 5 extensions in my FireFox browser that I never even pretended to look at the source code for.  Are they stealing key strokes, logging my bank passwords?... who knows!  The problem is that they pop up like mushrooms after a spring rain - and no one's realistically going to review them all... certainly not the Mozilla folks.

Perhaps the most hard-to-swallow design flaw with plugins is that they have access to the raw browser's stream... before it hits the encryption routines.  This effectively means that not only does a plug-in have access to keystrokes, URLs, full-text of your POSTs but it has access to all that pre-encryption onto the SSL stream.  Talk about game over!

In the final analysis, at least for me, it doesn't really matter that FireFox chooses to use XUL, which allows for an arbitrary script tag in extension manifest file... although that is a seriously neat trick.  What really matters is that the attack surface of FireFox is laid bare through the plug-in/extension architecture which in my humble opinion is fundamentally flawed from a security perspective.  It doesn't matter if we sign/encrypt/check-recheck that manifest file for a maliciously injected script src="http://malicious.tld/malicious.js" ... the browser is hosed anyway, long before that.

I'm hoping that this sparks the Mozilla folks to re-examine their architecture and seriously re-design their plugin/extension interface... I offer my humble support should it be requested.

Good luck!

3 comments:

David Blanc said...

I do not quite agree with some portion of your article. Extensions and plugins of any software run in the context of the user running it. This is not only true for Firefox but any other software that supports extensions, plugins, addons, etc. Take for example an emacs plugin. An emacs plugin can send a lot of sensitive data of the user to a remote computer while the user is editing a document. Now, do you say that Emacs plugin mechanism is flawed too?

David Spencer said...

Hi Rafal,

Thanks for writing this clarification blog. But there are some things I am still not able to understand. If the attacker has pwned your computer, how in any manner can you check for the integrity of the installed addon?

If the attacker has pwned the computer good enough to modify or compromise an addon, he can as well disable the addon integrity check or pwn it so that Firefox does notify the user of any addon compromise. Could you please throw some light on this area?

So, I don't see anything that Firefox or any other software which allows plugins can do in this case.

Raf said...

@David:
Sometimes I put up a post getting too "deep in the weeds" and absolutely miss the bigger picture, I'm ashamed to say. You seem to have stumbled upon that "big picture" in your comment. Yes, in the micro-world of the browser this is a big deal - but as you and a few others have pointed out by the time you're dropping payload through the browser into the file-system... the game is already over. So - while I will contend this is an issue - there are bigger fish on the hook here.

Thanks for reading and taking the time to comment.

Google+