In real life, when you take two species, a horse and a donkey, and mix them up you get a mule. In the browsers world, when you take a horse (Firefox/IE) and a donkey (Safari) and mix them up, you get – Google Chrome.
The new browser from Google tries to get the best from other browsers, but instead (well, at least in the current beta version), it seems to be doing quite the opposite.
The current beta uses an old version of WebKit - 525.13 - which is actually the same WebKit engine used by the old Safari v3.1. The current Safari version is v3.1.2, which fixed several critical issues, including the “blended threat” Carpet Bombing vulnerability. Google even mention that they use Safari v3.1 rendering engine in their own documentation (Thanks Yonatan Grabber for the information!)
On the other hand, Chrome borrowed (and modified) local resource files from the Mozilla project. And also, for some reason, in some cases there is an ActiveX plug-in loaded by Chrome, which might be an evidence of a capability of this browser to execute ActiveX controls.
I really wonder why Google have taken several features from other browsers and mixed them all together. Security wise, it’s very problematic.
They’ll have to track all security vulnerabilities in those features, and fix them in Chrome too. This will probably be only after those vulnerabilities were fixed by the other vendors or were publicly reported. It will put Chrome users at risk for a long time.
Back to the WebKit issue. I’ve created a proof-of-concept which demonstrates the automatic download vulnerability that was already fixed by Apple. This PoC will automatically download a JAR file and place it in the the downloads folder (there are reports that in some cases it will download it to the Desktop, as in Safari. In those cases, the Safari-Pwns-IE exploit can be easily converted to Chrome-Pwns-IE exploit).
Unfortunately, whenever Google Chrome downloads a file, it creates a download bar at the bottom of the page, which seems, for the untrained eye, as part of the page. The downloaded filename is displayed as a button, and the one click on this button will execute the file. If the file is an executable (e.g. .EXE, .BAT, etc.), Windows Explorer will show a warning that this file was downloaded from the Internet. In this case, Google Chrome does a good job by setting the Zone.Identifier in the alternative data stream.
However, as was mentioned by pdp at his great Black Hat talk this August, when Windows Explorer will try to execute a JAR file, it will automatically run the associated application, which in most cases is the JRE (Java Runtime Environment). JRE will not check the Zone.Identifier in the alternative data stream, and will execute the JAR file with no warning. JAR file, of-course, should be treated as any other executable file. This is again a sort of a "blended threat". Two small issues in different products, when blended together create a much larger problem.
In conclusion, Chrome seems to be a very nice and slick browser, but it is far from being secured as it is advertised by Google. It borrows several insecure features from other browsers, and it has its own security design flaws.