A new version of Adblock Plus
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
filter option enables filter list maintainers to inject arbitrary code in web pages.
The affected extensions have more than 100 million active users, and 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.
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
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. Attacks are difficult to detect because the operator may set a short expiration time for the malicious filter list, which is then replaced with a benign one. Organizations and individuals may be targeted based on the IP addresses from which the updates are requested.
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
CSP header, or by eliminating server-side open redirects.
Ad blocking extensions should consider dropping support for the
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
. It does not support the
filter option and it is not vulnerable to the described attack.