Google Chrome uses a user-mode sandboxing technique to isolate and restrict the renderer process. The sandbox consists of a privileged broker process and one or more sandboxed target processes. The broker process specifies policies, spawns targets, and acts on their behalf by intercepting and evaluating Windows API calls. The sandbox aims to isolate targets and restrict their access to resources using techniques like restricted tokens, job objects, and separate desktops. However, the sandbox has some limitations in its ability to restrict network and USB access under Windows.

1. Google Chrome Security d0c_s4vage

4. Broker

5. broker - The IPC service is used to “ forward certain windows API calls from the target to the broker ” - Calls are evaluated against the policy - If all is good, calls are then executed by the broker , and results are returned over the same IPC - The interception manager should patch windows API calls that should be forwarded from the IPC to the broker

6. target - Renderers are always target processes

7. target

8. target - interceptions == hooks, how windows API calls are forwarded to the broker via IPC - broker chooses to run the calls or fail them - **NOTE** “ The interception + IPC mechanism does not provide security; it is designed to provide compatibility when code inside the sandbox cannot be modified to cope with sandbox restrictions.”

10. Sandbox Security - restricted token - windows job object - windows desktop object - integrity levels (Vista only [ and Windows 7?])

11. Sandbox Security - token - The renderer runs with this token: Regular Groups Logon SID : mandatory All other SIDs : deny only, mandatory Restricted Groups S-1-0-0 : mandatory Privileges None - Nearly all resources the renderer uses were acquired by the broker /browser and duplicated into the renderer process

12. Sandbox Security – token - Mounted FAT or FAT32 volumes “ The security descriptor on them is effectively null. Malware running in the target can read and write to these volumes as long it can guess or deduce their paths.” - TCP/IP “ The security of TCP/IP sockets in Windows 2000 and Windows XP (but not in Vista) is effectively null. It might be possible for malicious code in the target to send and receive network packets to any host.”

13. Sandbox Security – Job object - Forbid using SystemParametersInfo() - Forbid the creation or switch of Desktops - Forbid changes to the per-user display configuration - No read or write to the clipboard - Forbid Windows message broadcasts - Forbid using SetWindowsHookEx() - Forbid access to the global atoms table - Forbid access to USER handles created outside the Job object - One active process limit (disallows creating child processes)

14. Sandbox Security - desktop - processes with the same token and same job object are effectively in the same security context - BUT, programs that have windows in the same desktop are also in the same security context - WHY? Sending + receiving windows messages in the same desktop is not subject to security checks

15. Sandbox - desktop - Default windows XP has 2 desktops: logon screen and regular desktop - Sandbox creates another desktop for all of the target processes, so they can't snoop on what the user is doing elsewhere

16. Chrome Sandbox

17. Chrome Sandbox

18. Other Attack Surfaces - All network-related IO functions run on a separate thread in the main browser process (no sandbox) - recent DoS PoC via malformed ftp responses on exploit-db ( http://www.exploit-db.com/exploits/12011 ) - Issue where IO thread got hosed, crashed entire browser http://code.google.com/p/chromium/issues/detail?id=42267

19. Debugging Google Chrome Startup Options - --no-sandbox --single-process --wait-for-debugger-children --wait-for-debugger --js-flags=”--trace-exception --heap-stats” --js-flags="--h" --safe-plugins Chrome has its own symbol server: http://build.chromium.org/buildbot/symsrv

20. Google Chrome Security Issues - Chromium Security Bugs (not always latest) http://www.chromium.org/Home/chromium-security/chromium-security-bugs - Severity ratings http://sites.google.com/a/chromium.org/dev/developers/severity-guidelines - Security Issues by Rating - Critical: http://www.google.com/search?q=SecSeverity-Critical+inurl:chromium+inurl:issues+site:code.google.com - High: http://www.google.com/search?q=SecSeverity-High+inurl:chromium+inurl:issues+site:code.google.com - Medium: http://www.google.com/search?q=SecSeverity-Medium+inurl:chromium+inurl:issues+site:code.google.com - Low: http://www.google.com/search?q=SecSeverity-Low+inurl:chromium+inurl:issues+site:code.google.com

21. Ideas - Under Windows, there is no practical way to prevent code in the sandbox from calling a system service - Since use of Windows TCP/IP sockets (XP) isn't restricted, download exe, guess USB path ( F:, G:, H:, etc. on Windows), save to USB, create autorun.inf on USB - Find vulnerabilities in valid messages the renderer can pass to the broker ( check out this issue: http://code.google.com/p/chromium/issues/detail?id=29828)

22. Ideas - Insert hooks into UI events and snoop on whatever the user does in the same tab, even on different sites? - Could upload/download files to/from USB - Could be used as a pivot point (or a proxy) to be able to gain access into a network, since TCP/IP security “ is effectively null”

23. References Google Chrome Sandbox http://www.chromium.org/developers/design-documents/sandbox Windows Tokens http://msdn.microsoft.com/en-us/library/aa374909(VS.85).aspx What is a Token http://alt.pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsAToken.htm Windows Jobs http://www.microsoft.com/msj/0399/jobkernelobj/jobkernelobj.aspx