Browsers and app specific security mitigation. Part 1

This article is an introduction to a small cycle dedicated to security mechanisms designed to counter the successful exploitation of memory corruption class vulnerabilities in web browsers. As part of this cycle, we will look at what mechanisms and for what purpose are being implemented by browser developers, and talk about how they could or could still be circumvented.

If you are interested in the topic of application protection or how the developers of exploits overcome protection, welcome under cat.

Security mitigations

Somehow we have already raised a similar topic in our blog in the article “About flags in 0x41414141 times” .
Similar mechanisms can be divided into categories according to the level at which they work or are applied:

1. At the hardware level - (DEP, MPX, CFI, SMEP, SMAP, UMIP, ...).
2. At the level of the operating system - implemented by the creators of the OS. For example, SEHOP, ForceASLR. In the case of the Linux OS, it can still be executed as an additional patch (Grsecurity).
3. At compiler / linker level - stack cookie, SafeSEH.
4. At the application level:
   ')
   
   • Third-party - EMET, Malwarebytes Anti-Exploit, HitmanPro, PaX and similar implementations in various antiviruses;
   • Built-in - implemented directly in the source code of the application.

In fairness it should be noted that this division is conditional, and not always so categorically. For example, CFG (Control Flow Guard) in Windows OS requires the OS to support this mechanism, and the application itself is built with special flags. If at least one of the conditions is not met, the CFG does not fulfill its tasks.

Mechanisms can also be aimed at solving a specific problem:

1. Complicate (reduce the stability of technology)
2. Make impossible the work of any technology (the opposition of a specific technique)
3. Mitigate the effects (isolation from the rest of the system, sandbox)

We will not go into the story of the emergence of such mechanisms in this article, and just recommend that you familiarize yourself with the presentations:

• “Exploit Mitigation Improvements in Windows 8” from BlackHat USA 2012
• “WINDOWS 10 MITIGATION IMPROVEMENTS” with BlackHat USA 2016

App specific security mitigations

This series of articles will be devoted to the last category, the so-called. app specific security mitigations. The appearance of these mechanisms is due to the very functionality of the application and the peculiarities of its implementation, usually affecting or implementing its own memory manipulation abstractions: own VM, own heap manager, own scripting language, etc.

The most prominent representatives include:

• Browsers
• Document Editors (Word)
• Virtual Machines (JVM, Dalvik VM, ActionScript VM)

So, for example, at the level of modern OS, the mechanisms of protection of the same heap already exist, but due to the fact that the developers create an internal implementation, heap protection mechanisms against the OS, by and large, are not involved in the operation of the program itself. Internal implementation generates internal structures, connections between objects, algorithms, which the attacker aims at. Naturally, all this was originally created for convenience, simplicity and speed, but, as practice shows, subsequently begins to overgrow with various additional mechanisms designed to ensure security. Well, you should not forget about the functionality of such solutions, since it also has a special imprint on the security mechanisms being introduced.

Browsers

Since browsers are the brightest (and, probably, the most interesting) representatives of software implementing their own security mechanisms from exploiting memory corruption class vulnerabilities, we decided to focus on them in our research center. A series of articles will be devoted to: IE + Edge, Chrome and Firefox for desktop PCs running Windows on x86 / x64 architecture. The list of these mechanisms was taken from the Browser security mitigations against memory corruption vulnerability updated compilation: our friend Arthur Gerkis , for which many thanks to him.

In 2011, Accuvant LABS released the Browser Security Comparison: A Quantitative Approach document, but much of the water has flowed since that moment, and browsers have seriously changed. However, to get acquainted with this information is still not superfluous.

If we generalize the mechanisms considered by us in the future, we can designate several groups:

• prevent unintended execution of code or data
• prevention of problems associated with the lifetime of the object
• preserve the integrity of code, data or metadata
• address space information restriction
• sandbox restriction

