Practical Sandboxing on the Windows Platform

Transcription

1 A TECHNICAL WHITE PAPER for the Black Hat Briefings, Europe 2011 Verizon Business Threat & Vulnerability Management EMEA Practical Sandboxing on the Windows Platform An assessment of the Internet Explorer, Adobe Reader and Google Chrome sandboxes Abstract By Tom Keetch This paper will discuss the design and implementation of three products applying sandboxing techniques that comprise Microsoft s Practical Sandboxing methodology; Protected Mode Internet Explorer, Adobe Reader X and the Chromium project. The paper highlights current limitations in these sandbox implementations, including underlying problems with the Microsoft platform itself in respect to sandboxing which increase the likelihood of sandbox escape. This paper is an expansion on work documented in my previous whitepaper Escaping from Protected Mode Internet Explorer. Introduction...2 A model for evaluating exploit mitigations...2 The Practical Sandboxing methodology...5 Restricted User Access Tokens... 5 Restricted Job Objects... 5 Window Station Isolation... 6 Desktop Isolation... 6 Mandatory Integrity Control... 6 Generic attacks against Practical Sandboxing implementations...6 Kernel Interface Exploits... 7 Socket-Based Attacks... 7 Handle Leaks... 7 Base Named Object Namespace Squatting... 8 Null DACLs... 9 Practical Sandbox Implementations...10 Protected Mode Internet Explorer Adobe Reader X Chromium Assessing Practical Sandboxing Implementations...11 Protected Mode Internet Explorer Adobe Reader X Chromium Discovered Issues...14 Protected Mode Internet Explorer Adobe Reader X Chromium Conclusions...15 Recommendations...16 Guidance for Application Vendors References...17

2 Introduction The number of browser and other client-side remote code execution exploits has grown significantly in recent years; the increasing complexity of web browsers and third-party extensions exposes a large attack surface to potential attackers. There is also an increased awareness of zero-day attacks, against which users currently have little protection with monolithic browser and document viewer implementations. [1] Vendors have therefore created more modular implementations which will allow individual components to be sandboxed using operating system primitives and rely on a relatively small application kernel, or trusted broker, and a secure inter-process communication (IPC) mechanism to interact with the rest of the system. In this way, sandboxes can be used to provide defence-in-depth protection against un-patched or unknown vulnerabilities in rendering engines. [2] The Microsoft Windows platform provides a number of security mechanisms which can be combined to create a user-space sandbox implementation. These mechanisms combined form the Practical Sandboxing methodology, [3] [4] [5] which provide the basis of three different sandboxes which will be considered in this paper: Protected Mode Internet Explorer [6] Adobe Reader X [7] Chromium (the basis of Google Chrome) [8] Also, future sandbox implementations such as for the Firefox browser will likely use this same pattern. [9] Microsoft Office 2010 Protected View also uses a sandbox implementation, [10] but these two sandboxes are not considered in this paper. In this year s Pwn2Own exploit writing competition, the winner of the Internet Explorer component must also show sandbox escape. [11] I think this is indicative of the level of acceptance that sandboxes have achieved and that they are here to stay. The aim of this paper is to highlight strengths and weaknesses of these sandbox implementations and to evaluate their effectiveness and, in order to evaluate sandboxes; a simple model is introduced in the next section. A model for evaluating exploit mitigations The central premise of this model is that an attacker will only attack a system if the perceived value of the system is greater than the estimated cost of a successful attack. Also, each potential attacker has a number of potential targets and the one with the greatest pay-off will be selected, so applications might seek to be secure enough in the face of competitors. In this model, the cost of an attack depends on the availability and reliability of exploit code and the ease with which additional vulnerabilities can be found. In the example of sandbox

3 escape, the attack may have two components: one exploit to execute code within the sandbox and another exploit to escape the sandbox. One strategy for exploit mitigations is therefore to increase the cost of the initial attack. This is what is achieved, though with variable success, when DEP and ASLR are used to protect an application. [12] [13] Remote code execution attacks are still possible, but the level of skill and knowledge required of an attacker is higher, and additional weaknesses are required for exploitation. [14] The value of a target is the value of the assets for which successful exploitation will provide access. In the context of web browsers, the number of users is a key factor and Internet Explorer currently has a large portion of the market, making it an extremely high-value target. To decrease the value of the target, one option for would be to decrease the value of assets accessible from the target application. This is where sandboxes are useful, because they place the most exposed parts of the target application in a separate protection domain to that of the user and provide the target application with a minimal level of access to a user s assets. Therefore, our hypothetical attacker has several options for how far to progress an attack. They can compromise the sandboxed process and gain access to a limited set of assets, or they can continue the attack to gain full user privileges, or full system privileges. For an attack to continue, the marginal value of the compromised assets must exceed the marginal cost of further attack. This can be represented in graph form as below. The three graphs below plot four different scenarios for the cost of a two-stage attack against the pay-off for success, the x=y axis represents the break-even point for the attacker in this model. When the plotted points lie below and to the right of the x=y axis, the cost of attack is greater than the expected value, when it is above and to the left of this axis, the attack becomes economically viable as developing the attack is expected to be less expensive than the expected pay-off of a successful attack. The scalability of exploits means that the development of drive-by download exploits for browsers is normally a profitable enterprise for

