292894 - Firelinking with jar: URIs

Status: RESOLVED DUPLICATE of bug 291150

(SeaMonkey :: Security, defect)

Description

[Pavel Kankovsky]

User-Agent:       Mozilla/5.0 (Mozilla rulez!)
Build Identifier: 

It appears the fix for "firelinking" vulnerability discovered by Micheal Krax
(see bug 290036) can be circumvented when the javascript: URI is wrapped in jar:
URI.

Reproducible: Always

Steps to Reproduce:
Take the exploit, prepend "jar:" to the link, append "!/xxxx" to it and try it out.



I file this as a bug for App Suite but I suspect Firefox is affected as well.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This should be fixed by the patch on bug 290949.

Comment 2

[Pavel Kankovsky]

Attachment: quick and dirty fix

This patch for 1.7.7 appears to thwart exploits using jar:.

Nevertheless, I dislike this blacklisting approach, because it is too fragile.
A proper fix should, imho, prevent evaluation of "side-effect" URIs
(javascript:) at places where it makes no sense like within jar: URI or in
img's src.

BTW: Is the security manager jar:-aware? Isn't it possible to circumvent image
policy with jar: URIs?

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 182610 [details] [diff] [review]
quick and dirty fix

The bug I mentioned in the previous comment has a better solution.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #2)
> A proper fix should, imho, prevent evaluation of "side-effect" URIs
> (javascript:) at places where it makes no sense like within jar: URI or in
> img's src.

Well, not necessarily prevent evaluation, since they're not always "side-effect"
URIs, but at least give them much less access.

> BTW: Is the security manager jar:-aware? Isn't it possible to circumvent image
> policy with jar: URIs?

That's separate from the security manager, but cc:ing bz.

Comment 5

[Daniel Veditz [:dveditz]]

This was also reported by Guninski

*** This bug has been marked as a duplicate of 291150 ***

Comment 6

[Daniel Veditz [:dveditz]]

(In reply to comment #2)
> BTW: Is the security manager jar:-aware? Isn't it possible to circumvent image
> policy with jar: URIs?

The security manager is jar-aware which is why the fix in 290949 fixes this one
too (it calls the security manager instead of explicitly blacklisting only
javascript:).

It relies on nsJARURI.cpp to give it the real file -- it's worth double-checking
that's recursive and wouldn't be fooled by a jar:jar: double wrapper.

Comment 7

[Daniel Veditz [:dveditz]]

double wrappers are caught by caps:
data:text/html,<link%20rel="ICON"%20href="jar:jar:javascript:delayedOpenWindow('javascript:alert(Components.stack)')//!/!/">

(the data: link above doesn't always work in 1.0.3, maybe once each new tab. But
it is fixed by bug 290949)

Comment 8

[Boris Zbarsky [:bzbarsky]]

The security manager is jar-aware, yes.  It'll drill in to the first non-jar:
URI it can find when doing a security check.  See
http://lxr.mozilla.org/seamonkey/source/caps/src/nsScriptSecurityManager.cpp#254
(while loop there).

Comment 9

[Boris Zbarsky [:bzbarsky]]

I'm not sure what the "image policy" question is asking... Is it referring to
same-origin policies for images, or to general security blocking of images, or what?

Comment 10

[Pavel Kankovsky]

To question was referring to any mechanism looking at URIs and deciding whether
the given URI can be loaded as an image. As far as I can tell, there are two
basic mechanisms: 1. nsScriptSecurityManager in caps, and 2. nsPermissionManager
in extensions/cookie. The former handles jar: URIs (although the code appears to
be quite messy IMHO), the latter is (AFAIK) oblivious to jar: URIs (as well as
to other "magical" URIs like view-source:, wyciwyg:, moz-icon: or God knows what
else...hmmm...).

Comment 11

[Boris Zbarsky [:bzbarsky]]

> 2. nsPermissionManager in extensions/cookie.

This implements things like "don't load images from this site", as well as
disabling of images by default and "load images from originating site only". 
You're right that this last probably doesn't work quite right for jar: -- please
file a bug on that in the appropriate component?