Paid Advertising
web application security lab

IE Tab Issues

While following a thread on the web application security forum about browser plugins for FireFox I remembered a project I had worked on briefly to exploit a small issue in one of Firefox’s extentions. The problem is around how IE Tab has built in sites to always render in IE Tab. The two default websites are http://* and for obvious reasons.

When I was first playing with this, I was thinking about it in context of DNS tricks, but then it occured to me yesterday that that star operator really felt exploitable (I love when people don’t really understand regex). Anyway, so in playing around with it, I realized if you just append “” to the end of any URL string (you can use a query string or a variable that doesn’t exist in an existing query string) you can begin running Internet Explorer in your browser window without even so much as a prompt.

If you have IE Tab installed click here to see a demo: launch IE in your browser.

Oh, but it gets better, if you ever find an XSS vulnerability in any website and you append that string to the end of the URL (CSRF) you can now run your vectors in IE space instead of Firefox, allowing you to run VB Script, ActiveX controls, and whatever else you want, without the restrictions of Firefox. Let’s take it one step further. You can actually launch XSS attacks against the target who has IE Tab with IE specific XSS vectors and since they will automatically switch into IE mode, you can get them to run on a single redirection. Tricky, eh?

I’ve always thought that browser plugins are one of the major security flaws in FireFox but this is a weird turn of events where it’s actually a cross between FireFox, a plugin and Internet Explorer. I think the major saving grace is that only 10-20% (estimated) run FireFox and far fewer run IE Tab. Why is this any different than just running Internet Explorer outright? Well because if you are a die hard FireFox user you probably spend far less time trying to harden IE than die hard IE users. I’m pretty browser agnostic, so I harden everything, but most people won’t - or don’t know how. I think I’ll uninstall IE Tab anyway.

12 Responses to “IE Tab Issues”

  1. Edward Z. Yang Says:

    Hmm, I do have IE tab installed, but I don’t have those two default settings. When did they get added?

    Otherwise, however, that’s a pretty interesting exploit. I have IE Tab and IE View installed, maybe I only need one…

  2. web application security lab - Archive » Detecting FireFox Extentions Says:

    […] In the same vein as the IE specific res:// URLs that can help you detect Internet Explorer, I’ve taken that detection one step further in Firefox. After discovering the issue with IETab where a user can be maliciously forced into the Internet Explorer rendering engine it got me thinking about ways to even detect that that is possible. How do you know your target is running what, and how to do you take advantage of that information. Taking advantage of it is a huge ball of wax and it completely depends on the browser plugin in question. In this case, the IETabs issue was pretty straight forward, but others may not be so straight forward, and will take a lot more time to analyze (by probably many more people than me alone). […]

  3. allonall Says:

    Your site has a xss vuln.


  4. RSnake Says:

    Uhm… I’m not sure what you are showing me, but that definitely isn’t “cross site” or “scripting” and there is no HTML injected, and the weird directory transversal thing you added to the end doesn’t do anything…. so…. unless I’m missing something I think what you are seeing is the intended behavior of how the page is designed (to show users any environmental variables passed to it).

  5. allonall Says:



  6. RSnake Says:

    What about that string? Unless there is some JavaScript executing it it is harmless. Just like it is harmless for me to write rm -rf *

    I don’t think you quite get the point of XSS.

  7. Benji York Says:

    > I think I’ll uninstall IE Tab anyway.

    Or just uncheck the “Sites liested here will always render using embedded IE” option.

  8. RSnake Says:

    That’s another option, but when I find one security hole in something I generally stay away from it for a while. Partly because it’s known that there are problems with it, and if I found one thing there may be others (in fact I have found some anomalous behavior with it that I’m concerned about but haven’t had time to research). Once any issue is published other people start poking and are likely to find additional problems. Thanks but no thanks, I’ll just stick to opening IE by hand, or using IE View for a while.

  9. Daniel Says:

    Looks like the IE Tab author has fixed this in version released last week.
    (note that’s the MozDev community bugzilla, not’s)

  10. RSnake Says:

    Interesting! Looks like someone reported it before I did. Good to know it was taken seriously. And thanks for finding my typo, Dan, I changed the offending mention of IE View to IE Tab.

  11. Penis Dickins Says:

    Don’t you have to actually, you know, hack IE first?

    All you’ve done is change the way a page loads, and if people are using IE tab they’ll probably be using IE itself frequently too.

  12. RSnake Says:

    @mr Dickins - this a two year old post you are responding to, and no, I don’t have to “hack IE” I just need to have a vulnerable string that works in IE that doesn’t work in FF. Please re-read the post that explains this. And then please re-read the comments saying that this problem has been fixed.