Security
Headlines
HeadlinesLatestCVEs

Headline

When ASLR makes the difference

We wrote several times in this blog about the importance of enabling Address Space Layout Randomization mitigation (ASLR) in modern software because it’s a very important defense mechanism that can increase the cost of writing exploits for attackers and in some cases prevent reliable exploitation. In today’s blog, we’ll go through ASLR one more time to show in practice how it can be valuable to mitigate two real exploits seen in the wild and to suggest solutions for programs not equipped with ASLR yet.

msrc-blog
#vulnerability#mac#microsoft#java#wordpress#pdf

We wrote several times in this blog about the importance of enabling Address Space Layout Randomization mitigation (ASLR) in modern software because it’s a very important defense mechanism that can increase the cost of writing exploits for attackers and in some cases prevent reliable exploitation. In today’s blog, we’ll go through ASLR one more time to show in practice how it can be valuable to mitigate two real exploits seen in the wild and to suggest solutions for programs not equipped with ASLR yet.

Born with ASLR

ASLR mitigation adds a significant component in exploit development, but we realized that sometimes a single module without ASLR loaded in a program can be enough to compromise all the benefits at once. For this reason recent versions of most popular Microsoft programs were natively developed to enforce ASLR automatically for every module loaded into the process space. In fact Internet Explorer 10/11 and Microsoft Office 2013 are designed to run with full benefits of this mitigation and they enforce ASLR randomization natively without any additional setting on Win7 and above, even for those DLLs not originally compiled with /DYNAMICBASE flag. So, customers using these programs have already a good native protection and they need to take care only of other programs potentially targeted by exploits not using ASLR.

ASLR effectiveness in action

Given the importance of ASLR, we are taking additional efforts to close gaps when ASLR bypasses arise in security conferences from time to time or when they are found in-the-wild used in targeted attacks. The outcome of this effort is to strength protection also for previous versions of Microsoft OS and browser not able to enforce ASLR natively as IE 10/11 and Office 2013 can do. Some examples of recent updates designed to break well-known ASLR bypasses are showed in the following table.

MS BULLETIN

ASLR BYPASS

REFERENCE

MS13-063

LdrHotPatchRoutine

Ref: http://cansecwest.com/slides/2013/DEP-ASLR%20bypass%20without%20ROP-JIT.pdf Reported in Pwn2Own 2013, works only for Win7 x64

MS13-106

HXDS.DLL (Office 2007/2010)

Ref: http://www.greyhathacker.net/?p=585 Seen used in-the-wild with IE/Flash exploits (CVE-2013-3893, CVE-2013-1347, CVE-2012-4969, CVE-2012-4792)

MS14-009

VSAVB7RT.DLL (.NET)

Ref: http://www.greyhathacker.net/?p=585 Seen used in-the-wild with IE exploits (CVE-2013-3893)

We were glad to see the return of these recent ASLR updates in two recent attacks: the Flash exploit found in February (CVE-2014-0502) in some targeted attacks and a privately reported bug for IE8 (CVE-2014-0324) just patched today. As showed from the code snippets below, the two exploits would not have been effective against fully patched machines with MS13-106 update installed running Vista or above.

Solutions for non-ASLR modules

The two exploit codes above shows another important lesson: even if Microsoft libraries are compiled natively with ASLR and even if we work hard to fix known ASLR gaps for our products, there are still opportunities for attackers in using third-party DLLs to tamper the ASLR ecosystem. The example of Java 1.6.x is a well-known case: due to the popularity of this software suite and due to the fact that it loads an old non-ASLR library into the browser (MSVCR71.DLL), it became a very popular vector used in exploits to bypass ASLR. In fact, security researchers are frequently scanning for popular 3rd party libraries not compiled with /DYNAMICBASE that can allow a bypass; the following list is just an example of few common ones.

3rd PARTY ASLR BYPASS

REFERENCE

Java 1.6.x (MSVCR71.DLL)

Very common ASLR bypass used in-the-wild for multiple CVEs NOTE: Java 1.7.x uses MSVCR100.DLL which supports ASLR

DivX Player 10.0.2Yahoo Messenger 11.5.0.228AOL Instant Messenger 7.5.14.8

Ref: http://www.greyhathacker.net/?p=756 (not seen in real attacks)

DropBox

Ref:http://codeinsecurity.wordpress.com/2013/09/09/installing-dropbox-prepare-to-lose-aslr/ (not seen in real attacks)

