When a file reference object is created, the type and user data of the object are set, but the destructor function is not cleared. This means that if the file reference object is constructed with a 'this' object that already has a destructor, it will get called on the wrong type of data when the object is destroyed, leading to native method calls on an object of the wrong type, which is usually exploitable.

A sample SWF is attached, it works as follows:

1) Pressing the full blue square on the left of the attached SWF will cause a FileReferenceList to be created. After it is created, the FileReference constructor is overwritten as follows:

var b = flash.net;
b.FileReference = q;

This code overwrites the FileReference constructor with method q.

2) browse() is then called on the FileReferenceList, causing a file selection dialog to be spawned

3) If the user selects a file, the function q will be called to construct a FileReference to hold the file the user selected. q is defined as:

this.f = flash.display.BitmapData
var c = new this.f(1000, 1000, true, 1000)

Note that Flash CS3 doesn't build this code as expected, and I had to manually correct a few actions in the SWF.

Calling this method causes the this object passed into the constructor to be initialized as type BitmapData, which sets the BitmapData destructor. After the method is exited, the browse function sets the type of the returned object to be a FileReferenceObject, but doesn't clear the destructor.

4) A crash will occur when GC happens, the button on the right of the poc can be used to trigger GC with limited reliability if the crash doesn't happen right away.

POC SWF is attached. This issue is marked as moderate, as FileReferenceList.browse always requires user interaction.
 

fdestroy9.swf 2.7 KB Download