Some colleagues and I have been doing some research into various URI schemes and we came across a very peculiar URI. This URI basically allows us to use IE to spawn an instance of FireFox (if the user has recent version of firefox2 installed on the machine). Normally, this wouldn't be too big of an issue, however in this case, we can pass arbitrary arguments to the URI, which ultimately get passed to FireFox.exe. With this in mind, we can initiate a UXSS if the user simply browses to my site with IE, and has a recent version of FireFox2 installed (XSS and CSRF apply)..... but WAIT.. it gets better... because we can control the arguments passed to FireFox.exe, we can do other fun things, like add a FireFox profile to the users machine (without user consent).

Proof of Concept can be found at: <removed by BK>

I've informed Mozilla security... they say it’s a feature and "bad behavior" on IE’s part... have fun.


BK



Edited 2 time(s). Last edit at 06/23/2007 02:55PM by BK.

Very interesting stuff! Nice research.

Although this has potential to be dangerous, I am unsure that it wouldn't be obvious something screwy is occurring to the user.

[No sooner does man discover intelligence than he tries to involve it in his own stupidity.]
[Jaques Cousteau]

Nice!

Very Nice, thanks for the info, :D

Even if IE patches this (because it is IE's fault that they don't sanitize data before putting it on the command line), this is a useful piece of information, for attacking those who use a separate browser for browsing sensitive sites.

Nice research!

-------------------------------
[fr3dc3rv.blogspot.com]

Well done!

---
g:0in~/*for another*/~alert(!!1)
(Å='',[Ç=!(µ=!Å+Å)+{}][Ç[ª=µ[++Å]+µ[Å-Å],È=Å-~Å]+Ç[È+È]+ª])()[Ç[Å]+Ç[Å+Å]+µ[È]+ª](Å)
me || PHPIDS || Twitter || <malicious></markup>

Nice findings, thanks.
They all can be quite an annoyance, but #1 has some exploitable twists in the scenario outlined by kuza55.
It cannot work if JavaScript is disabled for "about:blank", but since some extensions require it to be allowed, I worked around this limitation in latest NoScript development version.

--
*hackademix.net*

There's a browser safer than Firefox... Firefox, with NoScript

Uhm, thats cool. Very good research.

Regards,
- [christ1an.blogspot.com]

_______________________
[php-ids.org] Web Application Security 2.0

@BK

Yeah they tend to say that a lot at Mozilla: "feature".
I understand why though, it's the same if I link like:
telnet:// and set up a daemon to listens for incoming telnet sessions, like:

<iframe src="telnet://www.myeviltelnetdaemon.com" frameborder="0" width="1" height="1"></iframe>

But hey, why disclose it, it's fun to use! ^^

Just updated the PHPIDS detection rules to detect this kind of attack with highest impact.

---
g:0in~/*for another*/~alert(!!1)
(Å='',[Ç=!(µ=!Å+Å)+{}][Ç[ª=µ[++Å]+µ[Å-Å],È=Å-~Å]+Ç[È+È]+ª])()[Ç[Å]+Ç[Å+Å]+µ[È]+ª](Å)
me || PHPIDS || Twitter || <malicious></markup>

ma1 Wrote:
-------------------------------------------------------
> Nice findings, thanks.
> They all can be quite an annoyance, but #1 has
> some exploitable twists in the scenario outlined
> by kuza55.
> It cannot work if JavaScript is disabled for
> "about:blank", but since some extensions require
> it to be allowed, I worked around this limitation
> in latest NoScript development version.


I don't think NoScript will be able to stop you because you don't need JS execution in about:blank to execute cross browser XSS, you can just send the user straight to the XSS URL in the browser, as per how the firefoxurl: schema is supposed to actually work, so unless you're going to assume that anything passed on the CLI to Firefox is untrusted, I'm not sure how you're going to fix it.

Though it doesn't seem like you can use the schema from inside Firefox effectively (and at very very least without opening the warning dialogue), it *might* be a possible attack vector to bypass NoScrpt from Inside Firefox.



Edited 1 time(s). Last edit at 06/20/2007 04:14PM by kuza55.

kuza55 Wrote:

> I don't think NoScript will be able to stop you
> [...] unless you're going to assume
> that anything passed on the CLI to Firefox is
> untrusted [...]