4 criminal gangs. [15] The cost of an attack can also be though of as the time taken to find a vulnerability and develop an exploit. Graph (a) shows a safe system, the cost of attacking the system always exceeds the value of the target to the attacker. Graph (b) shows an unsafe system. The target s value to an attacker exceeds the attackers investment in the attack, regardless of whether one or both stages of the attack are conducted. There are two sub-cases, one where the return on investment ratio is better (b.i) when bypassing the exploit mitigation, and one where the return on investment is worse (b.ii). Graph (c) shows the use of an ineffective exploit mitigation technique, the cost of attack is not significantly increased. Graph (d) shows the use of an effective exploit mitigation technique, the cost of attack is significantly increased to the point that it is no longer viable. As attackers and defenders both mature and evolve, they will increasingly respond to market forces and seek to maximise profit and return on investment. Profit in this sense may not be monetary in nature, especially where state actors are involved. This model has been presented to try and frame the significance of the findings in this paper; the aim is to show how and when existing mitigations are ineffective within this model. To be effective, sandboxes must lower the value of existing exploits and bypassing the additional restrictions should be prohibitively expensive for attackers.

5 The Practical Sandboxing methodology The Practical Sandboxing methodology originated at Microsoft and consists of the following components: [3] [4] [5] Restricted user access tokens Restricted Job objects Window Station isolation Desktop isolation Mandatory Integrity Control (Vista and later) The use of Mandatory Integrity Control (also known as Integrity Levels ) is optional, allowing the methodology to be effective on Windows XP. [16] Restricted User Access Tokens A restricted user access token, is any token that is returned by CreateRestrictedToken(). In the context of Practical Sandboxing, the token is based on the user s normal token, but with every group set to Deny-only SIDs and all privileges removed from the token. A Deny-only SID is used instead of just disabled SID because they guarantee a more restrictive token. The restricted tokens still identify a process as belonging to a user and a session, but most or all of their group memberships which granted them access to resources have been stripped. A restricted token is effective in limiting access to any object protected by a Discretionary Access Control List, but other access control mechanisms are in place, for which other mechanisms are needed for properly sandboxing a process. One of these mechanisms is Job object restrictions. Restricted Job Objects Job Objects were introduced in Windows 2000 and allow groups of processes to be managed as a single entity. They also allow certain restrictions to be placed on processes which are not possible using restricted user access tokens. The restrictions that are relevant for Practical Sandboxing are: JOB_OBJECT_LIMIT_ACTIVE_PROCESS o Limit the number of processes in the job, if the limit is one, then no child processes can be created. JOB_OBJECT_UILIMIT_DESKTOP o Prevent job processes from creating or switching to desktops. JOB_OBJECT_UILIMIT_DISPLAYSETTINGS o Prevent processes from tampering with the user s display settings. JOB_OBJECT_UILIMIT_EXITWINDOWS o Prevent a process from logging a user off or initiating system shutdown. JOB_OBJECT_UILIMIT_GLOBALATOMS o Prevent access to the Global Atom Table. JOB_OBJECT_UILIMIT_HANDLES o Prevent access to USER handles belonging to processes in other jobs. JOB_OBJECT_UILIMIT_READCLIPBOARD o Prevent read access to the clipboard. JOB_OBJECT_UILIMIT_WRITECLIPBOARD o Prevent write access to the clipboard JOB_OBJECT_UILIMIT_SYSTEMPARAMETERS o Prevent write access to system parameters such as the desktop background, accessibility and other UI related settings. By default, processes assigned to a Job, cannot leave a job and therefore are subject to the limitations of the job for its lifetime. [17] All of the resources to which the Job object restrictions apply, are resources which are associated with a Window Station and which are otherwise available to all processes sharing a Window Station. Window Stations themselves are protected by Discretionary Access Control Lists, so these restrictions are not necessary to isolate processes using different Window Stations from one another.

