Chrome Performs Very Well at Hacking Competition

browsers At the CanSecWest conference each year they conduct a hacking competition (pwn2own).  Security professionals compete to get malware onto a machine faster than anyone else.  The contestant can pick the browser that they wish to attack.

At this year’s conference, every major browser including IE8, Firefox, and Safari were all hacked over a 3 day period.  The only browser which was not hacked was Chrome.  One of the winners of the contest had some interesting things to say about why Chrome was not hacked.

Chrome’s “sandbox” is not an accident; it was designed for this case.  Each web page runs in a renderer process, and that process has no privileges on the OS, so it cannot write to disk or talk to the network.  With all of the browsers being hacked, it’s fair to assume that hackers will find flaws in any browser.  Avoiding flaws is key, but the sandbox ensures that those flaws are contained to some degree.  It is much harder to do persist damage to the machine after the flaw has been exploited because the process can’t touch the network or disk.  While IE8 also uses multiple processes, it does not implement a sandbox, so it is vulnerable in similar ways to single process browsers.  Don’t get me wrong, the sandbox is not perfect, I’m sure someone will find an exploit.  But it does make Chrome harder to break into.  Plugins will be a vulnerability, as they cannot yet operate in a sandboxed environment (Flash, for instance, requires access to the OS in order to run).

More news:
IE8, Firefox, Safari Owned by 0-Day Vulnerabilities, Chrome Survives Intact
Chrome last browser standing after day one of Pwn2Own
Internet Explorer 8 Gets Hacked, Already

Javascript Faster and Slower

Several articles have been written about the latest in Javascript performance.  Here are some interesting points:

“Chrome 2 beats Safari 4 like a rented mule”

“The upshot: Chrome wins both tests handily, with Firefox in second place on Sunspider and Safari in second place on the V8 benchmark.”

Also interesting is that Firefox’s Tracemonkey Javascript engine may be falling behind.  Numerous articles have opined that Firefox 3’s ship date is in jeopardy due to Tracemonkey related bugs.  But new data also confirms that Javascript in Firefox 3.1 beta 3 is markedly slower than Firefox 3.1 beta 2.  The performance loss is palpable – Firefox lost 20% in performance from beta 2 to beta 3.  The problem may be that as the bugs have piled up in Tracemonkey, the fixes to ensure stability have eroded the performance gains initially boasted by the team.  It will be interesting to see Firefox’s final performance numbers when it ships out of beta.