Operating a widespread client software, including browsers or Adobe Flash, is a chain of vulnerabilities, techniques and approaches. Just look at a small selection of how they broke at pwn2own 2016:

For those who want to learn more about successful exploits for browsers, we recommend to pay attention to the performance of “$ HELL ON EARTH: FROM BROWSER TO SYSTEM COMPROMISE” ( presentation and whitepaper ) with BlackHat LasVegas 2016.

As you can see, even such “armored” programs successfully attack, bypassing all the defense mechanisms of both the OS and their own. As a result, researchers bypass a dozen security mechanisms — in fact, of course, fewer, since it strongly depends on the type of vulnerabilities used. For example, stack cookie does not manage with safeSEH, SEHOP, if the vulnerability is UaF - since the nature of the vulnerability is not related to the stack, and these mechanisms are not involved. The biggest threat to browsers is represented by vulnerabilities like use-after-free (UaF) - CWE-416 - everything here is due to the complexity of browsers. Therefore, it is not surprising that developers are working on the creation of protection mechanisms aimed at countering this type of vulnerabilities. The next point, which is also paid close attention (in terms of security) by the creators of browsers, is writing JIT (just-in-time) code. This is due to the fact that an attacker can use this code to locate his shellcode inside the JIT spray, which at the same time allows him to bypass both DEP and ASLR. Therefore, the developers and began to "tighten the screws" in this direction. We will also talk about this later.

It is important to understand that any attacker has certain goals, and he will follow them on the path of least resistance. For example, it is not always necessary for him to execute his own shellcode and be fixed in the system, gaining access to data from other applications. If this is not necessary, then there is no need to bypass the CFG and sandbox. At the same time, it is able to steal any data available / stored by the browser, or use its standard functionality, but for its own purposes (for example, changing data or changing browser settings).

RW primitive

Everything gradually goes to the fact that if an attacker has an RW-primitive (a vulnerability or a number of vulnerabilities that allow him to read and write to memory), all current protection mechanisms are bypassed.

Most often, this is realized due to:

• CWE-401 : Improve Release Memory Memory Reference ('Memory Leak')
• CWE-123 : Write-what-where Condition - write-what-where memory corruption of the primitive

Thanks to a memory leak, you can bypass memory randomization (ASLR), find what we need in memory, and thanks to the ability to write anything and anywhere, all you have to do is ask: “What do you need to rewrite to execute your code (shellcode)?” . Sometimes, it can be the desired address where the shellcode is located, the flag in memory (bypassing the check), the value of the token (to raise privileges in the system), etc.

It should be noted that the “Write-what-where” primitive is sometimes limited:

• Not controlled, what is written
• It is possible to write only NULL
• It is only possible to increment the value.
• Somehow the address range where we can write is limited

But even with such limitations, it is sometimes possible to carry out successful operation - it all depends on the application and the nature of the vulnerability. This is very well shown in the “Write Once, Pwn Anywhere” presentation from BlackHat USA 2014 in Internet Explorer.

To get acquainted with the power of the RW-primitive we give a number of examples:

• A great example of escaping the VirtualBox guest virtual machine, also thanks to the RW primitive.
• An example of exploitation in Silverlight (CVE-2016-0034)
• A great example for Linux
• Example [ 1 , 2 ] for Android
• Example [ 1 , 2 , 3 ] with the Windows kernel
• Browsers, of course, is no exception, but more on that later.

With this small selection I wanted to show one common and very powerful primitive in the operation of memory corruption vulnerabilities. It works for any browser, but finding an RW primitive is not so easy.

In a series of articles, we will look at more specific techniques for circumventing browser mechanisms.

Intermediate output

Vulnerabilities of memory corruption class were, are and will be and will continue to be exploited. The only thing with time is that everything becomes more complicated. And a lot depends on the nature of vulnerability. So on the compiler, OS, hope, but do not make it yourself.

PS Memory damage is good for an attacker, and logical vulnerabilities are just great or even web bugs like UXSS are always 100% reliable, and often cross platform.