Abusing sandbox domain to steal Chrome 0days

Today, I'll write about sandbox domain.

Sandbox domain is special domain meant to host untrusted (user uploaded) files. This make sure that untrusted files can not access sensitive information in trusted domains (with the help of SOP). So obviously, having XSS in sandbox domains wouldn't give attacker anything. Or is it? :)

I was browsing bugs.chromium.org one day, and noticed something. When attachment download link is clicked, it will follow below redirect.

https://bugs.chromium.org/p/chromium/issues/attachment?aid=attachment_id

⤵︎ Redirect

https://storage.googleapis.com/monorail-prod.appspot.com/16/attachments/Random_string

⤵︎ Download

And I could also render attachment instead of downloading them by adding "inline=1" parameter. If you noticed, the final domain where attachments are hosted is sandbox domain. It makes sense because those are uploaded by reporters. But some of those attachments are very sensitive because it includes 0day PoC of Chrome.

So I searched if I could host my HTML file in that sandbox domain, and surely I could. Luckily, I also had Chrome 0day attachment uploaded in bugs.chromium.org so I made PoC to steal attachment content from my uploaded HTML file, and it worked :)

<iframe src="https://bugs.chromium.org/p/chromium/issues/attachment?aid=attachment_id&inline=1" onload="alert(this.contentWindow.document.body.innerHTML)"></iframe>

So what attacker needed to do is simple. Go through recent attachments by incrementing "aid" parameter and see which "aid" requires authentication (which means, it's a security sensitive attachment). Gather all those aids and make loop to steal those attachments when rendered. And then, attacker needs to send that link via Chrome bug report so that Chrome security engineers who has access to all of the bugs open the link (which is their job).

After confirming that I can abuse this bug, I quickly reported it to Google. It took sometime for Google to triage the bug (since sandbox domain is usually out of scope), but Eduardo jumped into the case and everything was sorted out :) Overall, It was fixed in 5 days!

My thought on sandbox domain

Separating user contents from trusted domains is a good idea. But some user contents are sensitive. So putting everything together into same-origin sandbox might not be a good idea. Even if access to specific content requires a knowledge of random url path name, script-capable attacker with js file will be able to register Service Worker on sandbox domain. This means, all victim's request to sandbox domain is intercepted in the future if victim is infected by attacker's Service Worker. This idea is well spelled out here.

So, safer way to make sandbox domain is to isolate sandbox with subdomains (e.g. unique subdomain per user). This way, attacker's content won't have access to victim's content. In fact, this is how Google patched this bug.

Don't over trust sandbox domain!

Thanks for reading. hope you liked it :)