📜 ⬆️ ⬇️

Vulnerability in AdBlock and uBlock filters allows arbitrary code execution on the user side.

Under certain conditions, the $rewrite filter option implemented in AdBlock, AdBlock Plus and uBlock with update 3.2 dated July 17, 2018 , allows you to execute arbitrary code on a webpage displayed to the user, according to an armin.dev blog .

Here is how the problem function is described in the AdBlock patchout itself:
In this patch, a new $rewrite filter option has been implemented, which allows the authors of filter lists to prevent (mostly video) from displaying advertisements that previously could not be blocked on a number of websites.
The described vulnerability affects all three mentioned ad blockers, the total audience of which exceeds 100 million users. You can use it to attack any web service, including and not limited to, for example, any of Google resources. The problem is widespread, that is, the attack with the same success can be carried out on any popular browser and does not depend on its version.

The vulnerability lasted for almost 9 months and was found just now.

The essence of the attack


The author of the original source blog explains that the $rewrite option is used in AdBlock and other blockers mentioned to avoid tracking the user and blocking advertisements by redirecting requests from a visited webpage. So, $rewrite allows you to redirect and not process requests of type SCRIPT , SUBDOCUMENT , OBJECT and OBJECT_SUBREQUEST .
')
An attack can occur if a website uses XMLHttpRequest or Fetch to download and execute snippets of code, while simultaneously allowing arbitrary requests to be made.

That is, to make an attack, three conditions must be met:

  1. The webpage should load the JS string using XMLHttpRequest or Fetch and execute the returned code.
  2. The webpage should not use the Content Security Policy verification directives and should not verify the final URL before executing the downloaded code.
  3. The source of the extracted code must support server-side redirects or contain arbitrary user-generated content.

It would seem that there are a lot of conditions, and CSP is far from new to the world of web development. However, the main threat to the found vulnerability is not how it works, but how it spreads.

Since the AdBlock, AdBlock Plus and uBlock filtering systems are vulnerable, the path of “infecting” the ultimate victim is extremely simple - through the auto-update filter system. It is no secret that a huge part of users use ready-made filters, and does not customize them on their own. At the same time, the author of the filter pack can roll out a malicious update, conduct an attack, and then “roll” the packet, thereby “noticing the traces”.

Ways to fight


The easiest way to protect yourself from this vulnerability is to go to uBlock Origin. This ad blocker does not support the $rewrite function, that is, it is impossible to implement the described attack through it.

Otherwise, it is worth waiting for the next AdBlock update at your own risk. In the official blog of the blocker, literally a few hours after the publication in the armin.dev blog, this post appeared in response to the $rewrite vulnerability.

In it, the AdBlock administration says that even though the vulnerability is specific, they are very attentive to the safety of their audience and in the next update , the $rewrite function will be cut out from AdBlock.

Also, according to the administration, they check all the filter lists and recheck them now. According to the results of the test, the administration reports that none of the existing filter lists described the attack method on the user in itself. Taking into account the fact that between the time of the publication of the original entry and the response in the AdBlock blog, only about four hours passed, just rejoice in the efficiency of the blocker team.

At the same time, the removal of the $rewrite function from the project is a step back for AbBlock, since it was originally created to combat pop-up video ads. Now she will return for the sake of universal security. In addition, the efficiency with which it was decided to completely remove $rewrite from the project shows that even though the attack is specific, the consequences of its massive conduct look too dreadful.

Source: https://habr.com/ru/post/448302/


All Articles