Register for this year’s #ChromeDevSummit happening on Nov. 11-12 in San Francisco to learn about the latest features and tools coming to the Web. Request an invite on the Chrome Dev Summit 2019 website

The Chromium Chronicle: Coding Outside the Sandbox

Episode 5: August 2019

by Ade in Mountain View

Chrome is split into processes. Some of them are sandboxed, which means that they have reduced access to the system and to users' accounts. In a sandboxed process, bugs that allow malicious code to run are much less severe.

The browser process has no sandbox, so a bug could give malicious code full access to the whole device. What should you do differently? And what's the situation with other processes?

sandbox diagram

All code has bugs. In the browser process, those bugs allow malicious code to install a program, steal user data, adjust computer settings, access content of all browser tabs, login data, etc.

In other processes, OS access is limited via platform-specific restrictions. For more information, see Chrome's sandbox implementation guide.

Make sure to avoid the following common mistakes:

rule of two

  • Don’t parse or interpret untrustworthy data using C++ in the browser process.
  • Don’t trust the origin a renderer claims to represent. The browser’s RenderProcessHost can be used to get the current origin securely.

Instead, use the following best practices:

  • Be extra paranoid if your code is in the browser process.
  • Validate all IPC from other processes. Assume all other processes are already compromised and out to trick you.
  • Do your processing in a renderer or utility process or some other sandboxed process. Ideally, also use a memory safe language such as JavaScript (solves >50% security bugs).

For years, we ran network stacks (e.g. HTTP, DNS, QUIC) in the browser process, which led to some critical vulnerabilities. On some platforms, networking now has its own process, with a sandbox coming.

Additional Resources

  • Chromium's Rule of Two: no more than two of unsafe data, unsafe code, and unsafe process.
  • Validating IPC Data: a guide on how to ensure that IPCs from the renderer process are not full of fibs and misrepresentations.
Was this page helpful?
Yes
What was the best thing about this page?
It helped me complete my goal(s)
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
It had the information I needed
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
It had accurate information
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
It was easy to read
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
Something else
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
No
What was the worst thing about this page?
It didn't help me complete my goal(s)
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
It was missing information I needed
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
It had inaccurate information
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
It was hard to read
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.
Something else
Thank you for the feedback. If you have specific ideas on how to improve this page, please create an issue.

rss_feed Subscribe to our RSS or Atom feed and get the latest updates in your favorite feed reader!