283107 - Flash application in an unfocused tab/window receives mouse events from the focused one

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect)

Description

[Johan Sundström]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

A flash application in one page may listen in on (at least mouse) events in any
other tab or window.

Whether the flash application could spy on user keyboard events in other windows
similarly I have not confirmed, but I expect it might be able to. Since both the
focused and background page receive and act on the events (for instance, I can
click links or click-drag mark page text in my focused page, while the flash
application happily sees widget clicks from same actions), a less audiovisual
application would remain an undetected listener.

(I have not installed the tab browser extension. Bugs that might and might not
be even remotely related: bug 272849, bug 275484.)

Reproducible: Always

Steps to Reproduce:
(Not strictly mandatory steps in ellipsis:)
1. (Open a new window.)
2. Load example URL in one tab / window.
3. (You may want to maximize widget surface area by choosing a 13 by 11 board,
clicking Play! and finally the lock icon.)
4. (Minimize this window.)
5. Open or go to another tab / window.
6. (You may but don't have to load another page here)
7. Move mouse over a spot where the flash application had a widget.
8. Note the mouse cursor change on behalf of the flash application.
9. (And if you click, you elicit said application's characteristic sound and
widget action).
Actual Results:  
A chill ran down my spine.

Expected Results:  
Only the focused page should have received the events; I should have heard no
clicks from the flash application, and when I returned to the flash application,
it should still remain in a state where no widgets I had not clicked prior to
leaving it, had been invoked.

Comment 1

[Johan Sundström]

Strike step 4; I probably didn't do that. (When I try now, it successfully stops
the problem from showing up.)

Closer inspection reveals that other applications too (xemacs, photoshop) are
affected, as soon as the flash application is running. Minimizing the mozilla
window with the flash application makes it go away.

about:plugins reports Shockwave Flash as File name: NPSWF32.dll, Shockwave Flash
7.0 r19. Problem not invented here, and rather a Macromedia issue?

Comment 2

[Johan Sundström]

Do feel free to close this bug if it's indeed not a mozilla issue, as suspected.
I filed it with http://www.macromedia.com/support/email/security/main.cgi too,
just in case.

Comment 3

[Daniel Veditz [:dveditz]]

I can't reproduce this on Windows XP trying both Firefox 1.0 and the latest
aviary branch build. I'm also using flash 7.0.r19.

I did not minimize the window, tried the flash app in a separate window behind
and as a background tab in the same window. No click throughs.

What's different here?

If you were on a Mac it could be bug 162134, but afaik that's only tab
bleedthrough, not windows.

Comment 4

[Daniel Veditz [:dveditz]]

Note that I desperately want to know how to reproduce this because it's a
serious issue that we would like to fix on the Mozilla side if at all possible.
Granting that plugins are native code running on your machine, we still want to
sandbox them as much as possible.

Do you have any extensions installed?

