====================
Update: 30th November 2015:
The additional Flash Player security mitigations discussed in this blog post have since been bypassed by attackers. Further details are available from this Trend Micro blog post. Possible further mitigations are in development by security firm Endgame. These additional mitigations are discussed in a more recent blog post.
Thank you.
====================
Original Post:
====================
With the recent public disclosure of 3 Adobe Flash Player zero day vulnerabilities as part of the data breach of the “Hacking Team”; Adobe and Google have worked together to introduce additional exploit mitigations/defences to Adobe Flash Player.
These mitigations incorporate 3 improvements as detailed below:
Heap Partitioning
To protect against general buffer overflows that overflow into another object e.g. Vector. the memory in use by Flash Player for such Vector. objects is no longer stored in one area which means that an overflow cannot occur since one area of memory is no longer located beside another. In reality the Flash heap no longer contains Vector. objects, instead they are placed on the memory heap belonging to the operating system and no longer present on the Flash heap (where they could be corrupted). This mitigation defends against heap overflow and the common use-after-free (defined) exploits (since free chunks of memory are no longer freed within the Flash heap thus the attacker does not know the value to set the pointer to; in order to be able to use a new block of memory placed at the location that was just freed). This mitigation is especially effective with 64 bit versions of web browsers installed on a 64 bit operating systems due to 32 bit address space limitations no longer being present.
Memory Randomization of the Flash Heap
For allocations of memory that are greater than 1 MB are now randomized more thoroughly than before (in other words more entropy has been added). When a 64 bit system is in use, the Flash heaps position in memory will very likely be located far from other memory in use. Since the heap is so far away from other memory sections in use, a buffer overflow would unlikely be able to corrupt enough memory sections in order to use them for malicious purposes (since a 32 bit buffer overflow has a limit e.g. 2^32 * sizeof (in bytes) of variable type in use e.g. char, int, double etc.). The limit would be reached before the overflow could reach far enough into memory to have the intended effect.
At this time, this mitigation is only available within the Flash plugin built into Google Chrome, Adobe plans to make this mitigation available for all other versions of Flash in August.
Vector Length Validation
The final notable mitigation prevents the successful exploitation of buffer overflows for Vector objects. For each Vector object that is created a corresponding length of that object is stored along with a validation secret namely a value generated when the object was allocated by the operating system memory manager. When an exploit corrupts the known length of the Vector object, if they don’t know the value of the validation secret, this will cause a runtime error to be generated and all running code will halt, protecting you from the exploit. This secret value acts very much like the security cookie of Microsoft’s buffer overflow protection built into Windows with the introduction of the /GS (guard stack) compiler flag of Visual Studio 2005. This technology was incorporated into Windows XP Service Pack 2 in August 2004.
Conclusion
While these mitigations will make it harder for exploits to carry out their intended purpose, they won’t stop all exploits (I don’t mean this is in an offensive manner, no mitigation is perfect and these new mitigations were designed to make it harder not impossible for exploits occur).
In addition, it’s very likely that the exploit authors will begin to create exploits that avoid these mitigations either by working around them or using object types that don’t yet have these mitigations in place. However Google have pledged to continue improving the mitigations available as time goes on. It will be interesting to see the kinds of exploits/vulnerabilities emerging in the coming months.
Thank you.
securityinaction 