A new version of Adblock Plus was released on July 17, 2018. Version 3.2 introduced a new filter option for rewriting requests. A day later AdBlock followed suit and released support for the new filter option. uBlock, being owned by AdBlock, also implemented the feature.
Under certain conditions the
$rewrite filter option enables the publishers of these extensions and the maintainers of filter lists to inject arbitrary code in web pages.
The filter option empowers extension publishers and filter list operators to attack users without the need to release a malicious version of the extension, and without publishing an exploit to a public filter list that is easy to audit.
The affected extensions have more than 100 million active users, and Adblock Plus has several other forks controlled by third-party developers.
The feature is trivial to exploit in order to attack any sufficiently complex web service, including Google services, while attacks are difficult to detect and are deployable in all major browsers.
Considering the nature and implications of the uncovered vulnerabilities, and given that filter lists have been employed in the past for politically motivated attacks, details of the exploit chain are publicly disclosed to ensure the fastest possible propagation of upcoming mitigations in the affected browser extensions and web services.
uBlock Origin is not vulnerable to the described attack.
$rewrite filter option is used by some ad blockers to remove tracking data and block ads by redirecting requests. The option allows rewrites only within the same origin, and requests of
OBJECT_SUBREQUEST types are not processed.
However, web services can be exploited with the help of this filter option when they use XMLHttpRequest or Fetch to download code snippets for execution, while allowing requests to arbitrary origins and hosting a server-side open redirect.
Extensions periodically update filters at intervals determined by filter list operators. Organizations and individuals may be targeted based on the IP addresses from which the updates are requested, delivering the malicious payload only to targets, while keeping the public filter list unchanged.
The existence of an attack may be difficult to prove, unless the device is monitored during the attack, because threat actors could set a short expiration time for the malicious filter list, which is then replaced with a benign one.
The following criteria must be met for a web service to be exploitable using this method:
- The page must load a JS string using XMLHttpRequest or Fetch and execute the returned code
- The page must not restrict origins from which it can fetch using Content Security Policy directives, or it must not validate the final request URL before executing the downloaded code
- The origin of the fetched code must have a server-side open redirect or it must host arbitrary user content
Filter list operators may deliver a rule update such as this:
The above rule redirects the target request to Google’s I’m Feeling Lucky search service, which then redirects to a page with the payload:
Steps for running arbitrary code on Google Maps:
- Install either Adblock Plus, AdBlock or uBlock in a new browser profile
- Visit the options of the extension and add the example filter list, this step is meant to simulate a malicious update to a default filter list
- Navigate to Google Maps
- An alert with “www.google.com” should pop up after a couple of seconds
Gmail and Google Images also meet the listed conditions to be exploitable.
Google has been notified about the exploit, but the report was closed as “Intended Behavior”, since they consider the potential security issue to be present solely in the mentioned browser extensions. This is an unfortunate conclusion, because the exploit is composed of a set of browser extension and web service vulnerabilities that have been chained together.
Please note that the vulnerability is not limited to Google services, other web services could be affected as well.
The exploit can be mitigated in the affected web services by whitelisting known origins using the
connect-src CSP header, or by eliminating server-side open redirects.
Ad blocking extensions should consider dropping support for the
$rewrite filter option. It’s always possible to abuse the feature to some degree, even if only images or style sheets are allowed to be redirected.
Users may also switch to uBlock Origin, which does not support the
$rewrite filter option. The feature has been rejected by the maintainer of the extension, citing performance issues and security concerns.
The blog post has been updated on April 17, 2019 to clarify who could possibly exploit the security issue and how attacks may unfold. The safety of uBlock Origin has been further emphasized due to the confusion around the uBlock brand name.