1045770 - Flash object can stealth observe keypresses

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

From: [e-mail]
To: [e-mail]
-----//-----
Добрый день !

 Я нашел дыру в безопасности Firefox версии 31 и младших. К
 сожалению я не специализируюсь на безопасности, поэтому воссоздать
 эксплоит не имею возможности, однако описание я привел на странице
 http://firefox-me.ru/archives/58

 Если вас заинтересовала данная информация, я могу указать вам
 демонстрацию.

 Спасибо

-----//-----
TRANSLATION
-----\\-----
  I found a security hole in Firefox version 31 and younger. To
  Unfortunately I do not specialize in security, so to recreate
  have no opportunity to exploit, but the description I gave on page
  http://firefox-me.ru/archives/58

  If you are interested in this service, I can show you
  demonstration.

  thank you

Comment 1

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

Thank you for reporting this, we would like to get more details if
possible. Is this simply the flash object stealing the focus (so the
keystrokes do not go into the field they were intended for?) or is the
flash object truly able to observe the keystrokes without the user
noticing anything is amiss?

On 7/28/2014 6:13 AM, Игорь Тетерин wrote:
> Добрый день !
>
> Я нашел дыру в безопасности Firefox версии 31 и младших. К
> сожалению я не специализируюсь на безопасности, поэтому воссоздать
> эксплоит не имею возможности, однако описание я привел на странице
> http://firefox-me.ru/archives/58
>
> Если вас заинтересовала данная информация, я могу указать вам
> демонстрацию.
>
> Спасибо


--
Daniel Veditz
Mozilla Security Team

Comment 2

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

Attachment: zk_keyboard_v1.swf

open page:
http://onlinepianino.ru/index.php?page=%D0%9E%D0%BD%D0%BB%D0%B0%D0%B9%D0%BD+%D0%BF%D0%B8%D0%B0%D0%BD%D0%B8%D0%BD%D0%BE

this is normal my site, at this page will loading swf:
http://www.zebrakeys.com/swf/zk_keyboard_v1.swf

That swf is realy cool piano..
swich to another tab or press keys at adress bar and you will hear play
sounds.
Thats all.

Comment 3

[Daniel Veditz [:dveditz]]

confirming -- the flash can't observe events in a separate application (IRC, Vidyo, editor, etc) but can see them even when the focus has left the tab/page the flash object is on while still elsewhere in Firefox.

This can be used to steal passwords or other sensitive data entered into other pages or URLs entered into the addressbar. The keystrokes as still sent to the other tab so it would be easy to construct a silent attack. (If the flash object simply kept the focus and captured all the keystrokes that would be far less bad -- the user would notice and fix the problem one way or another.)

This does not appear to happen in IE or Chrome with the exception of the <enter> key which seems to get sent to the app from a second tab or from the address bar.

Comment 4

[Daniel Veditz [:dveditz]]

confirmed also for ESR-24 (so far only tried Windows however)

Comment 5

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

This does _not_ repro on mac.

Comment 6

[John Schoenick [:johns]]

I cannot repro on linux either. Can someone try with | plugins.force.wmode = transparent | vs | plugins.force.wmode = direct | and see if the behavior changes? The default should be windowed mode, so I'm not clear on how both windows are receiving the input.

Comment 7

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

well I just noticed an oddity, it does not play when I type in the other tab but if I ctrl-w and the piano tab is the last tab I hear a note. If I ctrl-t (new tab) I also get a note.

Comment 8

[Daniel Veditz [:dveditz]]

The default might be "transparent" due to bug 923746? Or maybe not, a non-e10s window might not be a GeckoProcessType_Content.
https://mxr.mozilla.org/mozilla-central/source/dom/plugins/base/nsPluginInstanceOwner.cpp#951

When I set plugins.force.wmode explicitly to "transparent" or "opaque" I can reproduce the problem. If I change it to "direct" or "windowed" the problem goes away. Then keystrokes don't active the flash until I click on it to give it focus, but that's obviously a less-bad problem to have.

