RSSGoogle Chrome grows up, joining the realm of everyday exploitability
By Scott M. Fulton, III | Published May 6, 2009, 4:00 PM
When the first public beta of Google Chrome arrived on the scene last September, it was given a rather rude welcome: It immediately faced the problem of averting a vulnerability. But this was only by virtue of the fact that it uses the open source WebKit rendering engine, whose exploitability had been discovered in Apple Safari just a few weeks earlier.
Now, however, Chrome is coming unto its own, but in a good way: Developers discovered some serious vulnerabilities in the browser apparently before malicious users did. In perhaps the most potentially serious dodged bullet, one of the Chromium project's lead contributors discovered a buffer overflow condition that occurs when a bitmap is copied between two locations in memory. The pointers to those locations may point to different-sized areas without any type or size checking, theoretically enabling unchecked code to be copied into protected memory and then potentially executed without privilege.
It's a typical buffer overflow situation. But in this case, the Google team was able to investigate and validate the claim, resolve the situation, and issue a test build for quality assurance testing within a mere five days. Still, the QA phase required another eight days before build 154.64 was released, and all during that time, the fact of Chrome's vulnerability was out in the open in Chromium's developers' forum.
While this isn't the first security-related issue to have affected Chrome since last September, it is probably the most critical. There is no indication that an active exploit of this issue was ever tried or is in the field.
It's pretty typical for companies not to publish what they know about exploits until they have a fix they can publish at the same time. The big DNS vunerablity was know about for more than six months before it hit the press and when it hit the press it was only a couple days away from being patched.
Score: 1
|What I'm more concerned about is not that vulnerabilities were found, but instead why the developers of Chrome had made the decision to patch the browser silently without the usual bells and whistles that most other companies do when their product needs to be done.
If Mac did that with Safari, or Microsoft did that with IE, there would be hell to pay.. But too many within the tech industry are applauding Google for this tactic, which certainly raises an eyebrow in this neck of the woods.
Score: 0
|You mean Apple; Mac is a computer line.
Firefox downloads the update automatically, unless you choose to change the options. Unfortunately, Google doesn't have an option for Chrome and that's the real problem.
If Apple did that people would probably cheer, because it meant that they'd fixed their software update process so it didn't require a system restart on Mac OS X.
Score: 0
|Actually there is a built in feature in all aspects of chrome during install that is installed with it. If you do a ctrl-alt-del look under processes you will see "GoogleUpdate.exe" this function is tied to a channel from the network. I'm attached to the DEV so it sends constant updates, vs beta which is less frequent. Unless you download the channel and change the setting you are on the stable build.
The updater is designed to push the build automatically when available, but to force an update goto the wrench, about google chrome.
Note, this feature will not work on Portable Chrome designed for USB drives.
Score: 0
|