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.
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?
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.
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.
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.
Created attachment 175199 [details] prefs.js: preferences changed from their defaults The present state of my prefs.js file.
(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.
(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.
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.
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).
I cannot repro this using the 2005022207-1.0.1 firefox build on linux fc3.
jhs, can you try creating a new profile (run firefox.exe -ProfileManager) and see if that profile exhibits this problem?
nor can I repro this using the 2005022205-1.0.1 Mac firefox build on OS X 10.3.8.
(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
(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.
> > md5sum flashplayer7installer.exe > 9e2bb1b15d8bbdaae3569fc8ef3ff94c flashplayer7installer.exe Same here
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
Oh, no, that *is* the actual flash installer exe. But still, the plugin dll is what matters.
(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.)
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.
(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?
> 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.)
I suppose we could cc the usual set of macromedia.com bugmails, assuming those get read... want me to do that?
I've informed my contacts at Macromedia about this issue. I'll followup in the bug as I hear back from them.
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.
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.