If I change the wmode value to "foobar" the problem goes away, "" brings the problem back (as I'd expect, it gives us the default).

Comment 9

[Daniel Veditz [:dveditz]]

Why doesn't a garbage value like "foobar" also give me the default behavior?

Comment 10

[John Schoenick [:johns]]

This is just the | <param name="wmode" value="foo"> | value we're passing to flash -- plugins.force.wmode lets us override it and lie to flash. Bug 923746 is doing that to force flash to use windowless-NPAPI while we fix windowed plugins there, but flash using windowless *by default* is news to me. Maybe the applet is somehow requesting it at runtime? That would also explain why "foobar" defaults back to windowed, while no value uses some windowless setting.

Comment 11

[Jim Mathies [:jimm]]

(In reply to Daniel Veditz [:dveditz] from comment #8)
> The default might be "transparent" due to bug 923746? Or maybe not, a
> non-e10s window might not be a GeckoProcessType_Content.
> https://mxr.mozilla.org/mozilla-central/source/dom/plugins/base/
> nsPluginInstanceOwner.cpp#951

That's for e10s. The default for the attached swf is windowed when you open it directly from the bugzilla link.

In the user's web site (yay, I'm listening to the piano on his site play in the background as I type this) the object is embedded and marked as 'transparent' (windowless). That's where the bug is.

Comment 12

[Jim Mathies [:jimm]]

Attachment: piano test case

Comment 13

[Jim Mathies [:jimm]]

STR:

1) open the test case in a background tab (right-click -> open link in new tab)
2) while still on this bugzilla page, set the focus to any text input and try typing something.

result: piano plays
desired: piano shouldn't play

Comment 14

[Jim Mathies [:jimm]]

One odd thing about this flash app - it isn't getting keyboard events the way you would expect - I set a break point in PluginInstanceParent::NPP_HandleEvent and didn't get any hits when the piano was playing in the backgbround. Similar windowless apps get their keyboard input through NPP_HandleEvent. So it doesn't look like our event targeting is to blame, afaict.

https://developer.mozilla.org/en-US/docs/NPEvent

Comment 15

[John Schoenick [:johns]]

Yes, I can kind of reproduce this on linux in a terrifying way: break in the parent process, so it is *entirely stopped*, while the plugin is focused.

Keys from *any open window* are now captured. So, let's break in plugin-container:

> #0  0x00007fffe7ace9b2 in ?? () from /usr/lib/libxcb.so.1
> #1  0x00007fffe7ad02bf in ?? () from /usr/lib/libxcb.so.1
> #2  0x00007fffe7ad03d1 in xcb_wait_for_reply () from /usr/lib/libxcb.so.1
> #3  0x00007fffea6037c7 in _XReply () from /usr/lib/libX11.so.6
> #4  0x00007fffea5f9701 in XQueryKeymap () from /usr/lib/libX11.so.6
> #5  0x00007fffe19b7023 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
> #6  0x00007fffe19b7211 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
> #7  0x00007fffe19b5b1d in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
> #8  0x00007fffe164817d in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
> #9  0x00007fffe17eaa90 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
> #10 0x00007fffe17493ef in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
> #11 0x00007fffe1747f15 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
> #12 0x00007fffe17febed in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
> #13 0x00007fffe17ff02a in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
> #14 0x00007fffe19bb106 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
> #15 0x00007fffe1964ab5 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
> #16 0x00007fffec880483 in ?? () from /usr/lib/libglib-2.0.so.0
> #17 0x00007fffec87fa65 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0

So flash is, in windowless mode, asking windows/X11/whatever for keys, bypassing the browser. Brilliant.

Comment 16

[Jim Mathies [:jimm]]