What non-default pref settings do you have? These would be stored in prefs.js
found in your profile (on windows XP usually something like
"c:\documents and settings\<account>\application data\mozilla\firefox\profiles\<random.name>\prefs.js)
or in about:config you can sort on the "status" column.

Comment 5

[Johan Sundström]

Attachment: prefs.js: preferences changed from their defaults

The present state of my prefs.js file.

Comment 6

[Johan Sundström]

(In reply to comment #3)
> I can't reproduce this on Windows XP trying both Firefox 1.0 and the latest
> aviary branch build. I'm also using flash 7.0.r19. [same procedure I perform]
>
> What's different here?

Tough, but let's try: my machine runs Windows XP Professional, service pack 2
installed and all presently available patches available via Windows Update too.
I use a handful of extensions, but the issue shows up when they are disabled too
(by running Safe Mode); would enumerating extensions still be useful?

I suppose I'll attach my userChrome and userStyles files too, in case they could
be a lead - especially the latter might be, with a bit of luck.

Comment 7

[Johan Sundström]

(On second thought, I tried removing userStyles.css and userChrome.css, and
while I for a while remembered what a vanilla firefox installation looks like,
it did not alter the symptoms of the bug.)

(In reply to comment #4)
> Note that I desperately want to know how to reproduce this because it's a
> serious issue that we would like to fix on the Mozilla side if at all possible.
> Granting that plugins are native code running on your machine, we still want to
> sandbox them as much as possible.

Perhaps not of much interest, but Internet Explorer for once does seem to manage
to get the job done right, so we might be in a position to fix it on the Mozilla
side, too.

I think my next action target is trying out a more recent build to see if the
problem persists.

Comment 8

[Johan Sundström]

Not sure if http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest-trunk/
is the place to look for those, but that build (Build ID: 2005022205) exhibits
this behaviour too.

Comment 9

[Johnny Stenback (:jst)]

I tested this too, and no luck. I did all sorts of combinations of Firefox
windows etc. I tested using Firefox 1.0.

I'd recommend getting a build from:

  http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-aviary1.0.1/

and doing a *clean* install to a new location, and creating a completely new
profile (start Firefox with a -ProfileManager argument, don't rely on safe mode,
that's not as safe as it could be).

Comment 10

[sairuh (rarely reading bugmail)]

I cannot repro this using the 2005022207-1.0.1 firefox build on linux fc3.

Comment 11

[Asa Dotzler [:asa]]

jhs, can you try creating a new profile (run firefox.exe -ProfileManager) and
see if that profile exhibits this problem? 

Comment 12

[sairuh (rarely reading bugmail)]

nor can I repro this using the 2005022205-1.0.1 Mac firefox build on OS X 10.3.8.

Comment 13

[Johan Sundström]

(In reply to comment #9)
> I'd recommend getting a build from:
>
>   http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-aviary1.0.1/
>
> and doing a *clean* install to a new location, and creating a completely new
> profile (start Firefox with a -ProfileManager argument, don't rely on safe mode,
> that's not as safe as it could be).

Reproduced the symptoms with the new profile and latest build (20050222) there.
Other venues to try? Might I be using a doctored flash player?

> md5sum flashplayer7installer.exe
9e2bb1b15d8bbdaae3569fc8ef3ff94c  flashplayer7installer.exe

Comment 14

[Johan Sundström]

(In reply to comment #13)
> Other venues to try? Might I be using a doctored flash player?
>
> > md5sum flashplayer7installer.exe
> 9e2bb1b15d8bbdaae3569fc8ef3ff94c  flashplayer7installer.exe

After a fresh reinstall of that binary, I can't reproduce the bug in the
20050222 build, but still get it in the 1.0 release.

Comment 15

[Daniel Veditz [:dveditz]]

> > md5sum flashplayer7installer.exe
> 9e2bb1b15d8bbdaae3569fc8ef3ff94c  flashplayer7installer.exe

Same here

Comment 16

[Johnny Stenback (:jst)]

The actual flash plugin that Firefox uses is in a dll file named npswf32.dll,
the installer mentioned here is just an auto update installer for flash, IIRC.

ac88e090f44692e974108555fc3330e4 .../Mozilla Firefox/plugins/npswf32.dll

Comment 17

[Johnny Stenback (:jst)]

Oh, no, that *is* the actual flash installer exe. But still, the plugin dll is
what matters.

Comment 18

[Johan Sundström]

(In reply to comment #16)
> The actual flash plugin that Firefox uses is in a dll file named npswf32.dll,
> the installer mentioned here is just an auto update installer for flash, IIRC.
>
> ac88e090f44692e974108555fc3330e4 .../Mozilla Firefox/plugins/npswf32.dll

Both my installations (1.0 and above aviary branch build) have this md5sum:

> a1353ba0e465748a1a01ec1786fcb9b5  NPSWF32.dll

and it's 832728 bytes long. Might I guess that it rather ought to be 827392
bytes, as is listed at http://www.e-systems.ro/download-dll/npswf32.dll/? 5336
bytes ought be plenty for patching on features like these, should malicious code
be behind this. (On the other hand, I don't know if the dll contains any strings
that vary with installation environment.)

Comment 19

[Johnny Stenback (:jst)]

I'd suggest you delete your flash player and launch firefox and go to a site
that uses flash. Then follow the steps to install the plugin through the plugin
finder service that'll be presented to you. Yes, the file should be 827392 bytes
in size, and the version number should be 7.0 r19.

Comment 20

[Daniel Veditz [:dveditz]]

(In reply to comment #18)
> 
> Both my installations (1.0 and above aviary branch build) have this md5sum:
> 
> a1353ba0e465748a1a01ec1786fcb9b5  NPSWF32.dll
> 
> and it's 832728 bytes long.

That's what I get too, and I just downloaded and ran a new copy of the installer
from macromedia's site (not our plugin finder). As mentioned before I don't see
the problem you're seeing.

> Might I guess that it rather ought to be 827392
> bytes, as is listed at http://www.e-systems.ro/download-dll/npswf32.dll/?
> 5336 bytes ought be plenty for patching on features like these, should
> malicious code be behind this.

It's a little disturbing that there seem to be at least two different "7.0.r19"
versions out there. Johnny, have any contacts at Macromedia who could straighten
us out on which one is the real one, or if they had a silent in-line re-release?

Comment 21

[Johan Sundström]

> Johnny, have any contacts at Macromedia who could straighten us out on
> which one is the real one, or if they had a silent in-line re-release?

David Lenoe of Macromedia's Product Security Team has mailed me back now
reporting that they have managed to reproduce this behaviour, and that it only
seems to leak mouse events to the flash application (the application won't see
which window the events were targeted at, though, so in their point of view, it
might not be a very high ranking security issue).

While he did suggest I should get back to him by mail or phone had I any
questions, proxying ticket traffic back and forth between bugzilla and the
Macromedia guys seems slow and strenuous to everybody involved. Somehow sharing
intelligence on this could be useful, though, so the problem class could be
addressed on both sides of the plugin interface barrier.

Since I'm neither near US time zones nor very involved in the Mozilla dev team
I'd gladly pass the ball on, if I know whom to introduce. (Or, should nobody be
interested in engaging in such communication, what form does Mozilla-$Business
contacts usually take? Especially regarding issues where a bug is closed from
public consumption, as this one is.)

Comment 22

[Boris Zbarsky [:bzbarsky]]

I suppose we could cc the usual set of macromedia.com bugmails, assuming those
get read... want me to do that?

Comment 23

[Johnny Stenback (:jst)]

I've informed my contacts at Macromedia about this issue. I'll followup in the
bug as I hear back from them.

Comment 24

[Daniel Veditz [:dveditz]]

Did this ever get resolved with newer versions of Flash? I still have never been able to reproduce this problem and would like to close this bug if it's not doing us any good.

Comment 25

[Josh Aas]

This is an old bug, it probably isn't an issue any more. Looks like Mozilla engineers had a hard time reproducing even many years back.

Gecko tells plugins when they have a cliprect of size zero, that is what they should be using to determine whether or not to listen to events. We can't stop plugins from doing this in general on our end because they are trusted code.

I'm opening this bug up. I've seen this type of issue brought up in public before, the given PoC isn't very specific (dangerous), and if there is anything we can or should do about this it'll get done a lot faster if we have more eyes on the problem.