6 Window Station Isolation Each process is assigned to a Window Station which contains one or more Desktop objects, a Global Atom Table, USER objects, a clipboard and various settings. By assigning a broker process and its target process to separate Window Stations, the two processes can be further isolated from one another, since they no longer share these resources. As described above, Job object restrictions can be used to implement approximately equivalent levels of isolation. Desktop Isolation Each thread is assigned to a desktop and each thread on a Desktop is capable of sending Windows Messages to any other thread on the same Desktop. Threads can also install hooks in processes which have threads on the same Desktop, which causes a user specified DLL to be loaded into other processes. For these reasons processes with threads on a specific Desktop were regarded to be in the same security context. When a more privileged process had a thread on a Desktop, other processes would be able to inject code into that privileged process and elevate privilege, either though installing hooks, or through Shatter Attacks. To fix this problem, Microsoft introduced UIPI restrictions. On Vista and later, processes sharing a Desktop are also isolated by Mandatory Integrity Control, so that lower integrity processes can not inject code into higher integrity processes such as administrator-elevated processes and native NT services. Mandatory Integrity Control Mandatory Integrity Control, also known as the Integrity Levels mechanism, was introduced in Windows Vista. It layers on an additional level of access control, in part, to prevent access to objects with empty Discretionary ACLs (which always allow full access to an object). As described above, Mandatory Integrity Control also supplements UIPI to provide isolation between threads in different processes residing on the same Desktop to prevent Shatter Attacks and hook injection. A more detailed analysis of Mandatory Integrity Control can be found in my previous whitepaper. [18] Generic attacks against Practical Sandboxing implementations There are a number of generic attacks which have been identified in this and previous research that can be used to escape sandboxes using the Practical Sandboxing methodology. Since the broker process is intended to regulate interaction between the sandbox target process and the rest of the system, the broker functionality and supporting IPC mechanism are an obvious source of vulnerabilities which will allow sandbox escape. But for the purposes of this research, the broker interfaces are assumed to be secure. Other privately commissioned research, by Azimuth Security (for Google) and isec Partners (for Adobe) has focussed on these interfaces, but my research focussed on attacks relevant to all implementations. The generic attacks detailed in this section are: Kernel Interface Exploits Socket-based attacks Handle Leaks Base Named Object Namespace Squatting attacks Null DACLs (Windows XP Only)

7 Kernel Interface Exploits A number of kernel interfaces are available to all users and do not differentiate between sandboxed processes and normal user processes. Therefore, local privilege escalations such as these are an obvious sandbox escape vector. Previous research presentations such as There's a party at Ring0, and you're invited by Tavis Ormandy and Julien Tinnes discuss the increasing relevance of local privilege escalations via the kernel in light of the increasing prevalence of application sandboxes. [19] However, even without sandbox-escape as a goal, local privilege escalation vulnerabilities are still of great interest, especially in multi-user environments such as terminal server and Windows domain-joined workstations. Being higher-value exploits, we can assume that they will be rarer (and therefore represent a higher cost) as more effort has been expended in finding and fixing these vulnerabilities. However, local kernel exploits do not have to evade the same number of exploit mitigation techniques, as these generally are implemented in user-mode only with no kernel-mode equivalents. Socket-Based Attacks A well-known and acknowledged limitation of the Practical Sandboxing methodology is that it does not limit access to network sockets. The only limitations are enforced by a host-based firewall. Host-based firewalls, such as the firewall shipped by Microsoft as part of the Windows operating system, typically allow outbound TCP connections to hosts in the local subnet. This would allow a compromised application to attack network services accessible only from the local machine (e.g. via the loopback interface) or only accessible from hosts on the local network, as opposed to the open internet where the original attack originated from. Again, as with local privilege escalation vulnerabilities, network based attacks are normally of significant value outside of the context of sandbox-escape. Handle Leaks Once the operating system grants access to a securable object, it passes an opaque handle back to the requesting process. This handle is granted a set of access rights and the handle can be used for any operation for which access has been granted without any further access control. Normally, if a sandboxed target process does not have the access rights to open an object directly, the broker process will open the object on behalf of the target on the condition that the broker s policy is configured to allow it. However, for a number of reasons, sandboxed targets often have access to open handles which refer to objects for which they should not be given access. This may be due to programmer error, limitations in the sandbox design, or due to unintended interactions with third-party DLLs. Once access is granted to a leaked handle, depending on the type of object that the handle refers to and the access rights granted to it, the handle may allow or facilitate a sandbox escape. The example of third-party DLLs is a problem specific to sandboxed processes which are initialised at a higher privilege level before transitioning to a lower privilege level (Adobe Reader X and Chromium). Initialisation of a sandboxed process at a higher privilege level frees the sandbox implementation from the complexities of the Windows PE loader, the behaviour of which is not well documented. This is in itself a sound design choice, but one which could have unintended consequences.

