Episode 5: by Ade in Mountain View, CA (August, 2019)
Previous episodes
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?
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:
- 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 RenderFrameHost 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.