How I found a workaround for Google Chrome's massive anti-adblocking update, but it's now fixed

Google Chrome has transitioned its extension specifications from Manifest V2 (MV2) to Manifest V3 (MV3). With this transition, the API 'webRequestBlocking', which allows extensions to dynamically block requests to websites, is no longer available. Since many ad blockers relied on this WebRequestBlocking, the transition to MV3 was expected to have a major impact on ad blockers, but Derin Eryılmaz reported that he discovered a bug in 2023 that could circumvent the MV3 restrictions and enable webRequestBlocking.

How I found a bypass in Google's big anti-adblock update
https://0x44.xyz/blog/web-request-blocking/

Chrome extensions are written in JavaScript, but their APIs work with the browser's internal C++ functions through a mechanism called 'bindings.' In the past, Google handled some of its APIs in JavaScript files, but after discovering vulnerabilities that allowed web pages to manipulate the behavior of the APIs, it migrated most of the API bindings to C++. However, some APIs, including ' chrome.webRequest ,' still use JavaScript bindings, which was the root cause of the bug.

In MV3, the following options for blocking requests in the ' webRequest.onBeforeRequest ' event are no longer available because the last 'blocking' part, 'webRequestBlocking', is not allowed in MV3.
[code]chrome.webRequest.onBeforeRequest.addListener(() => {
return { cancel: true }
}, { urls: ['*://*.example.com/*'] }, ['blocking'])[/code]

However, the implementation of this event uses a JavaScript class whose constructor is externally callable, allowing the creation of fake event objects with their own properties.

The bug discovered involved the misuse of a parameter called 'opt_webViewInstanceId' when generating this fake event. This parameter was previously used to allow Chrome platform apps to use 'webRequestBlocking' to control communication within the WebView, and events with this ID were exempt from permission checks. However, the browser did not verify the origin of events with this ID.
[code]let WebRequestEvent = chrome.webRequest.onBeforeRequest.constructor

// opt_webViewInstanceId is the 5th argument
let fakeEvent = new WebRequestEvent('webRequest.onBeforeRequest', 0, 0, 0, 1337)

fakeEvent.addListener(() => {
return { cancel: true }
}, { urls: ['*://*.example.com/*'] }, ['blocking'])[/code]

Therefore, even with normal extensions, it was possible to bypass the permission check by specifying an arbitrary number for 'opt_webViewInstanceId' and enable the request blocking function in the MV3 environment. This issue was caused by old code for platform apps that were deprecated in 2020 still remaining as of 2023, and Eryılmaz said, 'This is a good example of how old code can lead to bugs.'

By exploiting this bug, it was possible to develop an ad blocker that worked in the MV3 environment simply by replacing 'chrome.webRequest.onBeforeRequest' with a fake event. The discoverer, Eryılmaz, said, 'I could have used this bug to create a perfectly working ad blocker just by replacing all instances in MV3 with a fake event,' but he jokingly said that he reported the bug to Google in August 2023 because he didn't know how to make an ad blocker.

As a result, the bug was fixed in Chrome 118, adding validation that extensions using 'opt_webViewInstanceId' have the appropriate permissions. However, Google did not consider the report a security issue and did not award the bug bounty because it was determined that the bug did not allow extensions to access data that they did not have access to.

Eryılmaz released the following image, saying, 'This is my earnings from this bug.' However, for CVE-2023-4369 , which Eryılmaz also discovered in 2023, a reward of $10,000 (about 1.45 million yen) was paid after the report.