8 For example, if a third-party DLL (loaded during the sandbox target s initialisation) opens a handle to a privileged resource and does not close it, then that handle will be unintentionally available to all code running within the sandbox. The Chromium project has identified and black-listed a number of DLLs which when loaded into the sandbox, result in access violations and other errors, and so they are prevented from loading. However, DLLs not in this black-list may undermine the security of the sandbox. As a proof of concept, I created a global DLL which opened a file with write access and verified that the handle remained valid post-initialisation. The following table shows a selection of handle-leaks that directly allow sandbox escape if they refer to higher privileged objects: Handle Type Access Rights Process PROCESS_VM_WRITE && Process Thread Token PROCESS_VM_OPERATION PROCESS_DUP_HANDLE THREAD_SET_CONTEXT TOKEN_ADJUST_DEFAULT The following table shows a selection of handle-leaks that could allow sandbox escape if they refer to, or are shared with, higher privileged processes: Handle Type Section File Key Access Rights GENERIC_WRITE GENERIC_WRITE GENERIC_WRITE The above two tables provide generic attack vectors which are almost always only useful in a sandbox-escape scenario, therefore the cost of finding and using these types of exploits will be lower compared with local kernel exploits which, as was said before, have value in other scenarios. Another possibility is that a new thread is created during initialisation which is associated with a secondary (thread) token, this would be achieved through a call to ImpersonateSelf(). [20] Hijacking this thread would allow the same level of access as the primary (process) token at the time of the call to ImpersonateSelf(), which during initialisation may be the full rights of the user. Base Named Object Namespace Squatting Every process in a session shares a Local namespace and all processes share a Global namespace. In these kernel object namespaces, the following objects can be created: Mutants (Mutex) Semaphores Timers Events Sections (Memory mapped files and shared sections) Before Windows Vista, the vast majority of objects in the Local namespace belonged to processes running with the same privilege level. But now that less-trusted processes share a user s session and share the Local namespace, there is the possibility for sandboxed processes to interfere with applications running with normal user privileges, or even with elevated administrator processes (when UAC is enabled). As a result, the techniques in this section can be applied to UAC bypasses.

9 By creating an object in the Local namespace with the same name as an object to be created, the lower privileged process can gain full access to an object created by the higher privilege process. This potentially exposes the more privileged process to attack through an unexpected attack vector. Furthermore, such local exploits can more easily bypass many of the exploit mitigation technologies such as GS Cookies [21] and ASLR (which in turn defeats DEP). [13] [22] This named object squatting attack assumes that: A lower privilege process is running before the named object is created. The named object is created with a predictable name. This issue is particularly interesting, because for software running with normal user privileges on Windows XP, named object collisions (deliberate or accidental) in the local namespace were not security issues, because there would be nothing running in a lower privilege protection domain. Now Practical Sandboxes are being created, this is no longer true. Vulnerabilities of this type undermine the benefits of Practical Sandboxing because the cost of finding and using vulnerabilities of this type will be much lower than the cost of finding local kernel exploits and network-facing vulnerabilities. Shared Sections are the most interesting object type to squat on because of the increased likelihood of finding code execution vulnerabilities leading to sandbox escape. This lead me to write a simple shared section fuzzer, discussed later. In other situations where a shared section combined with a synchronization object such as an Event is used for IPC, the client and server interfaces handling IPC are exposed. This would allow otherwise off-limits functionality to be used. With regards to which named objects have predictable names, there is a common technique of appending a process identified (PID) to prevent and deter collisions. But it can be shown that the PID of a process about to created is highly predictable. [22] Null DACLs Securable object can be created with empty DACLs, which always grant full access to an object. On Vista and later, an additional Integrity Level check will deny access to the sandboxed process as its integrity level (Low) is lower than the default integrity level (Medium). However, on Windows XP, Objects with Null DACLs can be opened. This would allow the sandboxed process to attack applications sharing the object, or the object might be used directly to escape the sandbox just as with the exploitation of handle leaks. Null DACLs should not be confused with empty DACLs, the latter permit no access, except normally to the owner of the object. [23]

