1 2 Previous Next 46 Replies Latest reply on Feb 23, 2010 9:29 PM by verdy_p Go to original post
      • 40. Re: Curious Flash player update
        Jochem van Dieten Level 4

        verdy_p wrote:

        This time, this is not necessary, the component starts running immediately

        The <embed> tag you are showing does not have a play="false" attribute, so that is expected behaviour. The tag attributes technote clearly says that the default is true.


        and starts playing in the local zone without an explicit user action.

        How did you ascertain that it was in the local zone? What else do you have in your local zone and in your trusted zone?



        Apart from your ascertion it is in the local zone, which may have a perfectly sensible explanation, I really don't see anything special in what you describe. It is just a .swf that opens a popup window with a location that happens to be a .exe file. And just like would happen if the opening of the popup window were done through Javascript from the onload event, any decent popup manager will suppress the popup.

        • 41. Re: Curious Flash player update

          You did not see the issue. The download starts on a mouseover event. Even if the video starts "playing" it just contains a single frame with a poor resolution. The file is too large for this single frame, notable after the compression from SWF to SFC (220KB is too much for just a single frame and a basic static GUI interface with a few simple buttons).


          The rest is certainly a complex script that will attempt to bypass the security tests (based on counting stack frames, something that could be easily exploited by an uncaught exception within the Flash Player renderer, but trapped at lower level by the javascript).


          Note that this is definitely not a simple URL at end of the video. if this was the case, it would open as a normal popup and would be blocked by the browser. Note that the download starts BEFORE the browser actually sees a popup (probably a secondary method to get this same download) and displays an alert.


          And anyway, Flash Player 10 is supposed to restrict the use of popups and file downloads in ActionScripts, as long as there's not been any activation by an explicit click. Here a mere "mouseover" is enough, this should not have worked. This is a bug in Flashplayer10 which defeats one of its documented design requirements (this vulnerability existed in Falsh Player 9, and Flash Player 10 was explicitly modified to change the requirement: no internet interaction is allowed before activation, the only data usable is the one within the SWF file itself, the Actionscript should be completely stale, with the javascript engine blocked or possibly even not instantiated at all, before activation in Flash Player 10; before this activation, falsh Player should only use its own rendering and should manage all user events without using any part of the script within that file; it should only render the properly encoded videos, with a strict validation, ans the static GUI objects that make up the GUI interface visible in the Flash component, like here the "Menü" button, and theother play or bolume control buttons should should just be static images).


          See also these recent CVE-MITRE/Secunia report about Adobe Flash Player:





          "Adobe Flash Player Domain Sandbox Bypass Vulnerability"


          I think it may be related to the same bug (and here I think this may be somewhere in the Actionscript transitions/effects specified in the embedded CSS for displaying the static "player" interface, and that will run within the context of the wrong security zone)


          I passed the SWF to a SWF validator (the one used by DoubleClick for its advertzing banners), it is correctly encoded, but DoubleClick should never tolerate such SWF in its advertized banners if they can freely open popups and freely perform downloads (saving to local disk, and not just within the unsafe Player cache for its sandbox)


          So this SWF is demonstrating that was possible in Flash Player 9 and supposed to be closed in Flash Player 10 by a new security restriction still works as before (and so it can launch the same attacks that occured in last August-September 2009). And it's not surprizing that it is used now to try downloading new versions of a worm that has had many variants during last automn. it took many months by Adobe to design a solution against this vulnerability (and this has caused the development of a FlashBlocker addon for Firefox and IE browsers).


          I think that this bug is critical for all commercial advertizing networks delivering ads in Flash format in lots of websites (DoubleClick being one of the most wellknown), because the lack of automatic detection of this behavior means that these ads must once again be manually tested (but the Doubleclick test is still based on what happens when you make an active click, a mere "mouseover" event was not supposed to activate the link within the banner).


          The current code also bypasses the popup blockers by reaching another unrelated domain immediately prior to any user activation on the same component within the same webpage and same browser frame displaying the same document. all happens as if the link hidden in the SWF had been explcitly launched from a desktop shortcut or from a browser's "favorite" link these links are not supposed to display a confirmation before reaching an external site, because they are normally launched by an explicit user click or keypress).


          "Mouse over" events should only perform actions requiring data from the same domain (for example changing an image by another stored in the same domain, or using scripts loaded from the same domain). They are definitely not explicit user actions. They should not grab the mouse, they should not grab the keyboard input, they should not be able to use the clipboard, they should not be able to read or save data on disk out of the sandbox's temporary storage in the player's cache which should remain isolated in the same domain, they should not be able to open any new frame (window or tab), and they should not be able to access to the container document (to modify its DOM tree and insert HTML elements there), they should not be able to control any other browser's frame (even if they know their name), they should not even be able to read any other file from the browser's cache (which is separated from the Player's cache), except if they belong to exactly the same domain and this domain is in the whitelisted/secure zone.


          There are probably several other restrictions where this SWF has exploited vulnerabilities.

          • 42. Re: Curious Flash player update
            Jochem van Dieten Level 4

            verdy_p wrote on 2/23/2010 9:01 PM:

            Note that this is definitely not a simple URL at end of the video. if this was the case, it would open as a normal popup and would be blocked by the browser.


            It is blocked in my browser. Have you tried a different browser? The

            popup blocker in IE is not as comprehensive as the one Firefox.



            Note that the download starts BEFORE the browser actually sees a popup (probably a secondary method to get this same download) and displays an alert.


            The download never starts for me. I verified with a packet sniffer

            capturing all traffic between me and the internet that there is no

            download whatsoever unless I click to allow the blocked popup. And even

            then it is the standard browser dialogue.



            See also these recent CVE-MITRE/Secunia report about Adobe Flash Player:




            That was fixed in If you are using an older version of the

            Flash Player then all bets are off.



            I think that this bug is critical


            Since you are not answering my questions as to why you think it is in

            the wrong security zone I don't think we are making any progress. And

            even if we were making progress, if you seriously think this is a

            security issue this is not the right place for it. This is a user forum,

            not a vendor forum. Get the source of one of the email messages you

            receive that trigger the behaviour experience and send it to Adobe:


            • 43. Re: Curious Flash player update
              verdy_p Level 1

              If you don't read, I can't  replay more. I had already said since the begining that I have the latest version of the Flash Player. whan I spoke about the CVE/secunia listed vulnerabilities, yes it is supposed to be fixed. I asked whever this could be related, because I have now doubts that this was ever fixed.


              Also I have already said that I did not use IE (IE is not even installed on my Windows 7 release, which is an European version without it).


              All this was said since the beginning. don't make false assumptions about something that I have never written. Your interpretations are false.

              • 44. Re: Curious Flash player update
                verdy_p Level 1

                Also I already gave the source of the email, which only contains the small HTML fragment listed first (a single <embed> element and nothing else; the URL to the infected SWF is already present, Adove has everything to work, just like other Antivirus teams that have accepted the same info, it was clearly enough to allow them develop a detection and acknowldge that this was an exploit). The source does not matter, it is just spam sent from random infected sources on various places. I'm not discussing here the spam itself, and Adobe will not be able to fight it.

                • 45. Re: Curious Flash player update
                  verdy_p Level 1

                  Update: this SWF vector is now detected by Avira as "SWF/Dldr.CM" (this blocks all other malwares that may be downloaded through it from within one of its many internally encoded URLs)

                  • 46. Re: Curious Flash player update
                    verdy_p Level 1

                    The SWF apparently has many other concurrent variants, targetting each various ISPs. Most of them are targetting China or using various sets of hosting URLs for the malwares they attempt to download.

                    So there's now a new list of "SWF/Dldr.Agent.XX" (replace XX by the variant) detected by Avira (Chinese version). They have just been listed as well there, but still not deployed to all other Antivira customers.

                    1 2 Previous Next