1364219 - By including a plugin in a webpage, and an anchor to trigger XBL bindings, it may be possible to manipulate anonymous content.

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect)

Description

[Jerri Rice (rehash pending)]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170504105526

Steps to reproduce:

I included an embed in a page, with a src attribute of "data:application/x-shockwave-flash,1".  I then included a XMLStyleSheet that points to "chrome://pluginproblem/content/pluginReplaceBinding.css".

After this I added an anchor element with an href attribute of "https://get.adobe.com/flashplayer/" which in tern triggers corresponding bindings which should only be triggered if flash player isn't active on the current page.


Actual results:

This causes the anchor element to be able to be clicked to trigger notifications about the flash plugin now being active for the current domain.

This clearly shows that the binding mechanisms have been confused.  I will continue work on this later.


Expected results:

I'm not entirely sure what should happen here as this is the very definition of undefined input/behavior.

Comment 1

[Jerri Rice (rehash pending)]

I may not get time to get a testcase ready for this today, but I will have one up sometime tomorrow time allowing.  It's quite complex and I'm still trying to figure out exactly how this may lead to further manipulation of the XBL machinery, but it's definitely something that needs some eyes on it.

Comment 2

[Jerri Rice (rehash pending)]

Attachment: pluginBindingManipulation-testcase-new.html

Comment 3

[Jerri Rice (rehash pending)]

There is the very basics of a testcase, showing that what I'm talking about in fact does work.  I also know that plugins have to take many events that aren't trusted, so this could lead to all kinds of nastiness =)

I know the details above seemed kind of hard to follow.  Apparently this works even in the current release too.  Not sure I marked this but I'm doing this work in the nightly builds.

More to come.

Comment 4

[Jerri Rice (rehash pending)]

Attachment: pluginBindingManipulation-testcase-alt.html

Comment 5

[Jerri Rice (rehash pending)]

With this alt version after clicking to activate the plugin, open your global browser console to see errors from chrome:// code.  Nice :)

Had time to think to throw this together, so one could begin to understand what the aim for this bug is going to be.  I see the possibility for manipulation through a number of means, and might shift most of my focus for here for the time being.

Until then.

Comment 6

[Jerri Rice (rehash pending)]

I have ideas about switching the embed in line as clicking and such to go with this, I have to go do my daily rounds here shortly, but I'll be on this as soon as I get back.  ETA is around lunch time EST.

Comment 7

[Benjamin Smedberg]

Felipe the specific thing here with the Flash player link makes me think this is related to bug 1282484 -- could you have a look?

Jerri, it's not clear to me what the exploit is, so perhaps you could help me understand which of the behaviors here you think are exploitable, and which are just "weird".

Comment 8

[Jerri Rice (rehash pending)]

Nothing is exploitable yet, just getting pieces filed so maybe they can be fixed before they're exploitable.

I noticed this was possible days ago but it took me days to get back to it.  In the alt version you can see that it does error out from privileged code which is always places I target.  It's just to get people aware of the issue before I lose focus on it again for now.

Comment 9

[Jerri Rice (rehash pending)]

Here's just an idea, let's say that flash player was outdated and known to be vulnerable, and someone was wanting to launch the vulnerable version before an update to compromise an end user's system.  With the very way that I am choosing to lay in the styling sheet and trigger the binding for activating flash, one could hide the known vulnerable embed(as it's not even visible here) and then by clicking on the binding that I am attaching to an anchor element, one could active vulnerable flash and exploit it.

That I can almost assure you is entirely possible right now.  Kind of hard to force downgrade my flash version(and yours) to prove a point.

That's just one way I could see this being an exploit, not to mention the ways I have planned try to manipulate the XBL machinery behind the scenes.

Benjamin, just curious, and this may seem weird are you aware of the curious circumstances of this name and why it's being used here on bugzilla?

Leaving the NI, as I'm sure I will come up with more way to make this perfectly valid.

Comment 10

[Benjamin Smedberg]

I don't consider just triggering the notification a security flaw, because it's rather trivial for a site to do that by e.g. making the plugin fully transparent and then doing mousedown tricks. That's why all plugin activation is two-step through the notification.

That said, I don't know why this case is triggering the notification, so I'd like to follow up on that.

I'm interested if I could avoid having pages directly reference those XBL or CSS files, but I don't think that the JS errors you're seeing are actually from code running with chrome privileges: AIUI this code is all running in page privileges or maybe a null-privilege scope. Still looking through that, though.

Comment 11

[Jerri Rice (rehash pending)]

I'm choosing to include those .css files to just to get the click to activate binding attached to an anchor element.  Those errors are from chrome code.

Hey, it's codyc, it's me :)  I'm quite familiar with some of this, and the including of the css pages to trigger bindings not intended to be triggered is one of my own bugs from quite some time back.

I know pages could do that, but this triggering the binding provides this and the possibility of other nastiness that I haven't got to.  Nice to talk to you, it's been a while.

Comment 12

[:Felipe Gomes (needinfo for replies!)]

(In reply to Benjamin Smedberg [:bsmedberg] from comment #7)
> Felipe the specific thing here with the Flash player link makes me think
> this is related to bug 1282484 -- could you have a look?

I don't think this is related to bug 1282484 because all of that code is disabled by default by prefs. But I'll leave the needinfo here to look into it later today. The only thing that is active from that code is the caching of the return value from ShouldPlay().

Jerri, could you test this with Firefox 51 to check if you see the same weirdness?

Comment 13

[Jerri Rice (rehash pending)]

Give me a few minutes, and I'll have the results here for you.

Comment 14

[Jerri Rice (rehash pending)]

This seems to have been introduced by bug 1282484, I assume that when the pref is toggled, the stylesheet that I am including gets included automatically.  In ff 51, no binding to an anchor element and no way to activate the embed.  No nice chrome errors on the alt version of the testcase either.

So essentially, I was doing half the work of the pref that has to be toggled by choosing to include the stylesheet in the document myself.

That seems to remind me vaguely of something I did the past ;-)

Comment 15

[Jerri Rice (rehash pending)]

Just thought I would touch base here before trying many techniques that come to mind, at the top of nsBlocklistService.js it's directly accessing Components.classes and mapping that to Cc.  

The errors are definitely chrome based, now to try the many ideas that begin to come to mind here, besides the obvious exploitation technique that would in fact use browser internals and not just trickery in a webpage.

Comment 16

[Cody Crews]

Fresh eyes on this today, then on to memory corruption stuff in the newest nightly.

Comment 17

[Cody Crews]

I haven't had much time to get to things, sorry to leave you guys hanging.  I *do* have work that makes this seem worrisome, but my time lately isn't like it used to be.

I'll try to get back to this after the holiday.

Sorry for leaving this hanging so long.

Comment 18

[Cody Crews]

The first thing that made this worry me is now filed in bug 1378135.  Sorry about the grammar there, trying to do this in a hurry on the holiday.

I'll follow up with other parts of this(the XBL machinery side which needs work) and maybe file separate bugs then clear the NI here if everything can be handled separately.

Thanks guys, and again sorry about leaving this hanging.