10 Practical Sandbox Implementations This section summarises the designs of the three different sandbox implementations being considered from a functional perspective. The impact of these designs on the security of the sandbox is considered later. Protected Mode Internet Explorer Protected Mode Internet Explorer is built around a feature called Loosely Coupled Internet Explorer (LCIE) which allows every browser tab to run in a separate process. When Protected Mode is enabled for a tab, the host process will run at low integrity (Vista and later) and most privileges are stripped from the user s token. The browser kernel acts as the broker and runs with full user privileges, exposing a Local Procedure Call (LPC) interface to low integrity callers. The low integrity tab process is wrapped by a compatibility shim which redirects failed API calls to the broker. In this design, un-trusted websites run at low integrity and more trusted websites run at medium integrity and the two are segregated from one another. This, combined with the compatibility shim maximizes compatibility with third-party in-process browser extensions. Outof-process browser extensions are configured to run at low or medium integrity. The low integrity browser process cannot launch processes at a higher level of privilege, so the medium integrity broker process launches new processes subject to a security policy configured in the system registry. Job object restrictions and other ingredients of the Practical Sandboxing methodology are not used. This design and the design of Mandatory Integrity Control have been documented by Microsoft. [6] Adobe Reader X The Adobe Reader X sandbox is based on the Chromium sandbox for Windows, [24] which is possible due to the BSD licence adopted by the Chromium project. [25] Again, a trusted broker runs with full user privilege with PDF documents running inside a sandbox making usage of most of the ingredients of the Practical Sandboxing methodology. As a closed source application, the best current description of the inner workings, beyond that which is implemented by the Chromium Sandbox, is a series of blog posts by Kyle Randolph of Adobe s ASSET team. [26] [27] [28] Chromium The Chromium project has extensive design documentation which describes its modular architecture and the inter-process communication framework used for communication between components. As with other implementations, a broker runs with the full privileges of the user fulfilling requests on behalf of other components. The broker process manages user data including passwords and user cookies, dispensed to processes that require them. The broker also interacts with the network, even though Practical Sandboxing does not limit network access. The Practical Sandboxing is provided by a framework that implements all of the ingredients of the methodology, so that any level of sandboxing can be applied to each browser process according to its level of compatibility with Practical Sandboxing. Compatible plug-ins can be hosted in restrictive sandboxes, whilst incompatible plug-ins (such as Adobe s Flash plug-in) can be hosted in processes with limited or no restrictions applied. This framework is re-used by the Adobe Reader X implementation of practical sandboxing. In order to allow processes to initialise correctly, the process starts running with the full privilege of the user before dropping privileges to sandbox itself. It is assumed that no malicious code will be able to enter the process before this point.

11 Assessing Practical Sandboxing Implementations A previous section discussed potential attacks which apply to all implementations of the Practical Sandboxing methodology. In this section, I will describe problems specific to each of the three different implementations. These differ from each other in which parts of the application are sandboxed and other design choices. All of the limitations detailed in this section are known and deliberate limitations, but in order to evaluate the different implementations, these limitations need to be understood. Specific pointflaws are detailed in the next section. Protected Mode Internet Explorer The limitations and weaknesses of the Protected Mode sandbox were covered in my previous whitepaper: Escaping from Protected Mode Internet Explorer. But I will summarise here for completeness. First of all, Microsoft does not regard the feature as a security boundary, that is to say that they make no claims about its effectiveness as a security feature. But this stance is not sufficient to diminish its value as an exploit mitigation feature. The principle limitation is that Protected Mode only protects the integrity of a user s data, not its confidentiality, so an exploit payload can still steal copies of a user s files and registry settings, but it cannot modify a user s files, or install malware on the user s machine. A second limitation is that only Mandatory Access Control is used to isolate the sandboxed process, so the restrictions of Job objects, Window Station isolation and Desktop isolation do not apply. This exposes applications outside of the sandbox, including the broker process, to a wide range of attacks which are prevented in other sandbox implementations. This also means that Protected Mode is not supported on Windows XP. A third and final limitation, is that not all web sites are rendered in Protected Mode. This results in the same code executing both inside and outside of the sandbox, facilitating a number of potential sandbox bypasses. Adobe Reader X Adobe Reader X is retrofitting a sandbox to a complicated product, so one would expect to see more weaknesses, than newer applications built from the ground up with a sandbox implementation in mind. In terms of generic Practical Sandboxing limitations, a major limitation of the sandbox is its inability to restrict network access for a process that, unlike a browser, does not require network access to function correctly. This is noted by Adobe. [26] Also noted by Adobe, is that like Protected Mode Internet Explorer, the sandboxed process has full read access to a user s files and registry settings. However, unlike Internet Explorer, this is due to the broker s security policy, not an issue of the restrictions applied to the sandboxed process. This policy is likely to become more restrictive in future versions. To achieve sandbox escape; Base Named Object Namespace squatting attacks could be used in conjunction with Internet Explorer shared section parsing issues to escape the Adobe Reader X sandbox, for more information refer to Discovered Issues. The most obvious and notable limitation of this Practical Sandboxing implementation is that Window Station and Desktop Isolation are not implemented. But many of the benefits of such isolation can be implemented through Job Object restrictions. But the following notable restrictions are not enforced:

