Deep Analysis of CVE-2014-0502 – A Double Free Story
The Adobe Flash Player zero-day that was part of a targeted attack that infected several nonprofit organizations’ websites.
The vulnerability is a double-free vulnerability caused by a bug in how shared objects are handled by Adobe Flash Player.
The full story:
http://blog.spiderlabs.com/2014/03/deep-analysis-of-cve-2014-0502-a-double-free-story.html
A double free vulnerability occurs during the termination of adobe flash worker. when a worker is being terminated, all shared objects (also called as "flash cookies") are flushed an then freed from memory. while failing to flush an off limit "shared object" to disk (for being above 100KB data) a garbage collection occurs. the garbage collection decides to free the "shared object" from memory whilst the first free operation is still in process.
a screenshot presenting a "record" shared object while exploiting the vulnerable code and controlling EIP (0xcccccccc+8):
the screenshot blow presents the internal SharedObject destructor procedure, you can notice that there's a flag that checks whether flushing data to disk is required.
the "SharedObject" has data pending for flushing but fails to do so since the data exceeds the 100KB limit. then during the flushing attempt, garbage collection fires and frees the object without clearing this "pending flush" flag.
This specific flow will result in the “Pending Flush” flag being up when the object was already freed, and therefore Adobe Flash Player will try to execute a function from a dereferenced pointer otherwise known as remote code execution.
I originally posted this post on spiderlabs blog. for more details read the full story.
The vulnerability is a double-free vulnerability caused by a bug in how shared objects are handled by Adobe Flash Player.
The full story:
http://blog.spiderlabs.com/2014/03/deep-analysis-of-cve-2014-0502-a-double-free-story.html
A double free vulnerability occurs during the termination of adobe flash worker. when a worker is being terminated, all shared objects (also called as "flash cookies") are flushed an then freed from memory. while failing to flush an off limit "shared object" to disk (for being above 100KB data) a garbage collection occurs. the garbage collection decides to free the "shared object" from memory whilst the first free operation is still in process.
a screenshot presenting a "record" shared object while exploiting the vulnerable code and controlling EIP (0xcccccccc+8):
the "SharedObject" has data pending for flushing but fails to do so since the data exceeds the 100KB limit. then during the flushing attempt, garbage collection fires and frees the object without clearing this "pending flush" flag.
This specific flow will result in the “Pending Flush” flag being up when the object was already freed, and therefore Adobe Flash Player will try to execute a function from a dereferenced pointer otherwise known as remote code execution.
I originally posted this post on spiderlabs blog. for more details read the full story.
