If XMLSocket connect is called on an object that already has a destroy function set, such as a BitmapData object, the method will set the user data of that object, but not clear the destroy function. This leads to type confusion when the user data is freed during garbage collection.
The crash was observed in Flash Player 17.0.0.188 on Windows due to a use-after-free related to loading a sub-resource from a URL. The crash appears to occur when a jmp instruction is executed. The test case reproduces on Windows 7 using IE11, but does not appear to immediately reproduce on Windows+Chrome or Linux+Chrome.
There is a type confusion issue in TextRenderer.setAdvancedAntialiasingTable. If the font, insideCutoff or outsideCutoff are set to objects that are not integers, they are still assumed to be integers. A proof-of-concept is provided in the text.
A use-after-free vulnerability exists in Adobe Flash Player due to a flaw when CreateTextField is called on a MovieClip heirarcy. If a call is made into a function that deletes the MovieClip, a use-after-free occurs. This can be exploited to execute arbitrary code by tricking a user into opening a specially crafted SWF file.
Looking at https://github.com/adobe-flash/avmplus/blob/master/core/XMLListObject.cpp: In [1], the passed in index is validated. In [2], the callback can run actionscript, which might shrink the size of the current XMLList. In [3], the pre-validated index is used but it might now be invalid due to shrinking at [2]. Unfortunately, removeAt() does not behave well in the presence of an out-of-bounds index. The PoC works by triggering a wild copy in order to demonstrate the crash. But other side-effects are possible such as decrementing the refcount of an out-of-bounds index.
There is a use-after-free in MovieClip.swapDepths, a POC is as follows: var clip1 = this.createEmptyMovieClip("clip1", 1); var clip2 = this.createEmptyMovieClip("clip2", 2); var n = {valueOf: func, toString: func}; clip1.swapDepths(n); function func(){ clip1.removeMovieClip(); //_root.createEmptyMovieClip("test", 1); trace("here"); return "clip2"; } A swf and fla are attached.
The attached sample file, signal_sigsegv_7ffff637297a_8900_e3f87b25c25db8f9ec3c975f8c1211cc.swf, crashes, perhaps relating to XML handling. The crash looks like this on Linux x64: rcx 0x303030303030300 217020518514230016. The wider context shows that the wild pointer target can be incremented with this vulnerability, which is typically enough for an exploit.
A vulnerability in Adobe Flash Player allows an attacker to read data from memory locations outside of the intended bounds of a buffer, due to improper bounds checking. This can lead to information disclosure, and potentially code execution. This vulnerability affects Adobe Flash Player versions prior to 32.0.0.371.
A use-after-free vulnerability exists in Adobe Flash Player versions 17.0.0.188 and earlier. The vulnerability is caused by a non-deterministic condition that can lead to a crash when accessing memory after it has been freed. This can be exploited to execute arbitrary code by tricking a user into opening a specially crafted SWF file.
Running the attached swf file in Google Chrome (Linux x64) will eventually result in dialog offering to terminate the slow script. Upon electing to terminate the script, a crash occurs. It is not known whether this bug can be triggered or not without user interaction.
Services By CQR