12 JOB_OBJECT_UILIMIT_READCLIPBOARD JOB_OBJECT_UILIMIT_WRITECLIPBOARD JOB_OBJECT_UILIMIT_GLOBALATOMS Vulnerabilities exploitable through manipulation of the Global Atom table may also be used for escape from the Adobe Reader X sandbox. This also enables the possibility of clipboardbased attacks from the sandboxed PDF rendering engine. A compromised sandboxed process is able to steal clipboard contents and use the clipboard to attack other applications to try and escape the sandbox. By way of example, if a command line were to be copied from a text file (or a PDF) and pasted into a command shell, the sandboxed process could replace that command with a series of malicious commands, each followed by a carriage return. When the paste command is executed, the malicious command originating from the sandbox will execute with the full privileges of the user. But it is not only text that can be placed in the clipboard, data of many different types can reside in the clipboard and paste operations can trigger application-specific behaviour. Each of these applications will place undue trust in this data, making it an interesting avenue for sandbox escape. Protected Mode Internet Explorer may also be susceptible to clipboard-based sandbox-escape vulnerabilities. A by-product of not using a separate Desktop is that on Windows XP, where Mandatory Integrity Control is not available, it is not possible to prevent transient key loggers from operating. This limitation is noted by Adobe. [27] A limitation of the Adobe Reader sandbox, which may or may not be known to Adobe, is that it shares the Internet Explorer cookie store. This allows authentication cookies to be stolen and used to access authenticated web sessions, including those for internet banking sites. For more information refer to Discovered Issues. This could be mitigated by preventing network access. Chromium The Chromium project has been designed from the ground up to make use of the Practical Sandboxing methodology on Windows. [29] For this reason, the Chromium implementation is the strongest of the three implementations discussed in this paper. However, as acknowledged in the Chromium design documentation, they are reliant on the implementation of the underlying operating system. [29] For this reason, the Chromium sandbox is vulnerable to any generic attacks against the practical sandboxing mechanism including Base Named Object Namespace squatting and handle leaks from sandbox initialisation. Assessing the Chromium sandbox implementation in full could be a project in itself, so this assessment will not be a complete one, but will aim to cover the salient points and some interesting weaknesses. Mark Dowd has documented some details about the security of the sandbox from his security audit. [31] Within Chromium, rendering processes are fully locked down within the context of the supplied primitives; User access tokens are fully restricted, Window Station and Desktop isolation are implemented, all relevant Job object restrictions are enforced and the process runs at low integrity on Vista and later. There are of course, other types of process, summarised in the table below. At the time of writing, processes are either fully sandboxed, or not at all. All sandboxed processes share a single Window Station and Desktop. Process Type Broker Renderer Sandboxed No Yes

13 GPU Process Trusted Plug-in Un-trusted Plug-in No No Yes The GPU Process is intended to be sandboxed in a future release. [30] Assuming that sandbox escape is not possible, it should be considered what other resources are accessible to a compromised renderer process, which is the most likely process to be compromised by a remote code execution exploit. User cookies and passwords are stored in the broker process, but must be made available to renderer processes handling sites in the correct domain. There is naturally no security separation between sites rendered in the same process, so if a payload is able to get another site rendered by the same process, the browser s Same Origin Policy can be bypassed. Therefore, assuming sandbox escape is not achieved, an attacker can bypass the same origin policy instead, which is still a serious browser vulnerability. Two sites can be reside in the same process if one site places the other site in a HTML Frame, or if one page calls window.open() in JavaScript on another site, since the browser expects the two sites to be interaction and so places them in a single process for performance reasons. This behaviour contrasts with the behaviour of the (otherwise much weaker) Protected Mode Internet Explorer sandbox. In Internet Explorer, sites which are members of IE zones where Protected Mode is disabled are isolated from processes rendering un-trusted sites. This isolation is enforced by Mandatory Integrity Control as un-trusted sites are rendered in Low integrity processes and trusted sites are rendered in Medium integrity processes. The sandboxed rendering process can communicate with several other processes which are not sandboxed. The table below shows the potential targets and which messages are relevant. [31] Target Broker Trusted Plug-ins GPU Rendering Process IPC Message Type Prefixes ViewHostMsg_ PluginProcessHostMsg_ WorkerProcessHostMsg_ UtilityHostMsg_ GpuHostMsg_ PluginMsg_ NPObjectMsg_ WorkerMsg_ GpuChannelMsg_ GpuCommandBufferMsg_ IPC to plug-ins is implemented by wrapping plug-ins normal interface. In-process plug-ins traditionally used NPAPI which is wrapped by the IPC server. Since the NPAPI interface was previously only called by callers within the same process, the plug-in may not be resilient against malicious callers. Chromium currently does some validation of the parameters into NPAPI, but because the plug-in is a black-box to Chromium developers, the parameter validation is unlikely to be complete. This is evidenced by the existence of several crashes caused by Chrome s innocent use of NPAPI with Adobe Flash. [32] The NPAPI interface previously existed between two components in the same security context, now it is an interface between sandboxed and non-sandboxed code. Chromium could continue to add more validation, but hardening the NPAPI interfaces of plug-ins is a more practical solution, but some functionality is necessarily exposed the boundary and broader design changes are required in plug-ins.

