Vulnerabilities / Threats
8/23/2011
11:25 AM
50%
50%

Google Patches Critical Chrome Bug

Chrome browser update includes patches for 11 vulnerabilities, including several discovered by Google bug bounty winners.

10 Essential Google+ Tips
Slideshow: 10 Essential Google+ Tips
(click image for larger view and for slideshow)
Google released a new version (13.0.782.215) of its Chrome browser Monday that includes patches for 11 vulnerabilities. Nine of the vulnerabilities are rated as being of "high" severity, while one is "medium." The other, meanwhile, is "critical," which is Google's ranking for the most severe vulnerabilities found.

That bug is the sixth critical vulnerability in Chrome discovered in 2011 and relates to "memory corruption in vertex handing"--code that handles three-dimensional rendering--in the Windows version of Chrome. Credit for discovering the bug was given to Michael Braithwaite, a senior engineer at Turbulenz, and it earned him $1,337 from Google.

According to the Google Chromium blog, Michel Aubizziere (aka "miaubiz"), a regular Google bug bounty winner, found two new bugs, both rated high severity, earning him $2,000 in total. He also independently verified a third bug of high severity that had been found by Google.

Other bugs, meanwhile, involved "integer overflow in uniform arrays," buggy PDF memory handling in Chrome (Linux only), and various use after free errors.

All told, $8,000 in related bug bounties were paid out for nine bugs; two had been discovered by Google's own researchers. The current payout is less than the previous record of $17,000, which was paid out earlier this month for a prior release of Chrome.

Do bug bounties work? Google seems to think so. Based on the success of its cash-for-Chrome-flaws rewards program, Google last year extended the bug bounty program to cover any of its Web applications that handle sensitive user data.

Arguably, bug bounties socialize coordinated disclosure policies (previously known as "responsible disclosure") by giving security researchers incentives--cash, recognition--to help vendors patch bugs in their products.

Interestingly, Google's public disclosure of bugs discovered by its own employees isn't an industry standard practice. Notably, many vendors forego assigning a CVE identifier--referring to the widely used list of common vulnerabilities and exposures maintained by MITRE. According to the CVE website, the list "aims to provide common names for publicly known problems," in part to make it easier to share information about any given vulnerability.

In a blog post, Carsten Eiram, chief security specialist at vulnerability information provider Secunia, said that companies should always disclose bugs they've found, rather than performing a "silent fix," or in Microsoft-speak, treating it as a "variant," that gets patched but not detailed publicly.

"A software vendor should never silently fix vulnerabilities regardless of these being internally discovered or not; it is unethical and a disservice to customers," he said. "Vulnerability fixes should be clearly listed and, as such, become public and should be assigned a CVE identifier. Any public vulnerability should be assigned a CVE and all vulnerabilities should be made public."

He said that whenever MITRE becomes aware of a bug, it will assign it a CVE, regardless of whether or not the vendor has acknowledged the flaw. "This fact debunks the statement that there is no need for a software vendor to assign a CVE for an internally discovered vulnerability or similar," he said.

Eiram's comments came in response to a recent blog post from Brad Arkin, senior director of product security and privacy at Adobe. Arkin was responding to criticism that Adobe was undercounting the number of vulnerabilities discovered in its products. According to Arkin, "any bug identified by Adobe engineers and resolved as part of the Adobe Secure Product Lifecycle (SPLC) is not assigned a CVE."

At a full-day virtual event, InformationWeek and Dark Reading editors will talk with security experts about the causes and mistakes that lead to security breaches, both from the technology perspective and from the people perspective. It happens Aug. 25. Register now.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading December Tech Digest
Experts weigh in on the pros and cons of end-user security training.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-5426
Published: 2014-11-27
MatrikonOPC OPC Server for DNP3 1.2.3 and earlier allows remote attackers to cause a denial of service (unhandled exception and DNP3 process crash) via a crafted message.

CVE-2014-2037
Published: 2014-11-26
Openswan 2.6.40 allows remote attackers to cause a denial of service (NULL pointer dereference and IKE daemon restart) via IKEv2 packets that lack expected payloads. NOTE: this vulnerability exists because of an incomplete fix for CVE 2013-6466.

CVE-2014-6609
Published: 2014-11-26
The res_pjsip_pubsub module in Asterisk Open Source 12.x before 12.5.1 allows remote authenticated users to cause a denial of service (crash) via crafted headers in a SIP SUBSCRIBE request for an event package.

CVE-2014-6610
Published: 2014-11-26
Asterisk Open Source 11.x before 11.12.1 and 12.x before 12.5.1 and Certified Asterisk 11.6 before 11.6-cert6, when using the res_fax_spandsp module, allows remote authenticated users to cause a denial of service (crash) via an out of call message, which is not properly handled in the ReceiveFax dia...

CVE-2014-7141
Published: 2014-11-26
The pinger in Squid 3.x before 3.4.8 allows remote attackers to obtain sensitive information or cause a denial of service (out-of-bounds read and crash) via a crafted type in an (1) ICMP or (2) ICMP6 packet.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Now that the holiday season is about to begin both online and in stores, will this be yet another season of nonstop gifting to cybercriminals?