Open Bug 937663 Opened 8 years ago Updated 5 years ago

The pdf embedded using object tag is blocked by the mixed content blocker

Categories

(Firefox :: Security, defect)

26 Branch
x86
Windows XP
defect
Not set
normal

Tracking

()

Tracking Status
firefox25 --- affected
firefox26 - affected
firefox27 - affected
firefox28 - affected

People

(Reporter: mihai.morar, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(1 file)

Reproducible on the latest Beta (BuildID: 20131111154639): Mozilla/5.0 (Windows NT 5.1; rv:26.0) Gecko/20100101 Firefox/26.0

Steps to reproduce:
1. Start Firefox.
2. Access the following URL: https://moztrap.mozilla.org/media/attachments/2013/01/18/embeddedPDFsTestPage.html

Expected results: Both of the PDFs embedded on the page are displayed properly.

Actual result: The only PDF successfully displayed is the one embedded using <embed> tags, while the PDF embedded using the <object> tag is blocked by the mixed content blocker.

Notes:
1. This issue is only reproducible under Windows XP x32 and Windows 7 x32.
2. This issue is not a recent regression: it's also reproducible on Firefox 25 (buidID: 20131025151332). I will further investigate this bug in terms of regression.
This issue is also:
- reproducible on the latest Aurora (BuildID: 20131112004004): Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101 Firefox/27.0
- reproducible on the latest Nightly (BuildID: 20131112030204): Mozilla/5.0 (Windows NT 5.1; rv:28.0) Gecko/20100101 Firefox/28.0
An update on expected results:
Both PDFs embedded in the page should be blocked by the mixed content blocker, as both of them are actually HTTP content inside a HTTPS page (Mixed Passive Content).
Component: PDF Viewer → Security
Keywords: regression
Keywords: regression
The Mixed Content Blocker UI has been implemented starting with Firefox 18, but it was enabled only starting with Firefox 23.

The same behavior was encountered on the following builds, using Windows XP x86:
- Firefox 22 (BuildID: 20130618035212): with security.mixed_content.block_active_content set to true
- Firefox 23 (BuildID: 20130730113002)
- Firefox 24 (BuildID: 20130910160258)

The behavior changes on the following builds - enabling the Mixed Display Content does not block any of the embedded PDFs, while enabling the Mixed Active Content blocks both of the embedded PDFs, under Windows XP x86:
- Firefox 18 (BuildID: 20130104151925)
- Firefox 19 (BuildID: 20130307023931)
- Firefox 20 (BuildID: 20130307075451)
- Firefox 21 (BuildID: 20130511120803)

Also: a related issue was found, 738967 (pdf.js doesn't work for embedded PDFs), which according to latest comments, has been reported fixed starting with Firefox 22.
Keywords: regression
Tyler, is this something that has bubbled up in support or input?
Sid - is this actually the expected behaviour for MCB with pdf content?
Flags: needinfo?(sstamm)
This is iffy.  PDFs have a history of doing things they're not supposed to, but are probably *supposed* to be passive (and can't modify the web page).  Problem is, they're dangerous (especially if we're using pdf.js, which *is* script).

But I think PDFs are supposed to be passive content so MCB should not block them unless you have enabled blocking of mixed display.  Chris, what do you think?
Flags: needinfo?(sstamm) → needinfo?(mozilla)
The fact that the problem is only reproduceable on Windows strongly indicates a weired bug.
On Linux, both of these calls use the contentPolicyType TYPE_OBJECT, which is Active content and should therefore be blocked.
I guess one of the problems we are facing with MCB is the way we query the requestingLocation [1]. Probably we hit an early return somewhere in that code.

Currenlty, I am working on bug 878890, which eliminiates the ShouldLoad call of the contentPolicy and uses an observer to evaluate mixed content. Even though the problem mentioned here is not directly depended on bug 878890, I think that this rewriting of shouldLoad is going to fix that bug too. The new function that evaluates mixed content only requries a |context| to be provided and does not query the reqeustingLocation using so many if-else cases [1] that no one really can keep track of.

[1] http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsMixedContentBlocker.cpp#346
Flags: needinfo?(mozilla)
Given this is an old regression & is not a major issue for our users we would not track it for an upcoming releases. If this could be exploitable and a major security issue feel free to renominate it with appropriate rating else may be be we can wait on 878890 to get fixed.
The same bug was encontered in Firefox 28.0 Beta 6 on Manjaro 0.8.9 with mixed content allowed.
Build: 	20140224220227
Flags: needinfo?
[testday-20140227]
Flags: needinfo?
[Testday-20140523]
Still reproducible with 30.b7 (Build ID:20140522105902) on Ubuntu 14.04(Desktop-64bit)
[Testday-20140523]
Still reproducible with 30.b7 on Windows 7 32 Bit
[Testday - 20140523]
It doesn't happens with 30.b7 on KaOS (KDE - Linux) 64bit
Testday - 20170307
I have the same problem. It seems, it is still existing. I embedded an PDF file via googledocs. But in firefox (52.0 64Bit for Mac, and Firefox 52.0 32Bit for Windows) the whole Joomla-Article on the site is blocked.
SSL was made within Lets Encrypt. 
So how is secure PDF-embedding possible?
You need to log in before you can comment on or make changes to this bug.