Last Comment Bug 481342 - (CVE-2009-1307) Adobe Flash loaded from view-source: protocol - network security policy bypass and localhost LSO reading/writing
(CVE-2009-1307)
: Adobe Flash loaded from view-source: protocol - network security policy bypas...
Status: VERIFIED FIXED
[sg:high]
: verified1.8.1.22, verified1.9.0.9, verified1.9.1
Product: Core
Classification: Components
Component: Security (show other bugs)
: unspecified
: All All
: -- normal (vote)
: ---
Assigned To: Dave Camp (:dcamp)
:
: David Keeler [:keeler] (use needinfo?)
Mentors:
http://pseudo-flaw.net/v/view-source-...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-03 20:52 PST by Gregory Fleischer
Modified: 2015-07-08 05:10 PDT (History)
14 users (show)
jst: blocking1.9.1+
dveditz: blocking1.9.0.9+
dveditz: wanted1.9.0.x+
dveditz: blocking1.8.1.next+
dveditz: wanted1.8.1.x+
asac: blocking1.8.0.next+
dcamp: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
v1 (2.36 KB, patch)
2009-03-06 14:34 PST, Dave Camp (:dcamp)
bzbarsky: review+
bzbarsky: superreview+
Details | Diff | Splinter Review
v1 with tests (4.65 KB, patch)
2009-03-06 15:23 PST, Dave Camp (:dcamp)
dveditz: approval1.9.0.9+
Details | Diff | Splinter Review
1.8.0 branch patch (1.85 KB, patch)
2009-04-08 07:26 PDT, Martin Stránský
bzbarsky: review+
asac: approval1.8.0.next+
Details | Diff | Splinter Review
same for 1.8 (3.13 KB, patch)
2009-04-28 04:17 PDT, Alexander Sack
samuel.sidler+old: approval1.8.1.next+
Details | Diff | Splinter Review

Description Gregory Fleischer 2009-03-03 20:52:22 PST
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20

The following was sent to Adobe PSIRT (psirt@adobe.com):

*Overview*

When a Flash file is loaded in Mozilla Firefox from within the
'view-source:' protocol handler, the Adobe Flash plugin miscalculates
the origin of the content. To the plugin, it appears the content was
loaded from the local file system.

This introduces two specific security weaknesses:

    * bypass of 'crossdomain.xml' and access to arbitrary third-party
      web content

    * ability to read and write local shared objects within the
      context of localhost

*Background*

In Mozilla Firefox, it isn't normally possible to render content using
the 'view-source:' pseudo protocol handler. However, by providing the
content as a valid JAR file, the 'jar:' handler can be used to load a
file as HTML from within the context of 'view-source:'. 

This sequence would appear as:
    
    jar:view-source:http://example.com/data.jar!/page.html

where 'data.jar' would contain:

    * page.html
    * content.swf

The 'page.html' file would include 'content.swf' within an embed tag and
the Flash content would be loaded with a root path of
'view-source:http://example.com/data.jar!/content.swf'.

*Summary*

The Flash security policy restricts objects from accessing third-party
web content unless the third-party site opts in via a
'crossdomain.xml' file. For content that is loaded from the local file
system, no network access is allowed unless a user specifically allows
it by adding a security exception. But, by default, local Flash
objects can load any other local file system content.

Because Flash believes that any content loaded from 'view-source:'
originated on the local machine, the Flash standard network security
policy is not applied. The standard 'crossdomain.xml' file is not
consulted. Mozilla Firefox allows access to the third-party data
because both sets of content originate on the network.

When a Flash object is loaded from within the 'view-source:' protocol,
the content is created within the context of the 'localhost'
hostname. This allows for the creation of Local Shared Object (LSO)
that appears to originate from the localhost.

Since the local networking restrictions can be circumvented by
resubmitting the content using a 'view-source:' URL, coordinating
third-party sites can read and write locally shared objects as well as
post the information back. In this way, a complete privacy compromise
and user tracking is possible.

