Link

Google Chrome Addons Fingerprinting

Krzysztof Kotowicz has recently published the first part of a Chrome hacking series. In what went up mid-March, he provides the proof of concept code to ID the addons that users have installed. (The live demo – avoid if you’re particularly privacy conscious – is here.) There are various advantages to knowing what, specifically, browser users are running:

  • It contributes to developing unique browser fingerprints, letting advertisers track you passively (i.e. without cookies);
  • It enables an attacker to try and compromise the browser through vulnerabilities in third-party addons;
  • It lets websites deny you access to the site if you’re using certain extensions (e.g. a site dependent on web-based ad revenue might refuse to show you any content if you happen to be running adblock or Ghostery)

Means of uniquely identifying browsers have come and gone before, and this will continue into the future. That said, as more and more of people’s computer experiences occur through their browsers an ever-increasing effort will be placed on compromising the primary experience vector. It will be interesting to see if Google – and the other major browser vendors – decide to see this means of identifying customer-selected elements of the browser as a possible attack vector and consequently move to limit addon-directed surveillance.

Link

Security Bugs In Google Chrome Extensions

A piece that was authored last September, enumerating some of the security issues with Google Chrome Extensions. The authors:

reviewed 100 Chrome extensions and found that 27 of the 100 extensions leak all of their privileges to a web or WiFi attacker. Bugs in extensions put users at risk by leaking private information (like passwords and history) to web and WiFi attackers. Web sites may be evil or contain malicious content from users or advertisers.  Attackers on public WiFi networks (like in coffee shops and airports) can change all HTTP content.  We’ll show you how you can prevent attacks on your extension using Content Security Policy.

In a followup, the authors have published a full report (here) that outlines their methodology and identifies the extensions that, as of February 2012, remain unpatched.

Check out the article, and some of the other great pieces that they’ve published on security.

Link

Chrome Kills CA Revocation Checks

From Ars:

“While the benefits of online revocation checking are hard to find, the costs are clear: online revocation checks are slow and compromise privacy,” Langley added. That’s because the checks add a median time of 300 milliseconds and a mean of almost 1 second to page loads, making many websites reluctant to use SSL. Marlinspike and others have also complained that the services allow certificate authorities to compile logs of user IP addresses and the sites they visit over time.

Chrome will instead rely on its automatic update mechanism to maintain a list of certificates that have been revoked for security reasons. Langley called on certificate authorities to provide a list of revoked certificates that Google bots can automatically fetch. The time frame for the Chrome changes to go into effect are “on the order of months,” a Google spokesman said.

The problems with CA revocation checks have been particularly prominent over the past 12 months, given the large number of serious CA breaches. While even the Google fetch mechanism isn’t ideal – really, we need to move to an agile trust framework combined (ideally) with browser pinning that can’t be compromised by corporate admins – it’s better. Still, there’s a long way to go until SSL and the CA system are reformed to the point of being actual ‘trusted’ facets of the Internet.