798026 - Plugin content served as text/plain not detected as binary

Status: RESOLVED DUPLICATE of bug 648706

(Core :: DOM: Core & HTML, defect, P4)

Description

[Cristian Rodriguez]

Attachment: bug.png

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0.1
Build ID: 20120905151427

Steps to reproduce:

install windows 8 pro and then install firefox without installing the Flash plugin visit the url http://www.bbva.cl


Actual results:

Mozilla has failed to control the lack of flash plugin and exposed to hard code the file.


Expected results:

Mozilla should have detected the lack of plugin and should request the installation of the same

Comment 1

[Benjamin Smedberg]

This is not a security bug. The website in question is doing

<object type='application/x-shockwave-flash' data='/fbin/botonera_tcm319-190122.swf' width='190' height='400'>

But when the server responds for , it says the MIME type is text/plain.

I don't know if this is specced in HTML5 or not; johns/bz do you guys know?

Comment 2

[Cristian Rodriguez]

then?

Comment 3

[Boris Zbarsky [:bzbarsky]]

This is specced, yes.  

That said, for the text/plain case I thought we should end up under nsBinaryDetector::DetermineContentType. Do we not?

And note that I'm not sure what exactly the spec says here.  I know it does define the behavior.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Christian, the server is misconfigured and sending the data as text/plain.  I'd suggest that fixing that is a good idea no matter what we do or don't do about this.

Comment 5

[Cristian Rodriguez]

I agree with you that there is a security bug, sorry my bad interpretation.

Comment 6

[John Schoenick [:johns]]

Unless I'm misreading it, we're doing the right thing in ignoring the type attribute if the server returns a type we support, but we are failing to detect that it is binary data

> If the type specified in the resource's Content-Type metadata is "text/plain", and the result of applying the rules for distinguishing if a resource is text or binary to the resource is that the resource is not text/plain, then set binary to true.

Comment 7

[Boris Zbarsky [:bzbarsky]]

That sounds right.  So why is nsBinaryDetector not detecting it as binary?  We certainly pass LOAD_CALL_CONTENT_SNIFFERS in nsObjectLoadingContent::OpenChannel...

Comment 9

[John Schoenick [:johns]]

So bug 803159 discovered a test case wherein we hit this behavior in more sites due to bug 745030, so if the fix to this is simple, we should consider it for branches.

Comment 10

[Lukas Blakk [:lsblakk] use ?needinfo]

We'll track this, no need to track for ESR17 since that will be cut from mozilla-release once 17 is merged to it and so if this makes 17 we'll get it for free on ESR17.

Comment 11

[Boris Zbarsky [:bzbarsky]]

So the reason we're not detecting http://www.bbva.cl/fbin/botonera_tcm319-190122.swf as binary is because it's coming through with "Content-Encoding: gzip" and we don't sniff that for binary.  See also bug 648706.

Same thing for http://www.bbva.cl/fbin/banner_calidad_tcm319-188382.swf

But those are both using <object> elements.  And in particular, on the site in comment 0 I see the same behavior without bug 745030, as expected (since this bug is filed against firefox 15).

But bug 803159 is a totally different situation: that's using an <embed> object.  Did we break the bit about using the filename extension to override the server-provided type for <embed>?  See the spec at http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#concept-embed-type which explicitly says we should be doing that.

So I think we should reopen bug 803159, which is about <embed>, and probably mark this bug as duplicate of bug 648706.

Comment 12

[Boris Zbarsky [:bzbarsky]]

And in fact, doing that.

Comment 13

[Boris Zbarsky [:bzbarsky]]

And also, note that for this bug you have to disable Flash to reproduce.  But bug 803159 reproduces with Flash enabled.

Comment 14

[Lukas Blakk [:lsblakk] use ?needinfo]

Dupe of a longstanding issue, removing tracking.