14 As an example, the rendering process is able to send key and mouse events to the Flash plugin. By doing this, it should be possible to click on security dialogs instead of the user because Flash only uses a single UI Window to interact with the user. This would allow the renderer process to enable any functionality protected by user prompt such as enabling web cameras, microphones and hard-disk storage. Other plug-ins may similarly expose dangerous functionality which should not be available to the sandboxed process. Discovered Issues This section details apparent implementation flaws which were discovered in each of the sandbox implementations. However, implementation flaws in one sandbox can allow escape from another sandbox. For example, an Internet Explorer vulnerability was found which could be exploitable from inside the Adobe Reader X sandbox, allowing malicious code to escape the Adobe Reader X sandbox. The same is true from the Chromium sandbox, but it is less likely that Internet Explorer and Google Chrome would be running concurrently in a single user session. Time and effort invested in looking for sandbox-escape vulnerabilities was limited. In fact, to invest significant resources in this would defeat the point of this research, that is to find cheap and easy to discover vulnerabilities and weaknesses, which would undermine the protection afforded by browser sandboxes. Therefore, the discovered issues were uncovered with a modest effort by inspecting handles inside the sandboxes, fuzzing shared sections and exploiting design flaws. I think that focused vulnerability research would discover many more flaws with modest investment of resources. This research, whitepaper and slides had to be completed in a limited amount of time, so very little time was invested in vulnerability research. Protected Mode Internet Explorer Squatting on shared sections used by Loosely Coupled Internet Explorer and fuzzing the shared section parser resulted in three unique crashes. Two were just read-access violations with an unknown cause, but one of the crashes, the root cause of which has yet to be determines, resulted in a NX exception. The Instruction Pointer (EIP) points into the Internet Explorer heap and has taken a value which appears to have originated on the stack, suggesting stack corruption. This issue can most likely be exploited for code execution, allowing sandbox escape from any practical sandbox. The section associated with this vulnerability was called ie_lcie_main_<process_id>. This issue has been reported to the Microsoft Response Centre. There are also several other issues from my previous whitepaper [18] and Hack.LU presentation. [33] One of which is a bypass on a domain-joined workstation. The other allows a malicious IFRAME embedded in a trusted webpage to exploit un-sandboxed Internet Explorer processes. Adobe Reader X The Adobe Reader renderer process has access to the medium integrity cookie store, used by trusted Internet Explorer websites. This is most likely due to the initialisation of the WinInet module which happens before the lock-down of the sandbox. As a rendering process, access is not even required to the cookie store, so access to the trusted cookie store is also not required. In Chromium, the cookie store is held by the broker process. Also, the mapped Internet Explorer index.dat files for cookies, history and the browser cache are shared with the Protected Mode Internet Explorer broker, exposing the index.dat parser to memory corruption attacks. Again, this parser is not normally exposed to malicious inputs, so implementation flaws are more likely to be found than in network facing parsers. Lastly, a handle to an un-sandboxed process (AdobeARM.exe) is granted PROCESS_QUERY_INFORMATION access, which is more powerful than the PROCESS_QUERY_LIMITED_INFORMATION access which is normally granted to a lower

