It's possible yet again to manipulate the pdfjs implementation when rendered as a plugin. The issue here is that most things at content level totally ignore the pseudo view-source: protocol, so properly loading a pdf document then switching the src/data attribute of an object/embed to a url that begins with view-source: doesn't trigger the underlying logic which should be triggered for the plugin url changing. This also prevents the type changing which means that when combined with bug 1022919 to load the usually ignored view-source: protocol its possible for one to disclose information about local files or even possibly obtain chrome level code execution. Here I show off accessing navigator.mozApps.mgmt, and I feel I'm pretty close to code execution there but I have two other issues that need to get filed and my time has to be spread as much as possible. There's also issues that concern me regarding the remapping of the prototypes of embed and object elements, as I have already seen this lead to chrome level code trying to access a dead object when it should have been loading a perfectly valid embed element. I'll go into more detail about that and a practically impossible to reproduce SOW bypass that can also occur tomorrow I think. I already have two other issues to get testcases ready for either tonight or as early as I can tomorrow. Sorry guys I'm a little lack luster on this one I know but I'm running into many issues leading in many different directions lately and I think getting as much out there about them as I can piece together might be for the best. BTW the newest nightly has it locked down pretty well, but some XBL work is about to make another appearance, meh =/

So this is an actual playPreview bug, caused sort-of by bug 973837, but the bigger issue is playPreview is checking on all fallback types and hijacking them, meaning you can get into a play-preview state on a URI that failed security checks.

@gfritzsche, are you at all familiar with this code? The change is pretty simple, but if you're uncomfortable reviewing feel free to bounce the review to benjamin when he gets back

Comment on attachment 8463646 [details] [diff] [review] Don't check plugin playPreview status for null object types unless the fallback reason is unsupported Neglected to actually flag, let's try again: @gfritzsche, are you at all familiar with this code? The change is pretty simple, but if you're uncomfortable reviewing feel free to bounce the review to benjamin when he gets back

Comment on attachment 8463646 [details] [diff] [review] Don't check plugin playPreview status for null object types unless the fallback reason is unsupported Actually, this still is very shaky since the 'ignoreCTP' style playPreview plugins can step in for otherwise completely unknown types and open their own channel, but pdf.js is opening this into a privileged iframe assuming <object> loaded the channel, so neither does security checks, and things just kind-of-work except for view-source. I need to look at this more closely.

nom for bounty

Sounds bad. Let me know if you think that's too high or too low or whatever, John.

Any word on the status of the security bounty here? Just thought I would ask as I'm about to start some traveling, I did send Chris my updated payment info in case I'm not easily reachable. It's time to go see if the coast is still secure :-)

John, any progress here? There's been no update here in two months.

Strangely I don't feel the sense of motivation to tear through the mozilla source, but meh that's expected. I think three months would be seen as a little excessive to anyone. I do have something very nice in the works, but my love for mozilla makes it hard to just disconnect. I guess as they say on to the next one.

Hey cody, Sorry for the delay on this (we should have updated the status in the bug). The issue is that the real/robust fix for this bug is bug 558184, and John has been sidetracked with e10s and <picture> element stuff. He's going to try to get that bug landed in the next two weeks.

It's fine, I understand and by on to the next one I just meant I officially filed my first bug for chrome last night. I'm trying to branch out(maybe in too many directions), and have a ton of work but still in a tight situation. I also believe it may be possible to push bug 1045034 up to a critical in the current release based on some of my other work that was promptly fixed in nightly. I'll dig into it later today probably.

It's now been almost over 4 months on this, and the bug that's supposed to be the fix has been on file since 2010. My opinion in regards to Mozilla is beginning to change recently. I know that if I had released these publicly there would have been fixes for this and bug 1045034 probably within 48 hours if not a week. I use firefox as my primary browser and I don't want to change that, but how am I supposed to feel secure using it when it can take 4 months to address issues(not just the payable ones) that I have on file? I know Google says for chrome wait a week and if there's no progress on a serious security issue publish it yourself as they've obviously dropped the ball. Just another note there's still a need info flag on this bug that's been there for months, so long even the email for it has changed I think.

I think somebody else is working on the jsplugins bug.

bz is working on it now. I'll just leave this unassigned for now.

I think Boris is working on this.

This is a sec-high that has been sitting for quite a while with no updates. Do you have an ETA on when you might be able to work on it, Boris?

Boris has started landing some stuff in the dependencies a few weeks ago. Bug 1136379 landed on 2/25.

I _am_ working on it, yes. If we just wanted this bug fixed, I could probably hack together something faster than the thing we actually want to do, I guess, at the expense of taking longer to do the thing we really want to do.

Someone just filed bug 1191284 which seems to essentially show this is being exploited in the wild today to access local files.

This bug is not longer applicable for Firefox 42 and later due to bug 1179262, which removes Play Preview usage from PDF Viewer code somewhat fixing this bug.

Does pdfjs.disabled=true prevent this bug for happening?

(In reply to Sylvestre Ledru [:sylvestre] from comment #22) > Does pdfjs.disabled=true prevent this bug for happening? Yes, so does the removal of playPreview in bug 1179262.