439560 - New video player allows cross-site includes

Status: RESOLVED FIXED

(www.mozilla.org :: General, defect)

Description

[Wil Clouser [:clouserw]]

The video player got modified in bug 439358 to allow videos to be specified via the URL.  However, there appears to be no restriction as to the  source of the videos.  This affects mozilla.com and mozilla-europe.org.

https://stage.mozilla-europe.org/js/video/playerWithControls.swf?flv=http://www.micropipes.com/temp/superflytnt.flv

https://www.authstage.mozilla.com/en-US/firefox/video/playerWithControls.swf?flv=http://www.micropipes.com/temp/superflytnt.flv

Comment 1

[Steven Garrity [:sgarrity]]

I've got a question into the flash developer about white-listing the domains for videos.

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

Why is this blocking? Because someone can make the mozilla.com site show a video from somewhere else? I agree that it's critical and needs to be fixed, but does it need to be before we put the content up?

Comment 3

[Wil Clouser [:clouserw]]

(In reply to comment #2)
> Why is this blocking? Because someone can make the mozilla.com site show a
> video from somewhere else? I agree that it's critical and needs to be fixed,
> but does it need to be before we put the content up?
> 

You asked for nominations of bugs on mozilla.com; it's your call.  Personally if we get it fixed tomorrow I don't think it's a blocker (it'd be on the live site for a few hours).

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

OK, I just wanted to make sure I wasn't missing anything. I don't think it's a blocker either, but we should definitely try to get a fix in tomorrow even after launch.

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

Reed points out that this is basically an XSS hole which could be arbitrarily exploitable, which is more than just hosting random video content. It needs to be fixed, even if we do some sort of preprocessing of our own.

Comment 6

[John Slater]

What's the best way to get this fixed by tomorrow? That is, how do we patch this up well enough to keep everything working until the full-time fix is implemented?

Steven and I have been working with the Royal Order on this (complicated slightly by the fact that their Flash guy who originally worked on this is out of town), so I'm confident we'll get it fixed soon, but obviously we should have a plan in place to hold us until then.

Comment 7

[Reed Loden [:reed]]

Super-super-super temp fix added for www.mozilla.com. mozilla-europe.org still needs fixing.

Sending        .htaccess
Transmitting file data .
Committed revision 15841.

Comment 8

[Steven Garrity [:sgarrity]]

We have a copy of the .swf file that is hard-coded to look for the one local .fla video, which would fix this. However, we needed the more flexible version for the localized versions which play video hosted on videos.mozilla.org.

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

Marking FIXED. Please file a follow up for a less-hacky fix. :)

Comment 10

[Jonah]

Hi guys,

So after reading thru this thread I’m understanding the issue is the fact that the flv variable in the embed code is passing the URL itself? If so, we can have flv=english or flv=europe, etc. and then have a background processing page on Mozilla’s end that defines what english and europe are equal to which would then process which language video URL to use for the Flash file. If that sounds like a good suggestion I guess next steps would be to create a processing page with all languages needed and to send that to me so I can implement and test in my environment. 

Comment 11

[Jonah]

Sorry, also forgot to mention I'm the Flash Developer at Royal Order.