Fix has been issued
A security researcher has demonstrated how to bypass the payment handler security technology built into Google’s Chrome browser.
An issue found in the Payment Handler API could be paired with an exploit in Chrome’s renderer in order to read, or even steal, a victim’s files, according to a recent blog post from Google’s Project Zero.
Chrome 76 was impacted but a fix has since been issued.
The Payment Handler API enables web applications and pages to manage payments. Google began supporting the technology last year with its release of Chrome 68.
The API functions by opening a new window within a user’s page when a payment request is required. Both this new window and the API are required to share the same origin.
“The problem is the URL check is performed solely in the service worker process,” explained Project Zero’s Sergei Glazunov.
“Considering that a service worker can share its process with a regular web page renderer, a compromised renderer can abuse this API to load an arbitrary URL, including URLs in the file:// and chrome:// schemes.”
This scenario could allow an attack to steal files from a victim’s machine, Glazunov said.
“The download test case in the attached archive forces the browser to download an HTML file with its copy to the victim’s disk and then open it using openWindow,” Glazunov said.
The security researcher went on to explain how the compromised renderer should reconstruct the path of the downloaded file.
“The browser grants the local file read permission to processes that serve file:// pages, so the exploit just needs to re-use a bug in the renderer to skip the renderer-side checks (e.g., by overwriting SecurityOrigin::universal_access_ and block_local_access_from_local_origin_).”
The exploit is used after the service worker loads a local downloaded file using the Payment Handler API. This would normally have a limited impact due to the implementation of Site Isolation to prevent access to other processes.
Glazunov found, however, that a Site Isolation bypass under these conditions was also possible since CanRequestURL is not called during openWindow.
“The browser creates an empty page, whose corresponding SiteInstance doesn't get a site assigned to it,” Glazunov explained.
“Then, instead of performing regular navigation and initializing the site instance, it passes the URI to the new renderer via HandleRendererDebugURL.
“The browser still considers the page empty and the renderer unused, so it may re-use the renderer for future page loads (except for chrome:// and chrome-extension:// URLs), while the attacker’s JavaScript payload will be running in the same process.”
The issue was reported to Google on August 22, and disclosed followed its 90-day patch deadline.
RELATED The service worker hiding in your browser – New tool easily backdoors vulnerable websites
