Why are fervid Googlers making ad-blocker-breaking changes to Chrome? Because they created a monster – and are fighting to secure it

Analysis In a mild PR blitz, Google engineers this month insisted the ad giant's shake up of Chrome browser extensions won't kill advert blockers. Instead, we're told, Googlers are making the plugins safer. Those engineers have more work to do than it may seem.

Setting aside for a moment Google's public filings about the revenue threat posed by web ad blockers, and actions the corporation has taken in the Google Play Store to limit interference with mobile app ads, the internet goliath has reason to overhaul its Chrome Extension ecosystem – because it's as fragile as a house of cards.

Google insists it's dealing with the situation, noting that malicious extension installations have declined 89 per cent since early 2018. But the tech titan's coders are still addressing the root cause – a platform with few guardrails.

Chrome Extensions have obvious utility, for developers and users. They can enhance privacy, add functionality and improve the web browsing experience. But they're so powerful they can be easily abused and the security process Google has in place for the Chrome Web Store isn't foolproof.

The primary problem is that Chrome Extensions can undo the browser's security model and grab sensitive data. A reader who wrote in to elaborate on this issue suggested that if people really understood how unconstrained Chrome Extensions are, they would be given a 10.0 CVE score and banned from enterprises.

That may be something of an overstatement given that the API at the center of this mess, specifically blocking capability of the webRequest API, will continue to be available to enterprises after the pending platform renovation is completed because it's so useful.

Raymond Hill, the developer of uBlock Origin, disagrees with that characterization because, he says, the ability to change headers is intrinsically part of the design of the webRequest API – not an oversight.

"There is no CVE issue here because extensions are opt-in, and what they can do is disclosed to the users choosing to install them," he said in an email to The Register.

But Google's platform design decisions have security implications. And Mozilla's too, since Firefox also supports the webRequest API for Add-ons (aka extensions).

At Canadian security conference SecTor in October last year – coincidentally the same month that Google announced its Chrome Extensions revision plan, known as Manifest v3 – Lilly Chalupowski, security application developer at GoSecure, gave a presentation called The Chrome Crusader.

Security stripped

Chalupowski demonstrated that Chrome Extensions have the ability to strip away HTTP headers, including security headers, from website interactions. The result is that it's trivial to craft an extension that breaks the browser's Same-Origin security model.

As she put in a phone interview with The Register, "Injection is a feature."

"When you have injection as a feature, that's when you have to start being concerned," Chalupowski said, "especially when you're handing over functionality to modify secure headers on the fly and change them to literally whatever you want."

During her demonstration, Chalupowski showed how to craft a basic Chrome Extension that interacts with Flask command-and-control server – running locally for the demo – to steal passwords from an online banking website.

Google, it should be said, keeps an eye out for malicious extensions, but Chalupowski suggested a few ways miscreants might avoid detection.

Chalupowski has posted PoC code on GitHub; The Register hasn't yet determined whether any changes made to Chrome since the initial publication of the PoC code affect its functionality.

"uBlock Origin and a few others use this capability to modify headers for good purposes, for security," she said. "At the same time, those same features will be used in Chrome and Firefox for malicious purposes."

And therein lies the problem: A developer with good intentions can craft extension code that's beneficial and a developer with bad intentions can use the same API to abuse trust and steal information.

Back in 2010, when the webRequest API was being developed, there was some discussion of privacy and security implications, but it wasn't the overriding concern. The design document mentions the issue in passing:

Chrome Extensions used to be even more open. Hills said that back in 2013, Chrome extensions could see the network requests of other extensions via the webRequest API. It was a useful feature but also an abusable one and so was removed.

Google may need to make webRequest less of a risk but among those who develop extensions, there's hope that the price of security isn't ineffective content blocking and subpar privacy controls.

Hill argues that Google should implement a more finely grained permission model for loosening CORS and CSP headers. That way, extensions requiring certain capabilities could ask for them directly rather than settle for a less capable API. He also suggested Google could deny the webRequest API access to a broader range of request headers, as it already does in some instances.

"Right now the browser just inherently trust the browser extensions will be nice," said Chalupowski. Changing that, she said, "is nothing but good news for users."

For developers and users capable of making responsible choices about the software they install, it's a bit more complicated. ®

Updated to add

In an email on Monday, Chalupowski said that she had been able to confirm that her old proof-of-concept no longer works on the latest version of Chromium. She said that Cross Origin Read Blocking (CORB) now appears to be blocking requests, and that code for stripping headers no longer produced log entries to indicate that it’s working. She said she wasn’t sure whether this was related to the addition of features like Strict Site Isolation or something else.

“The fact it’s not working is a good sign,” she said.