[Laszlo-dev] Flash security vulnerability, a problem for OL?

[P T Withington]

On 2007-12-23, at 23:05 EST, David Russell wrote:

> The following article details what appears to be a serious security
> defect in tool generated SWF files:
>
> http://www.theregister.co.uk/2007/12/21/flash_vulnerability_menace/
>
> It notes "SWF files generated by six of the more popular content
> development tools automatically contain the bugs...". OL is not
> mentioned in the article so I have to ask: anybody know if OL  
> generated
> SWF share this vulnerability?


There are a number of issues discussed here, but they all hinge around  
validating your external inputs.

The simplest one is the 'php auto-register bug'.  This is where you  
have a program that depends on undeclared global being undefined (poor  
practice, of course, but it happens).  Because by default the flash  
player will define all the query args as globals before any of your  
program is executed, a cracker can potentially subvert your program by  
'clobbering' one of your globals with a query arg.  (Believe it or  
not, this is still considered a feature of the Flash player.  It  
really ought to be disabled, and the player should provide a simple  
way to extract query args from the url, as the LZX runtime does.)

Consider the following program:

> <canvas debug="true">
>   <script>
>     Debug.write(foo);
>   </script>
> </canvas>

if you invoke this with the query arg ?foo=busted!, you will see the  
vulnerability.  If you simply declare your globals:

> <canvas debug="true">
>   <script>
>     var foo;
>
>     Debug.write(foo);
>   </script>
> </canvas>

You will see that LZX is immune to this vulnerability.  It correctly  
maintains `foo`s initial value as `undefined`.

Here the compiler can help you.  If you compile and run the first test  
case above in debug mode (without supplying the ?foo parameter), you  
will get a warning that you are referencing an undefined variable:

> ERROR @security.lzx#3: reference to undefined variable 'foo'
> undefined

A more subtle instance of this vulnerability is when you explicitly  
extract a query arg, but don't validate it.  The scenario detailed in  
the article you reference goes something like this:

You have a sensitive page that loads a swf.
The swf is hosted on your trusted site (hence also trusted).
The swf takes a query parameter that is loaded as an url by the swf
The cracker can get the user to click on a link:
  trusted-site://trusted-swf?param=bad-url
In the example, the bad-url is of the form 'javascript:<give me your  
cookies>'

So basically, the advice is:  validate your program's parameters or  
your program may be subverted.

There's really nothing Adobe (or any development tool) can patch to  
prevent you from writing a program that fails to validate its inputs.