NoScript already distrusts (XSS-wise) every URL opened from external applications (e.g. your email client), so checking the command line if needed wouldn't be a big deal.
At any rate, I tend to believe that bypassing NoScript with this stuff is not as easy as you seem to suggest.
Could you please provide a working test-case?

--
*hackademix.net*

There's a browser safer than Firefox... Firefox, with NoScript

BK Wrote:
-------------------------------------------------------
> I've informed Mozilla security... they say it’s a
> feature and "bad behavior" on IE’s part...

I never said it was a feature, I said we were "working on protecting users from this on our end for a future security update."

I do think IE should escape quotes in URLs (RFC 1738 considers them an "unsafe" character in URLs), but the Firefox team has been looking into back-stop protection in our app since we saw Thor Larholm's Safari 0-day post.

@dveditz - If I misinterpreted your email, I'm sorry. I'm glad Mozilla is taking this issue seriously and is taking measures to protect their customers. I agree that some of IE actions are to blame here, but keep in mind that Firefox (not IE) registers the URI in the Windows Registry.

As for other applications registering URIs, you're absolutely right. We (Nate, Raghav, and I) have discovered other very serious vulnerabilities in other applications through URI schemes. We'll be releasing our research soon... If there are any other Mozilla related vulnerabilities, we'll contact you privately.

BK



Full email I received for context:

"Thanks for sending the details. Ultimately we view this as bad behavior on the other app's part (as in the Safari bug Thor Larholm blogged about) but we are pragmatically working on protecting users from this on our end for a future security update.

The hook you used was added for Vista compatibility and you will no doubt start seeing many more apps adding similar features."



Edited 1 time(s). Last edit at 06/20/2007 06:48PM by BK.

ma1 Wrote:
-------------------------------------------------------
> kuza55 Wrote:
>
> > I don't think NoScript will be able to stop you
> > [...] unless you're going to assume
> > that anything passed on the CLI to Firefox is
> > untrusted [...]
>
> NoScript already distrusts (XSS-wise) every URL
> opened from external applications (e.g. your email
> client), so checking the command line if needed
> wouldn't be a big deal.
> At any rate, I tend to believe that bypassing
> NoScript with this stuff is not as easy as you
> seem to suggest.
> Could you please provide a working test-case?


In that case I'm very sorry, I didn't know that NoScript distrusted URLs from other applications, so I'm impressed, :D I did some testing, and it seems that NoScript is doing its job properly, sorry.

Oh, since you're already here, would it by any chance be possible to create a way by which you allow javascript, but don't disable the XSS protection? Or would that be infeasible?

@dveditz

I never understand why you guys allow access from URI's like this in the HTML space, and telnet, gopher, ftp, data, resource, res, file. Why? why not turn it off by default and THEN if you need it activate it in a security tab in Firefox. Simply the principle of least privilege.

kuza55 Wrote:

> Oh, since you're already here, would it by any
> chance be possible to create a way by which you
> allow javascript, but don't disable the XSS
> protection? Or would that be infeasible?

NoScript already does it since version 1.1.4.9, just look at the changelog.

It basically filters every request (GET and POST) from untrusted to trusted sites (the behaviour you know), but it additionally applies the same XSS filters to those GET requests which go from trusted to trusted and match certain "injection patterns".
The aim is handling reflected XSS links which someone managed to put in a trusted site.

Feel free to hammer NoScript's "injection pattern" detection. It is obviously less safe than the default "blind nazi filter" for cross-trust requests, but I would be happy to quantify this "less safe" with live examples :)

--
*hackademix.net*

There's a browser safer than Firefox... Firefox, with NoScript



Edited 2 time(s). Last edit at 06/22/2007 09:54AM by ma1.

Ronald Wrote:
-------------------------------------------------------
> I never understand why you guys allow access from
> URI's like this in the HTML space, and telnet,
> gopher, ftp, data, resource, res, file. Why? why
> not turn it off by default and THEN if you need it
> activate it in a security tab in Firefox. Simply
> the principle of least privilege.

Ronald, you are asking the wrong guy - because Firefox doesn't allow access to these URLs. Try opening a telnet: URL in Firefox, you will get a warning that can only be accepted after several seconds. The problem is that Internet Explorer doesn't do the same, and Firefox has no influence on that.