I can confirm a couple things - one, that flash is picking up input independent of the napi interface on windows, and two - that we do send an appropriate lost focus event (WM_KILLFOCUS on windows) when switching away from the app.

Here's my flash info - 

    File: NPSWF32_14_0_0_145.dll
    Path: C:\Windows\SysWOW64\Macromed\Flash\NPSWF32_14_0_0_145.dll
    Version: 14.0.0.145
    State: Enabled
    Shockwave Flash 14.0 r0

I'm curious if this is tied to a specific flash release. Maybe its a recent flash bug.

Comment 17

[John Schoenick [:johns]]

I stepped through this pretty carefully and see the same thing - we do hit [1] where we give an event of type WM_KILLFOCUS with 0/0 as the params to the plugin's event handler, followed by the plugin continuing to process key events without being refocus'd.

We do drop several WM_NULL events on the floor above that, which is coming from bug 567645 dropping unknown events at [2]. Maybe we're dropping an event flash is expecting to determine focus? Otherwise this seems like a flash issue.

[1] http://dxr.mozilla.org/mozilla-central/source/dom/plugins/ipc/PluginInstanceChild.cpp#798
[2] http://dxr.mozilla.org/mozilla-central/source/dom/plugins/ipc/NPEventWindows.h#108

Comment 18

[Jim Mathies [:jimm]]

Juan, curious if you can help us here, we'd like to get better version coverage (or maybe even a regression range if it exists), and if possible, tests with different versions of flash.

Comment 19

[John Schoenick [:johns]]

Also flash is calling GetNetscapeWindow to get the native window widget when it starts up, which notes that "it turns out that flash also uses this window for determining focus" [1]. Did the behavior of GetRootWidget change at some point on windows? Maybe it is expecting a per-tab widget of some kind to determine if its tab is focused.

http://dxr.mozilla.org/mozilla-central/source/dom/plugins/base/nsPluginInstanceOwner.cpp#671

Comment 20

[jkeks]

Hi there, I'm bug finder - jkeks. First time here.
I'm From Russia

Bug exists and in IE8, sent to Microsoft too.
IE11 not affected

Opera12/24 not affected

Comment 21

[Matt Wobensmith [:mwobensmith][:matt:]]

Attachment: Another test case

This test case just isolates capturing one keystroke - the A key. Open the HTML file, switch tabs, press A, and return to the page to see if it captured your key press.

Offending ActionScript is AVM1.

var someListener = new Object();
this.onEnterFrame = function()
{
	if (Key.isDown(65))
	{
		label.text = ("you pressed A");
	}
};
Key.addListener(someListener);

Comment 22

[John Schoenick [:johns]]

Have we reached out to adobe about this yet? It seems that we are sending flash the proper focus events, but flash is not properly stopping its raw input detection. I'm not sure what can be done from our side, though checking if this ever worked in any build that can load modern flash might clue us in to what heuristic flash is using to determine focus.

Comment 23

[Jim Mathies [:jimm]]

Doing a little additional flash testing, I've reproduced this so far in flash versions 14.0.0.125, 13.0.0.231, 12.0.0.44, and 11.7.700.260.

http://helpx.adobe.com/flash-player/kb/archived-flash-player-versions.html

So I can't tie this to a rev of flash yet.

Comment 24

[Daniel Veditz [:dveditz]]

Hopefully Jeromie can find us an answer for comment 22.

Comment 25

[Jeromie Clark]

This is the first I'm hearing about it.  I'm filing ADBE 3797272 right now.  :)

Comment 26

[Jim Mathies [:jimm]]

A couple more data points: I can reproduce in Fx18 with the latest rev of flash, and also reproduced in flash rev 11.5.502.146, released 01/08/2013 in nightly.

reproducible in nightly with:
14.0.0.145
14.0.0.125
13.0.0.231
12.0.0.44
11.7.700.260
11.5.502.146

also reproduced in fx18 with 14.0.0.145.

Comment 27

