Re: Cross-Site Scripting vulnerability in Mozilla, Firefox and Chrome

["MustLive" <mustlive@xxxxxxxxxxxxxxxxxx>]

Hello Michal!

First I note, that when I'll find time, I'll answer at your previous comment
about redirection to javascript: URIs in different browsers.

Second I note, that, please, write about something new, not about that I
already mentioned in my advisory ;-).

> "Refresh" or "Location" redirection in Firefox will not bestow a
...
> updates - do inherit that context.

I know it. And I mentioned about this in my paragraph "Via data: it's
possible to bypass in Firefox ...". In these paragraph I wrote "But in
Firefox 3.0.11 and Google Chrome you can't get to cookies this way", which
is the same that your wrote, but in more laconic way. And in the same
paragraph I wrote "but it's possible in old Mozilla (and in those versions
of Firefox where there is relation between data: page and original page)".
So there are such browsers which data: URIs from redirectors inherit context
of the site. In any case JavaScript execution is dangerous even without
relation with original site.

Your position is similar to Mozilla's position. And because Mozilla declined
to fix this hole due to "lack of inheritance" between data: URI and the site
with redirector, and Chrome also has no such inheritance, I didn't send my
advisory directly to Google Security Team. And from your declining of this
vulnerability, I see that it's Google's official position about this issue.

I understand your and Mozilla's position, but I don't agree with you. And I
wrote enough (as I was thinking) arguments in my advisory, why it's
dangerous and why it need to be fixed.

Third, I note that no need to hurry up to write about location redirection
in Firefox. Because the day before your comment I posted at my site advisory
about this vulnerability in Firefox (and not only in it, but also in Opera).
And I'll write separate advisory (when will find time) to Bugtraq about
those holes.

> This means that there is nothing to be gained by redirecting to data:

Michal, there are always something that bad guys can gain. And they can gain
benefits even from data: URL without inheritance with original site. Only
just JavaScript execution (of evil code) is dangerous. Like I said to
Mozilla, cookie stealing (and such things as access to DOM) is only one
vector, there are other vectors of attacks. As I mentioned in advisory, it
can be used particularly for malware spreading.

> he could as well just redirect to his own site and run any potentially
> malicious JavaScript there.

First he need to have his web site (with malicious JS code) and then he need
to redirect users to it. With this hole in different browsers new attack
vectors appears - no need to redirect to any site, just execute JS code from
redirector. Bad guys even no need to have their bad sites, just use all
vulnerable redirectors (so they can't be closed, so they have no such risk
and for this reason it'll be harder to stop such malware spreading, because
there will be no site to close, and no site to block with antifishing
lists). And there are a lot of vulnerable redirectors in Internet.

I planned to write an article about JavaScript Execution attacks in
different browsers via different redirectors to draw attention of Internet
community to this problem. Didn't write it in last two weeks, but I'd do it
in near time.

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: "Michal Zalewski" <lcamtuf@xxxxxxxxxxx>
To: "MustLive" <mustlive@xxxxxxxxxxxxxxxxxx>
Cc: <bugtraq@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, July 15, 2009 11:00 PM
Subject: Re: Cross-Site Scripting vulnerability in Mozilla, Firefox and
Chrome


> > To bypass protection from JavaScript code execution via refresh header
> > it's
> > needed to use data: URI, which will be containing requisite JS code.
> > [...] After I informed Mozilla, they declined to fix this vulnerability.
>
> "Refresh" or "Location" redirection in Firefox will not bestow a
> security context derived from the referring site upon the executed
> code. This is different from the behavior on javascript: URLs.
> Granted, it and also somewhat counterintuitive, as other types of
> data: navigation - e.g., link navigation, IFRAMEd content, location.*
> updates - do inherit that context.
>
> This means that there is nothing to be gained by redirecting to data:
> through www.example.com; he could as well just redirect to his own
> site and run any potentially malicious JavaScript there.
>
> /mz


!DSPAM:4a6ccdc2221422067717600!