15 privileged process. This can be regarded as an information leak and so not useful in itself for sandbox-escape. Chromium No obvious implementation flaws were found in Chromium. This is probably due to the amount of security assessment effort that has been invested as a result of paid audits (Azimuth Security) and the Google Bug Bounty program. But the exposure of NPAPI interfaces is likely to be an interesting avenue of attack. Also, it is worth repeating that flaws outside of Chromium can be used to escape the Chromium sandbox as documented throughout this paper. One implementation flaw which came to light which is that sandbox rules differentiate between creating and opening kernel objects, but often that distinction was not enforced by the broker as the same Win32 API call is used for creating and opening kernel objects. To determine if the object already existed, GetLastError() must be called. Conclusions Every application making use of the Practical Sandboxing methodology is reliant on the underlying security of the Windows operating system for the security of its sandbox. But implementations of Practical Sandboxing are also reliant on other third party applications. The ability of sandboxes to limit the value of the resources available to an exploit payload running inside the sandbox was also limited to various extents. This in turn limits the effectiveness of the sandboxes as exploit mitigation techniques. In Protected Mode Internet Explorer confidentiality was not preserved, Adobe Reader X provides access to cookies for trusted web sites in Internet Explorer and Chromium allows the browser Same Origin Policy to be bypassed, giving access to cookies and auto-complete passwords. Each sandbox implementation was also hindered in its ability to make the marginal cost of sandbox escape vulnerabilities prohibitively expensive to find and exploit. This is because the security of the sandbox is reliant on the security of the underlying operating system and thirdparty applications. In some instances, these issues in third-party applications previously had little or no security impact until the introduction of Practical Sandbox implementations. However, each and every flaw or weakness detailed in this whitepaper is fixable, either by the vendors responsible for individual implementations or by Microsoft through changes to the operating system. The latter of which will require much longer to implement. Regardless of these findings, user-mode sandboxes are here to stay and can represent a valuable defence in depth mitigation to discourage the installation of malware through drive-by browser exploits and similar attacks. The modular implementations encouraged by browser sandboxing also improve browser reliability and extensibility with acceptable performance overheads. At the conclusion of this research, the following items could be interesting areas for further research, but which were not pursued further for lack of time: NPAPI Fuzzing (Chromium Sandbox escape) Clipboard-based attacks (Adobe Reader X and Protected Mode IE escape) Base Named Object Namespace squatting (universal sandbox escape)

16 Recommendations This section represents my own opinion about how the strength of sandboxing can be improved on the Windows platform. However, without greater insight into technical challenges, some of these recommendations will not be practical to implement. Finally, I will offer some practical suggestions to help software vendors bolster the security of practical sandboxes on Windows. My first recommendation is for software vendors to focus on making writing exploits expensive for attackers. A combination of DEP, ASLR, GS cookies and SafeSEH does this reasonably well, so vendors should redouble their efforts to make full use of these protections. But still only a single vulnerability is needed to exploit an application, use of these protections do little to dissuade a skilled and determined attacker. Secondly, sandbox implementations should not be weakened by third party code. To achieve higher levels of assurance in a sandbox, third party code should be prevented from creating additional attack surface to a sandboxed application. This attack surface may originate from inside the sandbox (such as in the example of third-party hook DLLs) or outside the sandbox (such as in the example of shared section squatting). To prevent third-party applications from weakening sandbox implementations, the sandbox must adequately isolate sandboxed code from un-restricted applications. Examples in this research showed that the Base Named Object Namespace is unnecessarily shared. Also, network access must be restricted, as network services running on local networks are generally far less robust and secure than their internet-facing equivalents. Finally, the value of assets available to sandboxed processes must be kept to a minimum. If the assets which interest an attacker are readily available without breaking out of the sandbox, then the security of the sandbox implementation itself becomes irrelevant. Guidance for Application Vendors Ensure all modules make use of existing exploit mitigation techniques, whether they are internet facing or now. Create named shared sections and synchronization objects with unpredictable names where possible. Avoid hooking processes running within sandboxes. Design browser extensions with sandbox limitations in mind. Assess existing applications to ensure they do not undermine exploit mitigation techniques, or sandboxing techniques. Apply the principle of limited privilege in all new components, especially libraries; this will result in more reliable, robust and future-proof code.

17 References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] aspx [11] [12] [13] [14] [15] [16] %e2%80%93-part-2-%e2%80%93-the-sandbox-process.html [17] [18] modeinternetexplorer_en_xg.pdf [19] [20] [21] [22] Fritsch-Bypassing-aslr-whitepaper.pdf [23] [24] [25] [26] design.html [27] %e2%80%93-part-2-%e2%80%93-the-sandbox-process.html [28] broker-process-policies-and-inter-process-communication.html [29] [30] [31] [32] +Pri+Area+Feature+Type+Status+Summary+Modified+Owner+Mstone+OS&cells=tiles [33]