Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Escaping the Chrome Sandbox Through DevTools- 1518

ading2210Posted 1 Year Ago
  • All untrusted code in Chrome, especially JavaScript on websites and within browser extensions, runs in a Sandbox. Practically, this means that the code is limited to the set of APIs instead of system calls. The raw Chromium Gui, called WebUI with the chrome:// URL protocol, can interface with the raw C++ code and are privileged sections that run outside a sandbox.
  • Being able to execute code within the chrome:// is usually game over with UXSS or some other bug. So, keeping this clean of malicious code is important to the security of the browser. With this knowledge, our story begins with looking at Enterprise Policies in Chromimum. These are a way for an administrator to enforce certain settings by devices owned by a school or company.
  • These policies are downloaded remotely to a JSON file then placed in /etc/opt/chrome/polices for usage. Since it's annoying to write these policies by hand, the developers created a policy testing WebUI page at chome://policy. In particular, it shows a list of provided policies, logs them and allows for exportation.
  • Oddly enough, you can't edit these policies. After some digging, they found an undocumented API for editing these. There is a feature check for whether it is possible to do this. Unfortantely, the check is faulty and always returns true for all builds of Chrome. At this point, we can only call the API from the privileged WebUI pages. Convincing somebody to copy JS into the console to execute is unlikely. So, how can we escalate this? Chrome extension sandbox escape!
  • The previous vulnerability had been reported in the devtools Chrome extension APIs. When calling chrome.devtools.inspectedWindow.eval(), the command is stored. If the tab is crashed then moved to another page, since as a WebUI page, it gets executed! The key to this attack was sending a request to eval before Chrome decides to disable the devtools API but while you are on a WebUI page. Classic race condition!
  • The author wondered if any variants of this vulnerability existed. They checked out the chrome.devtools.inspectedWindow.reload() function to try to do a similar thing. To the authors surprised, it worked! They could continually spam reload() requests with JavaScript and switch the tab to a WebUI page. This exploits a race condition between the communication of processes on killing the devtools API. Neat!
  • What's the worst thing that we can do with the chrome://policy page? The enterprise policies have a setting for Legacy Browser Support called Browser Switcher. This is meant to launch an alternative browser when a user visits specific URLs in Chrome that are not supported. In particular, the AlternativeBrowserPath can be used to execute an arbitrary command with arbitrary commands. This gives us a shell if we can execute it!
  • At this point, they have a shell but the race condition only works like 70% of the time with only a single chance to hit it. They were curious if the same revival trick from the original bug report would work. To their surprise, calling the debugger twice in a row results in a crash. At this point, the code is stored and will be launched upon recovery. However, it's at this point that we update the tab itself to a different location. Now, this is 100% reliable.
  • So, what's the fix? Funnily enough, Google had fixed this vulnerability originally then added a special case that exempted reload() from this patch. Originally, they just cleared all pending messages unless it was a reload.
    • Adding a loaderId on the renderer side. Ensures that a pending command is only valid on a single page.
    • Fix the feature flag for test policies.
    • Prevent the crash from happening in devtools. Idk how they did this though
  • I absolutely love this blog post. The bugs are not super complex, they have simple to understand code snippets yet it's still high impact. To me, this really shows up complexity opens up the attack surface is crazy ways.