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?
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).
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.
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.
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 10.0.45.2. 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:
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.
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.
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)
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.