Dangerous XSS bug in Google Chrome’s ‘New Tab’ page bypassed security features

0

Get real time updates directly on you device, subscribe now.


Related Posts


Ben Dickson

03 November 2021 at 15:02 UTC

Updated: 03 November 2021 at 18:13 UTC

‘Chrome’s NTP only has a really weak CSP that doesn’t mitigate XSS’

The Chromium team has patched a cross-site scripting (XSS) vulnerability that allowed attackers to run arbitrary JavaScript code on Chrome’s ‘New Tab’ page (NTP).

According to a discussion thread and proof-of-concept on the Chromium bug portal, an attacker can exploit the bug by sending a HTML file to the victim that contains a cross-site request forgery (CSRF), which sends a malicious JavaScript code snippet as a search query to Google.

RELATED Google, Mozilla close to finalizing Sanitizer API for Chrome, Firefox browsers

When the user opens the file, the CSRF script runs and the query is stored in the browser’s search history. The next time the user opens an NTP and clicks on the Google search bar, the malicious code is triggered.

Alarmingly, if the victim was logged into their Google account when opening the malicious file, the request will be saved to their account’s search history and triggered on any other device where their Google account is logged in.

Hacking the NTP

Ashish Dhone, the researcher who discovered the bug, has a track record of hunting XSS bugs in Google web and mobile applications. “I wanted to find XSS in Chrome, hence my hunting started with the desktop application of Google Chrome,” he told The Daily Swig.

“I was looking for HTML markup functionality where XSS can be executed. After spending hours, somehow I found that in NTP, stored search queries are not sanitized and then I was able to execute [the uXSS]”.

UXSS attacks exploit client-side vulnerabilities in a browser or browser extensions in order to generate an XSS condition and execute malicious code.

“When such vulnerabilities are found and exploited, the behavior of the browser is affected and its security features may be bypassed or disabled,” Dhone explains.

Hacking the IPC channel

While the bug is dangerous, other researchers have pointed out that it is not a uXSS. “This XSS is a classic DOM-based XSS, where user-controlled text is assigned as an HTML using innerHTML,” security researcher Jun Kokatsu told The Daily Swig.

Chrome’s NTP exposes Mojo.JS bindings that can send inter-process communication (IPC) messages to the browser through JavaScript code. The XSS bug could abuse this IPC channel to exploit a bug in the browser process, which executes at a much higher privilege than code running in web pages.

Read more of the latest browser security news

“Usually, getting control over sending arbitrary IPC requires native code execution in the renderer process such as memory corruption bugs in the JS engine,” Kokatsu said. “However, because the IPC channel was exposed to JS directly in NTP, the XSS in Chrome’s NTP can be treated as the equivalent of renderer process RCE.”

Limited to Chrome

Most Chromium-based browsers have their own implementation of NTP, so the bug doesn’t affect all browsers, Kokatsu said, adding that Edge was not vulnerable to the attack.

“The XSS could have been mitigated using Content Security Policy (CSP) and/or Trusted Types,” Kokatsu said. “Chrome’s NTP only has a really weak CSP that doesn’t mitigate XSS (i.e., script-src ‘unsafe-inline’).”

Dhone took away a $1,000 bug bounty reward for the discovery as well as some important lessons about browser security. “Always check for the features and functionality where HTML markup is used – this is where most XSS attacks can be found and exploited,” he said.

This article has been updated to reflect the lack of consensus around whether this is a universal XSS vulnerability.

RECOMMENDED Japanese punctuation exacerbates privacy flaw that leaks search terms in Google, Firefox browsers





Source link

Get real time updates directly on you device, subscribe now.

You might also like
Leave A Reply

Your email address will not be published.