veraport20.Veraport20Ctl Gomtvx.LauncherINIUPDATER.INIUpdaterCtrl

Ref: KISA report http://boho.or.kr/upload/file/EpF448.pdf(seen in-the-wild with CVE-2013-3893)

As noted at beginning of this blog, Internet Explorer 10/11 and Office 2013 are not affected by ASLR bypasses introduced by 3rd party modules and plugins. Instead, customers still running older version of Internet Explorer and Office can take advantage of two effective tools that can be used to enforce ASLR mitigation for any module:

  • EMET (Enhanced Mitigation Experience Toolkit): can be used to enable system-wide ASLR or “MandatoryASLR” selectively on any process;

  • “Force ASLR” update KB2639308: makes possible for selected applications to forcibly relocate images not built with /DYNAMICBASE using Image File Execution Options (IFEO) registry keys;

Conclusions

ASLR bypasses do not represent vulnerabilities, since they have to be combined with a real memory corruption vulnerability in order to allow attackers to create an exploit, however it’s nice to see that closing ASLR bypasses can negatively impact the reliability of certain targeted attacks. We encourage all customers to proactively test and deploy the suggested tools when possible, especially for old programs commonly targeted by memory corruption exploits. We expect that attackers will continue increasing their focus and research on more sophisticated ASLR bypasseswhich rely on disclosure of memory address rather than non-ASLR libraries.

- Elia Florio, MSRC Engineering

Related news

CISA Adds Twilio Authy and IE Flaws to Exploited Vulnerabilities List

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has added two security flaws to its Known Exploited Vulnerabilities (KEV) catalog, based on evidence of active exploitation. The vulnerabilities are listed below - CVE-2012-4792 (CVSS score: 9.3) - Microsoft Internet Explorer Use-After-Free Vulnerability CVE-2024-39891 (CVSS score: 5.3) - Twilio Authy Information Disclosure

The March 2014 Security Updates

This month we release five bulletins to address 23 unique CVEs in Microsoft Windows, Internet Explorer and Silverlight. If you need to prioritize, the update for Internet Explorer addresses the issue first described in Security Advisory 2934088, so it should be at the top of your list. While that update does warrant your attention, I want to also call out another impactful update.

Fix it tool available to block Internet Explorer attacks leveraging CVE-2014-0322

Today, we released Security Advisory 2934088 to provide guidance to customers concerned about a new vulnerability found in Internet Explorer versions 9 and 10. This vulnerability has been exploited in limited, targeted attacks against Internet Explorer 10 users browsing to www.vfw.org and www.gifas.asso.fr. We will cover the following topics in this blog post:

MS13-106: Farewell to another ASLR bypass

Today we released MS13-106 which resolves a security feature bypass that can allow attackers to circumvent Address Space Layout Randomization (ASLR) using a specific DLL library (HXDS.DLL) provided as part of Microsoft Office 2007 and 2010. The existence of an ASLR bypass does not directly enable the execution of code and does not represent a risk by itself, since

Assessing risk for the October 2013 security updates

Today we released eight security bulletins addressing 25 CVE’s. Four bulletins have a maximum severity rating of Critical while the other four have a maximum severity rating of Important. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment. Bulletin Most likely attack vector Max Bulletin Severity Max Exploit-ability Likely first 30 days impact Platform mitigations and key notes MS13-080(Internet Explorer) Victim browses to a malicious webpage.

MS13-080 addresses two vulnerabilities under limited, targeted attacks

Today we released MS13-080 which addresses nine CVEs in Internet Explorer. This bulletin fixes multiple security issues, including two critical vulnerabilities that haven been actively exploited in limited targeted attacks, which we will discuss in details in this blog entry. CVE-2013-3893: the final patch after Fix it workaround Previously, Microsoft released Security Advisory 2887505 and made available the Fix it workaround 51001 to provide earlier protection to all customers for an actively exploited security issue that was reported to us.

Microsoft Releases Security Advisory 2887505

Today we released Security Advisory 2887505 regarding an issue that affects Internet Explorer. There are only reports of a limited number of targeted attacks specifically directed at Internet Explorer 8 and 9, although the issue could potentially affect all supported versions. This issue could allow remote code execution if an affected system browses to a website containing malicious content directed towards the specific browser type.

msrc-blog: Latest News

Securing AI and Cloud with the Zero Day Quest