*Details*

Additional details and demonstrations are available at 
http://pseudo-flaw.net/v/view-source-flash-issues/


Reproducible: Always
Comment 1 Boris Zbarsky [:bz] (still a bit busy) 2009-03-03 21:07:59 PST
I think this is just a hole in the fix for bug 369814.  We should, imo be checking that not only is the HTTP header set that way but that GetContentType on |channel| (NOT on the nsIHttpChannel) gives the same type.  Since view-source: overides the type, there wouldn't be a problem, right?
Comment 2 Benjamin Smedberg [:bsmedberg] 2009-03-04 05:44:59 PST
What data does the view-source channel actually give back? Is it just the parent channel's data?

The linked website is public. Has this vulnerability been publicly announced?
Comment 3 Boris Zbarsky [:bz] (still a bit busy) 2009-03-04 05:48:17 PST
> Is it just the parent channel's data?

Yes, with a special content-type that causes special processing in nsContentDLF.

I should note that on our end view-source URIs are properly created as nested URIs and so forth, so we give them the right principals and whatnot.
Comment 4 Gregory Fleischer 2009-03-04 14:28:59 PST
(In reply to comment #2)
 
> The linked website is public. Has this vulnerability been publicly announced?

No, this vulnerability hasn't been publicly announced.  The information was sent to Adobe PSIRT and entered here.
Comment 5 Daniel Veditz [:dveditz] 2009-03-06 11:31:30 PST
Blocking 1.9.0.8 probably isn't reasonable without a 1.9.1 fix (1.9.0.9 is more realistic), but blocking for now since I can't make it block 1.9.1
Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2009-03-06 12:24:57 PST
ccing some likely fixers.  I guess I could patch this, but then I'm not sure who to get to review it...
Comment 7 Dave Camp (:dcamp) 2009-03-06 13:18:08 PST
(In reply to comment #1)
> I think this is just a hole in the fix for bug 369814.  We should, imo be
> checking that not only is the HTTP header set that way but that GetContentType
> on |channel| (NOT on the nsIHttpChannel) gives the same type.  Since
> view-source: overides the type, there wouldn't be a problem, right?

If we generally avoid rendering view-source content, and jar: lets someone get around that, should we just always disallow unpacking if our child is a view-source channel?

Just extending the 369814 fix will still leave people vulnerable if they have the network.jar.open-unsafe-types pref set.

Also, if flash is generally treating unknown protocols as local, this might happen again if another channel implements nsIHttpChannel and doesn't happen to override GetContentType().  Maybe we should really only trust nsHttpChannel to provide the safe-jar content type?
Comment 8 Boris Zbarsky [:bz] (still a bit busy) 2009-03-06 13:23:02 PST
> should we just always disallow unpacking if our child is a view-source channel?

We could, yes.

> still leave people vulnerable if they have the network.jar.open-unsafe-types
> pref set.

They're already vulnerable to various attacks, but agreed.

> Also, if flash is generally treating unknown protocols as local,

Then it's busted in all sorts of ways and should be fixed, imo...  Any extension protocol will break that assumption, no?
Comment 9 Dave Camp (:dcamp) 2009-03-06 14:34:14 PST
Created attachment 366006 [details] [diff] [review]
v1
Comment 10 Boris Zbarsky [:bz] (still a bit busy) 2009-03-06 15:00:38 PST
Comment on attachment 366006 [details] [diff] [review]
v1

Looks good.  Tests, please?
Comment 11 Dave Camp (:dcamp) 2009-03-06 15:23:50 PST
Created attachment 366027 [details] [diff] [review]
v1 with tests

Not sure why that patch didn't include the test changes...
Comment 12 Dave Camp (:dcamp) 2009-03-06 15:55:34 PST
This patch conflicts a bit with the patch in bug 474536.  If that patch is going to land on 1.9.0/1.9.1 we should land it first, otherwise I can put together a new patch for those branches.
Comment 13 Dave Camp (:dcamp) 2009-03-10 15:14:55 PDT
http://hg.mozilla.org/mozilla-central/rev/38ce0b3beaec
Comment 15 Daniel Veditz [:dveditz] 2009-03-16 14:56:43 PDT
Comment on attachment 366027 [details] [diff] [review]
v1 with tests

Approved for 1.9.0.8, a=dveditz for release-drivers
Comment 16 Dave Camp (:dcamp) 2009-03-17 14:55:30 PDT
Checking in docshell/test/Makefile.in;
/cvsroot/mozilla/docshell/test/Makefile.in,v  <--  Makefile.in
new revision: 1.14; previous revision: 1.13
done
Checking in docshell/test/test_bug369814.html;
/cvsroot/mozilla/docshell/test/test_bug369814.html,v  <--  test_bug369814.html
new revision: 1.2; previous revision: 1.1
done
Checking in modules/libjar/nsJARChannel.cpp;
/cvsroot/mozilla/modules/libjar/nsJARChannel.cpp,v  <--  nsJARChannel.cpp
new revision: 1.131; previous revision: 1.130
done
Checking in bug369814.jar;
/cvsroot/mozilla/docshell/test/bug369814.jar,v  <--  bug369814.jar
initial revision: 1.1
done
Comment 17 Al Billings [:abillings] 2009-03-19 16:48:20 PDT
Verified for 1.9.0.8 using the checked in tests, which pass.
Comment 18 Daniel Veditz [:dveditz] 2009-03-25 22:37:46 PDT
1.9.0.8 was renamed to 1.9.0.9, to make room for an inserted "Firefox 3.0.8". The release containing this fix has been renamed to "Firefox 3.0.9" but will release on pretty much the same schedule (mid-April).
Comment 19 Martin Stránský 2009-04-08 07:26:47 PDT
Created attachment 371669 [details] [diff] [review]
1.8.0 branch patch
Comment 20 Martin Stránský 2009-04-08 07:29:08 PDT
Comment on attachment 371669 [details] [diff] [review]
1.8.0 branch patch

Can you check this one?
Comment 21 Boris Zbarsky [:bz] (still a bit busy) 2009-04-08 09:17:38 PDT
Comment on attachment 371669 [details] [diff] [review]
1.8.0 branch patch

Looks fine.
Comment 22 Alexander Sack 2009-04-28 04:10:39 PDT
Comment on attachment 371669 [details] [diff] [review]
1.8.0 branch patch

a=asac for 1.8.0
Comment 23 Alexander Sack 2009-04-28 04:17:30 PDT
Created attachment 374884 [details] [diff] [review]
same for 1.8
Comment 24 Daniel Veditz [:dveditz] 2009-05-20 15:53:16 PDT
Comment on attachment 374884 [details] [diff] [review]
same for 1.8

Approved for 1.8.1.22, a=dveditz for release-drivers
Comment 25 Daniel Veditz [:dveditz] 2009-05-29 23:11:45 PDT
Checked into the 1.8(.1) branch
Checking in Makefile.in;
/cvsroot/mozilla/modules/libjar/Makefile.in,v  <--  Makefile.in
new revision: 1.50.2.1; previous revision: 1.50
done
Checking in nsJARChannel.cpp;
/cvsroot/mozilla/modules/libjar/nsJARChannel.cpp,v  <--  nsJARChannel.cpp
new revision: 1.116.2.5; previous revision: 1.116.2.4
done
Comment 26 Al Billings [:abillings] 2009-06-02 15:16:21 PDT
Verified for 1.8.1 using http://pseudo-flaw.net/v/view-source-flash-issues/thirdpartycontent.html and Seamonkey 1.8 nightly (Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.22pre) Gecko/20090602 SeaMonkey/1.1.17pre).

Verified for 1.9.1 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090601 Shiretoko/3.5pre. 

Verified for trunk with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090529 Minefield/3.6a1pre.

Note You need to log in before you can comment on or make changes to this bug.