The Technical Aspects of Exploiting IE Zero-Day CVE-2013-3897

Just last month, during our work at spiderlabs research, the team and myself had the chance to analyze CVE-2013-3897 Use-after-free vulnerability.
This vulnerability was basically a result of an object type CDisplayPointer being freed and used again when a richtext tries to scroll the pointer into the current view.
A flow that includes a selection, that occurs under "onpropertychange" event, and a DOM that contains a textarea structure (detailed below) results a possible remote code execution.

Breaking it to down

1. Create a TEXTAREA and apply a different element as a child using applyElement. This will place theaddress element as the child of the textarea element.

2. Trigger a select event on the TEXTAREA element to create an instance of DisplayPointer.

3. Inside onselect event change the value property of the TEXTAREA element, which in turn will fire the eventonpropertychange. For example, usage of appendChild or swapNode will cause this behavior. 

Notice that id_2 (“address” element) is a child of the TEXTAREA element. By swapping that element we remove it from layout of “textarea” and insert a different element, therefore the value property changes.

4. The event onpropertychange is triggered

5. In the next stage we basically need to change the position of the display pointer within the TEXTAREA layout. In the original exploit document.execCommand(“UnSelect”) was used. However, selecting a different element, executing the SelectAll command or any operation that causes a DisplayPointer position change will also work. 

The attacker used "UnSelect" command

6.  The JavaScript selection causes a call to CDisplayPointer::ScrollIntoView, which tries to set a new position for the DisplayPointer. At this stage, the reference to CMarkupPointer is already released by the CDisplayPointer::Release function (as a result of the “UnSelect” command) and therefore points to an attacker-controlled heap area.

The flow eventually gets into QIClassID, which tries to execute “CMarkupPointer::QueryInterface” (located at offset 0x0 in CMarkupPointer’s virtual table).

QIClassID (use): 

QIClassID disassemble crash point

At the crash we end up with the following stack trace:

CMarkupPointer freed and then used by QIClassID:

Most of this post was originally generated here:
(http://blog.spiderlabs.com/2013/10/ie-zero-day-cve-2013-3897-technical-aspects.html)

X-Framing them all! - Cross-Framing is "impossibe" - Apple’s iOS 5

Cross Framing Google, Facebook and whoever you wish. 

Jailbreak Your Device? or buy android?

This post is mostly for people who hold iPhone/iPad/iPod or any other iDevice.

As for today at least for most people, jailbreaking is a serious concern and as for my experience it can even determine whether or not to purchase IOS(Apple) or Android(Google) device.
 there are quite many differences that comes to mind, one bold example is that the exact same application (whatsapp for example) would be free if you hold an smart-device who runs android, and would cost money if you use iDevice unless it is jailbreaked.

Some people even say the reason there was no jailbreak for iPhone5 might affected the apple sales, New York Times post on “Apple Earnings”

“Once-euphoric investors, who pushed Apple’s stock to a record high of $702.10 last September, have become nervous, and in early trading on Thursday, the stock traded at $455.89, down more than 34 percent from its peak.” (http://www.nytimes.com/2013/01/24/technology/apple-earnings.html)

Are you, behind? IOS 5.1.1? 6.0.1?

Since the only reason to convince us to upgrade to IOS 6 are update you already have with your installed Cydia tweaks, people just “stay behind” and use IOS 5.1.1 or lower to still have a nice jailbreaked iPhone. 

So you use IOS 5 or lower? Are you Safe?

As for today we already know there are many web application vulnerabilities around, client side attacks and mostly cross site scripting have become one of the most common attacks in the past recent years.

Google, Facebook, Microsoft, Paypal, Mozilla, Apple and many other great companies have tried to fight against the security risks to give us - their product customers, the answer to keep our data safe.

But do they?

Many of the web application developers had to deal with many different client side attacks and design their security architecture to protect their users and avoid different hacking attempts targeting their customers, since some attacks such as frame-busting click-jacking, multiple stage attack, self-XSS exploitation etc, are not easy to deal with and require browser cooperation.

There are quite a few client side security solutions such as Anti-XSS filters; No-Script, XSS-Auditor, SoP different headers, Caching, and X-Frame-Options header which define how the interpreter handles a response from a webpage loaded insde frames.

Safari on your iPhone(or iDevice) – you CHOOSE to stay vulnerable:

So Google’s/Facebook’s/Paypal’s/Any_Other web developers(including myself) can rely on browser implemented security features and protect their webpages from Client side attacks mostly from Click-Jacking and staging attacks with X-Frame-Options, setting it so that the webpage content will only be displayed after a request coming from the Same-Origin or completely disable Framing and thinking everything is now secured, what we unfortunately forget it is basing the protection on browser's client security. 

What if the browser fail?

I reported to apple 2 months ago at 06/12/12, that I discovered that even though the web server (in this example “www.google.com”) set HTTP response header, X-Frame-Options Header to Same Origin the response will still be displayed using my iDevice.

As you can see in the following PoC HTTP response while sending HTTP request to Google.com:

HTTP/1.1 200 OK
Date: Thu, 06 Dec 2012 15:54:50 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=UTF-8
Server: gws
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Content-Length: 99283 

Setting this header suppose to provide browser client side security that will allow the iframe element to be displayed only if the parent document is at the same origin/domain of the iframe src attribute.

It appears the Safari Browser does not enforce X-Frame-Options and therefore displays our frame element as it did not even have any protection.

Normal Behavior IE9 enforcing X-Frame-Options: 

Safari on IOS 5:

PoC Test Page:

<html>
<head><title>X-Frame-Options Bypass</title></head>
<h1>Apple PoC X-Frame-Options </h1>
<iframe id="X" src="http://www.google.com"></iframe>
<script>
framex = document.getElementById("X");
framex.onload = function () { }

</script>
</html>

Btw, This also means ClickJacking Anywhere Over IOS 5 and lower victims.

So What Should I Do?

Well, Apple did good and fixed this issue in the New IOS (6.0.1)
Unless you want to stay vulnerable knowning you can be a victim to advanced client side attacks over your gmail/facebook make sure you use IOS 6.