A pair of security holes whose proofs-of-concept were validated by BetaNews show that Google Chrome may not have been as thoroughly inspected as Google would have us believe. But isn't finding bugs and holes what beta testing is all about?

A beta test is not a product debut, at least not by definition. So the discovery of the first few serious security vulnerabilities in Google's Chrome shouldn't, in and of themselves, raise alarm bells. However, one may rationally wonder why a project that was in the works for at least two years, if not four, wasn't able to find these same security holes long before the independent researchers did.

Last week, we learned that a variant of the same security vulnerability that afflicted Apple's Safari for Windows two months ago also impacts the first Chrome beta. Although Webkit is the rendering engine for both products, architecturally speaking, this problem actually has nothing to do with rendering, but rather about how downloads are presented and handled.

Security researcher Aviv Raff has become particularly adept at spotting cross-site scripting vulnerabilities, and similar problems where one component is triggered to pass control to another component without appropriate controls in place. Last week's discovery is a classic Raff feat of juggling.

With Chrome, whenever a file is downloaded from a Web page, a control appears along the bottom left of a fresh status bar. It's part of Chrome, not the Web page, but many novice users may not know this. If the file is executable -- for instance, an .EXE file -- Windows Explorer will take note that you're trying to execute something downloaded from the Web. So here, Chrome is actually relying on the security mechanism Microsoft has already put in place.

But Microsoft's security mechanism doesn't extend to Java downloads, instead leaving that responsibility to Sun. So when the user downloads a .JAR file -- or rather, something that pretends to be a Java .JAR file, by virtue of the file extension -- Chrome's downloads bar executes it automatically. A software-based firewall such as ZoneAlarm can stop automatic execution, but without one of those, Chrome executes whatever was downloaded.

In BetaNews tests this morning with Chrome version 0.2.129.27, Raff's proof-of-concept placed a fake "free coupwns" download button at the bottom of Chrome's status bar. When we clicked on that, Java launched a Notepad application without any kind of warning or check to see whether the downloaded application had permission to launch code. In theory, it could have launched any code.

As anyone who uses a Google Toolbar with IE or Firefox already knows, Google's memory-resident automatic update application is particularly aggressive. In our tests, we've noted it can check for updates from five different sets of IP addresses as often as every half-hour. Chrome uses the same update application, according to our firewalls which, once the Toolbar updater is cleared for Internet access, enables Chrome's update as well.

This morning, Google distributed build 0.2.129.29, and some sources had been reporting that this build would include a fix to this problem. In BetaNews tests, the Raff security hole remained -- .JAR files are still executed without warnings or permission checks.

Raff suspects the Webkit rendering engine as contributing to the problem, though on his personal blog last week, also casts suspicion on the fact that patches of Chrome's source code appear to have been taken from a handful of open source projects (with attribution, of course), including Firefox. Perhaps some degree of security is lost in all the patching together; but another problem Raff suggests is that borrowing so many ideas from others may mean Google will leave it to those other sources to fix their problems first, before it fixes its own.

"They'll have to track all security vulnerabilities in those features, and fix them in Chrome too," Raff wrote. "This will probably be only after those vulnerabilities were fixed by the other vendors or were publicly reported."

Some other peculiarities we noted in our tests: Chrome's downloaded files bar doesn't appear to have any way to delete reference to a download that may have been accidental. You can open the thing, or you can tell Chrome you always want it to open files of the same type (which you'd think would be the problem in the first place), but you can't get rid of it until you get rid of the tab. Now, each tab has its own download bar; which means, if you've downloaded files from several sites during the same session, they won't all appear together along the bottom. This is apparently because all plug-ins and processes in Chrome are attributable to the tab, not to the browser; in other words, each tab is a separate process, and everything it triggers can't be shared by another tab. In this particular case, we can see where that could become a headache.

We also noticed, though, that when you click on the Show all downloads link in the lower right corner of the downloads bar, Chrome pulls up a separate page listing links to everything you've downloaded from all sites. Well, now you have a new and separate tab to think about. But when you click on the .JAR file in this page, now there's a safeguard that prevents the file from running unchecked -- a safeguard that did not appear in the downloads bar itself.

Subsequent to Raff's discovery last week, Vietnamese security research firm Bach Khoa (BKIS) uncovered a different Chrome problem, though not affecting files with .JAR extensions specifically. In its proof of concept, an attempt to save the contents of a page whose default name is way longer than 256 characters, can trigger code within that page to run unchecked.

BKIS said that, in systems running Windows XP Professional, Chrome could be triggered by its proof of concept to run Calculator, although it could have run any code. In BetaNews tests with build 0.2.149.27 on XP Pro SP3, we noted less destructive behavior: Chrome crashed, but it didn't run any unchecked code. After we upgraded to version 0.2.149.29, however, the browser behaved properly, giving us a default filename that was way too long, but then prohibiting us from saving the page under that name without shortening it first.