On Chromium and Practical Windows Sandboxing

  • Article

UPDATE 9/13/2008:  The authors of the Chromium whitepaper linked to below wrote to me the day after I wrote this post thanking me for the links to Dave's blog and they insisted that they had not seen his presentation at Blackhat nor were they aware of his blogs on sandboxing so it must be a coincidence that the two groups used the same approach for MOICE and Chrome.  They also mentioned that they have subsequently updated the whitepaper to cite his work at the end in the referrences section which was nice.  It has also been pointed out to me that Google bought GreenBorder however I do not believe that this is the technology described in the whitepaper on the Stanford web site and used by Chrome that I link to below - but I could be wrong - I know pretty much nothing about GreenBorder.
------------------------------------------ 

So tonight a friend sent me this URL which offers a bit more technical detail on how Google's new 'Chrome' browser implements its 'sandbox' for the rendering engine processes: https://crypto.stanford.edu/websec/chromium/chromium-security-architecture.pdf

If you read up on the sandbox you will discover that Google is doing essentially the following things:

  1. Using the CreateRestrictedtoken API and AdjustTokenPrivileges to lock down the token the rendering process is running with.
  2. Using a Job object to place limitations on what the rendering process can do
  3. Running the rendering process on a separate desktop to prevent window message abuse.

Hmmm . . . this all sounds familair . . . where have I read about this type of sandbox before?  Oh that's RIGHT . . . on David LeBlanc's blog:
https://blogs.msdn.com/david_leblanc/archive/2007/07/27/practical-windows-sandboxing-part-1.aspx <-- CreateRestrictedToken
https://blogs.msdn.com/david_leblanc/archive/2007/07/27/practical-windows-sandboxing-part-2.aspx <-- Job Object
https://blogs.msdn.com/david_leblanc/archive/2007/07/27/practical-windows-sandboxing-part-3.aspx <-- Locking down a process on a different desktop to prevent WM abuse.

Now obviously his blog posts are over a year old . . . Chrome just released today along with the whitepaper I linked to above (the create date on the PDF was 9/2/2008 so this doesn't appear to be something old that I'm just now reading) - but in the "references" section - I didn't see any acknowledgement of Dave's work on building the MOICE sandbox (which clearly seems to have given the Google Chrome team some inspiration?  Or perhaps great minds just think alike).  Dave also presented this at Blackhat last year I believe.

Having said all of that - this does appear on the surface to be a rather well thought out browser / sandbox . . . what I find interesting is how . . . "quaint" the new Chrome browser makes FireFox 3.0 look! :)  I mean FireFox 3.0 was touted for its "security" and is heavily hyped as being the most secure browser by people not grounded in reality.  In reality that browser offers even less protection / mitigation against web exploits than IE7 on Vista and of course it has had quite a few vulns in its short lifetime (9 CVEs so far?).  Now we have Chrome which seems to be over the top with respect to protection technology that Windows can offer - possibly even going above and beyond what we have planned for IE8? 

All I can say is - "dang". :)

So the only concerns I have left are:

  1. Does Google have an SDL?  Are they using any banned / dangerous Windows APIs?  Do they have any sort of automated code analysis that is occuring looking for defects as its checked in?  Are they compiling with the latest C compiler and opt-ing in to things like /GS, /SafeSEH, /NXCOMPAT, /DYNAMICBASE etc.?  Clearly they are open sourcing this - but are qualified eyeballs being paid to review the code and look for weakness or are they just assuming that someone will . . . for free?  They clearly seem to have threat modeled and pen-tested which is important - but at the same time they seem to have started from an older version of WebKit which Apple has already patched in a recent Safari build . . . this causes some concern.
  2. How strong is the sandbox?  Will catastrophic jail breaks be discovered that are challenging or architecturally impossible to fix rendering them useless against some future Metasploit module? :)

I for one don't run FireFox 3.0 . . . I don't consider it even a worthy challenger (though it sure is fast) to IE7 let alone IE8 (due to lack of protection / mitigation technologies, the vuln counts etc.), but I AM going to install Chrome and give props to the folks over at Google for impressing me - this is definitely no "Google Safari 3" or "Google FireFox 3" like I was expecting. :)