Re: Chrome, NoScript, and WebRequest API
by NickP » Thu Nov 24, 2011 4:26 am
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chrome’s design comes from the OP web browser from Univ. of Illinois. I independently invented a similar design around that time, although mine would’ve run on a Ring 1 microkernel or -1 hypervisor w/ capability-based security. (And NO STANDARD JAVA!) I loved running into the OP paper in 2008 & seeing that someone actually implemented some of these ideas.
http://www.cs.uiuc.edu/homes/kingst/Research_files/grier08.pdf
OP was designed to be secure from ground up. It’s very similar in nature to microkernel-based trusted OS’s with secure decomposition of applications. (The rest is an abstract of the abstract. OP is a browser security kernel and a collection of subsystems/components isolated into separate processes. Like a microkernel system, they communicate with message passing. The design allowed plugins to run safely. They also used formal (mathematical) methods to prove the address bar displays the correct address. They incorporated info-flow tracking for post-mortem analysis. They implemented it Java to avoid security issues so prevalent in C/C++ apps, even more beneficial due to the speed of HotSpot. Performance was only slightly slower than Firefox.
Sounds great. So, Google then invested money in OP, gave it a bunch of new features & created the most secure browser out there, right? Not quite. Instead, they created their sandbox technology & Chromium. Chromium is written in C++ (for decent reasons), making it much more vulnerable to attacks. The good news is they still use partitioning & message passing. Bad news: as of mid-2010, only renderer and “untrusted” plugins are sandboxed (Mark). “Trusted” plugins fully privileged by default (Mark). They’ve added tons of extra features, including overprivileged ones like WebGL. This increases the attack surface & bypass potential quite a bit. There’s some privacy issues. There were no formal methods used to prove claimed security properties hold & I have no idea if it still does info-flow tracking.
So, we essentially have a browser similar to OP on the surface with solid protection against system level attacks, inferior protection against web app layer attacks, privacy invasions & a good process for reducing vulnerability count (i.e. $$$ incentives). It’s a decent option for people who lack the will or technical capability to manage something like NS. It’s also decent for people who don’t value privacy or can take all the steps necessary to ensure Chrome surfs privately. However, a properly sandboxed FF running NS currently provides the best level of protection for the web user if they are taught how to use NS properly. The latter point isn’t as hard as it seems for many users.
I’ve avoided Chrome because Google isn’t following their motto. When Chrome was released, one of my hacker friends did an analysis of it. His packet sniffer showed that every single thing he typed into the address bar was sent to Google, even if he hit backspace. This was before Google Instant (probably a precursor feature). We found that ethically questionable as most people think something only happens when they hit enter. There were other issues. We and many media sources blasted Google for being silent about that. Over time, things have gotten to the point where many of these things can be disabled & Google is quite clear on what they’re doing:
On the sandbox technology. There’s been quite a few analyses on Google’s sandboxing method. These resulted in mixed opinions. There are two main problems: overprivileged components & dependency on OS to help it stay secure. The OS issues make it where I’m pretty sure state-level people have compromised Chrome already. The overprivilged components, WebGL, plugins, etc. may lead to compromises by black hats, especially combined w/ social engineering.
Mark’s analysis (pro-Chrome, mainly)
http://blog.azimuthsecurity.com/2010/05/chrome-sandbox-part-1-of-3-overview.html
Keetch on several sandboxes (paints darker picture)
http://media.blackhat.com/bh-eu-11/Tom_Keetch/BlackHat_EU_2011_Keetch_Sandboxes-WP.pdf
Keetch’s on practical sandboxing
http://www.slideshare.net/tkeetch/black-hat-eu-2011-assessing-practical-sandboxes
A LiveCD, carefully constructed browser VM, or proven 3rd party sandbox with Firefox/NS is more trustworthy at the moment. So, Chrome’s main strength is stopping common system-level attacks at the browser level. Alternatives are better in every area. Chrome continues to gain new features & inch closer to the capabilities of FF/NS. I always pick the most secure & useful option I can get. Right now, it’s not Chrome, but it might be in the future. They’ve invested more effort into security than any other group (except OP). I wish them luck on trying to surpass my alternatives in security: we benefit regardless.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJOzcWvAAoJEFvQ0aBVJJxWuN8H/RfO52uslvbcCgULw1N4vPf7
UZYYJASH3lVcMXUbYQYuudjOVO5dZINYJ7CiDQACytesn8a3pGDkSnihJJLBXhkA
WipP3fjBdKO4h1lQ11mgdaIUsrJrdn9j0UuXwdXBCeurbTGjeaXX61jDccC8A9xn
jsfMEu4j/QnTxHGg4bSvDhhW0Y/rN0jBeUzBn/tteUkNpC+gSpWLNSPmXj7aLbrS
E21GG3UfF+jmSougCZNKb2exF+lh8ccDtkXBQR17rgJkvvQ84/8a62i5nSgT7raU
oneMR2yFsawGUsSPSVXq3NyVpzFKwiGiiaroQqVq7oOtt2DWMIRv/yIjitHQocY=
=L4xw
-----END PGP SIGNATURE-----
here the whole thing.
Google Chrome vs. FX+NS; integral sandboxing vs. 3rd-party - InformAction Forums
Mod edit: fixed various url’s to make them clickable. Eric