‘Chrome’s New Tab page only has a really weak CSP that doesn’t mitigate XSS’
UPDATED 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.
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 a New Tab Page 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 New Tab page
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 New Tab page, 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 New Tab page 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 New Tab page, 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 New Tab page, 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 New Tab page 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.
This article was updated again on November 19, 2021, this time to remove the ‘NTP’ acronym that some in the tech community were confusing with the Network Timing Protocol.
RECOMMENDED Japanese punctuation exacerbates privacy flaw that leaks search terms in Google, Firefox browsers
