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.
 |
Exploit code for CVE-2014-0502 (Flash) Unsuccessful attempt of ASLR bypass using HXDS.DLL fixed by MS13-106.NOTE: the code attempts also a second ASLR bypass based on Java 1.6.x |
 |
Exploit code for CVE-2014-0324 (IE8) Unsuccessful attempt of ASLR bypass using HXDS.DLL fixed by MS13-106. |
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