A revised security architecture in the new version of Flash may drastically reduce malicious users' ability to "clickjack" their way into remote code execution. But it requires admins of content provider sites to take notice.

The cross-site scripting vulnerability problem with Adobe Flash has been known for some time. Since Macromedia first made it possible for Flash clients to receive content and instructions from sites outside the domain that launched them, it's been an even bet that the mechanism relied upon to maintain the integrity of Flash sessions would be the target of malicious attack.

That mechanism is the policy file, which is a kind of lock that's supposed to enable Flash content from one site to allow itself to be appended by content from an outside domain. For many organizations whose content is derived from multiple sources or partners, even worldwide, such a policy system may be necessary. But cross-site content wasn't even possible before Flash 7; and possibly as a result, many admins' inattention to the proper use of the policy file once it was implemented, may have contributed to the vulnerability problem.

With the release of Flash Player 10 this week, Adobe enters a new, planned phase in addressing what Adobe still calls a critical issue. In fact, you could consider Flash 10 the "patch" for the hole, except that Adobe has been implementing its ultimate fix for the issue as a long-term project, and yesterday marked the beginning of the final stage in that fix.

"Like most new technologies, policy files weren't perfect when they were first introduced. After four years, the Internet security community has found two undesirable situations...that can arise from the existence of policy files," reads the latest version of an article from Adobe security engineer Deneb Meketa, updated last month.

"The basic premise of policy files remains valid," Meketa writes, "and Flash developers can continue to rely on policy files just as they have since Flash 6. To address the new concerns, however, Adobe is specifying some stricter rules for the use of policy files. Additionally, there are a number of improvements that make policy files more useful and usable."

Far stricter rules on the implementation of policy files, Meketa goes on, are intended to reduce the likelihood that any kind of malicious file can be crafted to masquerade as the policy file. In earlier editions of Flash, it was possible for a malicious site to present the client with a false image file, such as a fake JPEG, and then trigger it to reveal itself as an SWF script that altered the policy file.

Another new safeguard he mentions is the use of socket-level binding, as a way of thwarting instances where malicious content can alter the client's local DNS server to make it appear as though later content is actually coming from the legitimate content's origin. That can happen if IP addresses or DNS names are used to determine the origin of content; this type of optional binding enables resolution to take place at a much more granular level.

Admins have been warned for some months that stricter policy controls were coming, so the fix to this problem has required renewed vigilance from all sides. While some have faulted Macromedia's, and later Adobe's, response to this issue as slow, the amazing fact has been that this vulnerability has not been exploited more than it has. Historically speaking, there's a good chance security developers have spent more time on this issue than malicious users.