[Daniel Veditz [:dveditz]]

John or Jim: the .swf doesn't appear to capture keystrokes when I switch to another application--how is it doing that? Do we send a different kind of lost-focus notification to Flash or is it figuring that out on its own? If it's something we're sending maybe we could send that in the tab-switch case as well.

Comment 28

[John Schoenick [:johns]]

(In reply to Daniel Veditz [:dveditz] from comment #27)
> John or Jim: the .swf doesn't appear to capture keystrokes when I switch to
> another application--how is it doing that? Do we send a different kind of
> lost-focus notification to Flash or is it figuring that out on its own? If
> it's something we're sending maybe we could send that in the tab-switch case
> as well.

I don't see us sending any events, and no traffic whatsoever with NSPR_LOG_MODULES=IPCPlugins:5

The call I mentioned in comment 19 is being used to get firefox's window handle, so I'm guessing flash is watching for focus-switch on that as well

Comment 29

[Jim Mathies [:jimm]]

(In reply to John Schoenick [:johns] from comment #28)
> (In reply to Daniel Veditz [:dveditz] from comment #27)
> > John or Jim: the .swf doesn't appear to capture keystrokes when I switch to
> > another application--how is it doing that? Do we send a different kind of
> > lost-focus notification to Flash or is it figuring that out on its own? If
> > it's something we're sending maybe we could send that in the tab-switch case
> > as well.
> 
> I don't see us sending any events, and no traffic whatsoever with
> NSPR_LOG_MODULES=IPCPlugins:5
> 
> The call I mentioned in comment 19 is being used to get firefox's window
> handle, so I'm guessing flash is watching for focus-switch on that as well

ditto, afaict, no events pass through the napi interface if the plugin is initially in the background and we change the focus of the top level browser.

Comment 30

[Matt Wobensmith [:mwobensmith][:matt:]]

I can repro in FP 9r124 as well.

IIRC, this was regressed at one point in the FP8/FP9 days, and then fixed. It has clearly regressed again since then.

Comment 31

[Matt Wobensmith [:mwobensmith][:matt:]]

I don't see the point of Juan looking for a regression range if it's purely a Flash Player issue. I mentioned it to him. If anyone feels that QA needs to spend more time looking for regression-related info, say the word, but I'm clearing the flag for him in the meantime.

Comment 32

[Jeromie Clark]

Yeah, I'm working through regression ranges.  I've walked it back to Flash Player 10.3 at this point and it still reproduces. As far as I can tell, this is just a really old bug.

Comment 33

[Daniel Veditz [:dveditz]]

Jeromie: as we head into the weekend any news? From the investigation here it looks like this has to be fixed on the Adobe side. All we've come up with that we could do on the Firefox side are pretty unsatisfactory and will leave users unhappy:
 - make Flash click-to-play
 - force wmode to "direct" for every flash on the web

Comment 34

[Jeromie Clark]

I agree that neither of those resolutions are very good.

We've triaged the issue and it is assigned to an engineer for remediation.  We are currently treating this as a responsibly disclosed issue (our general commitment for responsibly disclosed issues is to provide a fix inside 60 days), with the actual goal of addressing this in our next monthly shipping vehicle, which is our Market release.  Market is currently on-track to reach customers on September 9th.

Once a fix has been checked in (which I'm hoping will be soon), it will be available in the subsequent weekly public beta for evaluation, and I'd be more than happy to share advanced builds with Mozilla before then, if that would be helpful.

If Mozilla or Adobe becomes aware of the issue actually being abused in the wild, that would naturally change what the response looks like.  In the event you do find evidence of abuse in the wild, please contact the Adobe Product Security Incident Response Team ([e-mail]) immediately.  Feel free to continue copying me, but that account is staffed 24/7/365 with incident response experts and will start the appropriate emergency response gears turning.

Comment 35

[jkeks]

How it mey be problem of Adobe if there are not affected:
-IE11
-Chrome
-Opera24
-Opera12.17

sorry for my English =)

Comment 36

[Daniel Veditz [:dveditz]]

jkeks: There are different versions of Flash for those different browsers, and because the plugin API is more of a "historical accumulation" than a well-specified interface there is sometimes conditional code within plugins based on which browser it's running in to deal with various behavior differences. Like you, I initially assumed it was most likely a Firefox bug, but our investigation eventually pointed at Flash (for example, comment 16 and comment 17) and Adobe themselves have accepted this as a Flash bug (comment 34).

Given the symptoms are unique to Firefox (mostly) and the ubiquity of Flash use we may still consider this for the Mozilla bug bounty program since your report has resulted in changes that make Firefox users safer. Due to summer vacations the bounty committee may not be able to meet for a couple of weeks.

Comment 37

[jkeks]

Thanks for answer, Daniel

Comment 38

[Frederik Braun [:freddy]]

(In reply to Jeromie Clark from comment #34)

Hey Jeromie, will this make the next release (i.e. Sep 9th)?
Is this already in the public beta?

Comment 39

[Matt Wobensmith [:mwobensmith][:matt:]]

This doesn't appear to be fixed in today's FP 15.0.0.152 release.

Comment 40

[Jeromie Clark]

Yeah, unfortunately this didn't make the Market release.  We have a tentative fix and it looks like it will make the Market+1 update.

Comment 41

[Jeromie Clark]

FYI, this is fixed in the current beta builds:

* PASS: FP 15.0.0.170, 16.0.0.50 in Firefox 32.0.2 on Win7 x64
* PASS: FP 15.0.0.170, 16.0.0.50 in Firefox 32.0.2 on Win8.0 x64
* PASS: FP 15.0.0.170, 16.0.0.50 in Firefox 32.0.2 on Win8.1 x64

Comment 42

[Matt Wobensmith [:mwobensmith][:matt:]]

I've verified that this is fixed on FP 15.0.0.189, on WinXP, Win7 SP1 Pro, Win7 x64 and Win8.1 x64.

This is the current release build, right Jeromie? I assume the 16.x builds are beta.

Comment 43

[Jeromie Clark]

Sweet, glad it works.  

This fix will be available to end-users with the Market+2 (15.0.0.xxx) update, which is currently scheduled to release on November 11th.  We also verified that the issue is fixed in our mainline (16.0.0.xxx).  That was probably TMI.

Comment 44

[Matt Wobensmith [:mwobensmith][:matt:]]

Right... but I verified with the default install from the FP download page - FP 15.0.0.189. So it appears to be shipping now, yes? Or am I missing something odd with the versioning?

Comment 45

[Jeromie Clark]

No, I got my releases mixed up, sorry.  Flash Player 15.0.0.189 went live today.  This is fixed and shipped with the current release.

Comment 46

[Matt Wobensmith [:mwobensmith][:matt:]]

Good news is good news. Thanks Jeromie.

Comment 47

[Al Billings [:abillings - ex-MoCo]]

Dan, this is now fixed by Adobe. Since only we and IE were affected, do we need to issue an advisory or blog post?

Comment 48

[Daniel Veditz [:dveditz]]

Since this is a Flash bug and not a Firefox bug it technically doesn't qualify for a Bug Bounty, however since it was mostly a Firefox-only effect and reporting this to us did result in the bug being fixed we'd like to thank you with an award anyway.

Comment 49

[Daniel Veditz [:dveditz]]

(In reply to Al Billings [:abillings] from comment #47)
> do we need to issue an advisory or blog post?

not an advisory. Might already be mentioned in Adobe's advisory for the 15.0.0.189 release.

Comment 50

[Al Billings [:abillings - ex-MoCo]]

Resolving fixed based on Adobe addressing this since it is really a flash issue.

Comment 51

[jkeks]

Hello, where is my award, Daniel  ?