Apr 08, 2024NewsroomSoftware Security / Cybersecurity

Google has announced support for what’s called a V8 Sandbox in the Chrome web browser in an effort to address memory corruption issues.

The sandbox, according to V8 Security technical lead Samuel Groß, aims to prevent “memory corruption in V8 from spreading within the host process.”

The search behemoth has described V8 Sandbox as a lightweight, in-process sandbox for the JavaScript and WebAssembly engine that’s designed to mitigate common V8 vulnerabilities.

The idea is to limit the impact of V8 vulnerabilities by restricting the code executed by V8 to a subset of the process’ virtual address space (“the sandbox”) and isolating it from the rest of the process.

Shortcomings affecting V8 have accounted for a significant chunk of the zero-day vulnerabilities that Google has addressed between 2021 and 2023, with as many as 16 security flaws discovered over the time period.

“The sandbox assumes that an attacker can arbitrarily and concurrently modify any memory inside the sandbox address space as this primitive can be constructed from typical V8 vulnerabilities,” the Chromium team said.

“Further, it is assumed that an attacker will be able to read memory outside of the sandbox, for example, through hardware side channels. The sandbox then aims to protect the rest of the process from such an attacker. As such, any corruption of memory outside of the sandbox address space is considered a sandbox violation.”

Groß emphasized the challenges with tackling V8 vulnerabilities by switching to a memory-safe language like Rust or hardware memory safety approaches, such as memory tagging, given the “subtle logic issues” that can be exploited to corrupt memory, unlike classic memory safety bugs like use-after-frees, out-of-bounds accesses, and others.

“Nearly all vulnerabilities found and exploited in V8 today have one thing in common: the eventual memory corruption necessarily happens inside the V8 heap because the compiler and runtime (almost) exclusively operate on V8 HeapObject instances,” Groß said.

Given that these issues cannot be protected by the same techniques used for typical memory-corruption vulnerabilities, the V8 Sandbox is designed to isolate V8’s heap memory such that should any memory corruption occur, it cannot escape the security confines to other parts of the process’ memory.

This is accomplished by replacing all data types that can access out-of-sandbox memory with “sandbox-compatible” alternatives, thereby effectively preventing an attacker from accessing other memory. The sandbox can be enabled by setting “v8_enable_sandbox” to true in the gn args.

Benchmark results from Speedometer and JetStream show that the security feature adds an overhead of about 1% on typical workloads, allowing it to be enabled by default starting with Chrome version 123, spanning Android, ChromeOS, Linux, macOS, and Windows.

“The V8 Sandbox requires a 64-bit system as it needs to reserve a large amount of virtual address space, currently one terabyte,” Groß said.

“The sandbox is motivated by the fact that current memory safety technologies are largely inapplicable to optimizing JavaScript engines. While these technologies fail to prevent memory corruption in V8 itself, they can in fact protect the V8 Sandbox attack surface. The sandbox is therefore a necessary step towards memory safety.”

The development comes as Google highlighted the role by Kernel Address Sanitizer (KASan) in detecting memory bugs in native code and help harden Android firmware security, adding it used the compiler-based tool for discovering more than 40 bugs.

“Using KASan enabled builds during testing and/or fuzzing can help catch memory corruption vulnerabilities and stability issues before they land on user devices,” Eugene Rodionov and Ivan Lozano from the Android team said.

Apr 03, 2024NewsroomBrowser Security / Session Hijacking

Google on Tuesday said it’s piloting a new feature in Chrome called Device Bound Session Credentials (DBSC) to help protect users against session cookie theft by malware.

The prototype – currently tested against “some” Google Account users running Chrome Beta – is built with an aim to make it an open web standard, the tech giant’s Chromium team said.

“By binding authentication sessions to the device, DBSC aims to disrupt the cookie theft industry since exfiltrating these cookies will no longer have any value,” the company noted.

“We think this will substantially reduce the success rate of cookie theft malware. Attackers would be forced to act locally on the device, which makes on-device detection and cleanup more effective, both for anti-virus software as well as for enterprise managed devices.”

The development comes on the back of reports that off-the-shelf information stealing malware are finding ways to steal cookies in a manner that allows threat actors to bypass multi-factor authentication (MFA) protection and gain unauthorized access to online accounts.

Such session hijacking techniques are not new. In October 2021, Google’s Threat Analysis Group (TAG) detailed a phishing campaign that targeted YouTube content creators with cookie stealing malware to hijack their accounts and monetize the access for perpetrating cryptocurrency scams.

Earlier this January, CloudSEK revealed that information stealers like Lumma, Rhadamanthys, Stealc, Meduza, RisePro, and WhiteSnake have updated their capabilities to hijack user sessions and allow continuous access to Google services even after a password reset.

Google told The Hacker News at the time that “attacks involving malware that steal cookies and tokens are not new; we routinely upgrade our defenses against such techniques and to secure users who fall victim to malware.”

It further recommended users to enable Enhanced Safe Browsing in the Chrome web browser to protect against phishing and malware downloads.

DBSC aims to cut down on such malicious efforts by introducing a cryptographic approach that ties together the sessions to the device such that it makes it harder for the adversaries to abuse the stolen cookies and hijack the accounts.

Offered via an API, the new feature achieves this by allowing a server to associate a session with a public key created by the browser as part of a public/private key pair when a new session is launched.

It’s worth noting that the key pair is stored locally on the device using Trusted Platform Modules (TPMs). In addition, the DBSCI API permits the server to verify proof-of-possession of the private key throughout the session lifetime to ensure the session is active on the same device.

“DBSC offers an API for websites to control the lifetime of such keys, behind the abstraction of a session, and a protocol for periodically and automatically proving possession of those keys to the website’s servers,” Google’s Kristian Monsen and Arnar Birgisson said.

“There is a separate key for each session, and it should not be possible to detect that two different session keys are from one device. By device-binding the private key and with appropriate intervals of the proofs, the browser can limit malware’s ability to offload its abuse off of the user’s device, significantly increasing the chance that either the browser or server can detect and mitigate cookie theft.”

One crucial caveat is that DBSC banks on user devices having a secure way of signing challenges while protecting private keys from exfiltration by malware, necessitating that the web browser has access to the TPM.

Google said support for DBSC will be initially rolled out to roughly half of Chrome’s desktop users based on the hardware capabilities of their machines. The latest project is also expected to be in sync with the company’s broader plans to sunset third-party cookies in the browser by the end of the year via the Privacy Sandbox initiative.

“This is to make sure that DBSC does not become a new tracking vector once third-party cookies are phased out, while also ensuring that such cookies can be fully protected in the meantime,” it said. “If the user completely opts out of cookies, third-party cookies, or cookies for a specific site, this will disable DBSC in those scenarios as well.”

The company further noted that it’s engaging with several server providers, identity providers (IdPs), and browser vendors like Microsoft Edge and Okta, who have expressed interest in DBSC. Origin trials for DBSC for all supported websites are set to commence by the end of the year.

Mar 15, 2024NewsroomBrowser Security / Phishing Attack

Google on Thursday announced an enhanced version of Safe Browsing to provide real-time, privacy-preserving URL protection and safeguard users from visiting potentially malicious sites.

“The Standard protection mode for Chrome on desktop and iOS will check sites against Google’s server-side list of known bad sites in real-time,” Google’s Jonathan Li and Jasika Bawa said.

“If we suspect a site poses a risk to you or your device, you’ll see a warning with more information. By checking sites in real time, we expect to block 25% more phishing attempts.”

Up until now, the Chrome browser used a locally-stored list of known unsafe sites that’s updated every 30 to 60 minutes, and then leveraging a hash-based approach to compare every site visited against the database.

Google first revealed its plans to switch to real-time server-side checks without sharing users’ browsing history with the company in September 2023.

The reason for the change, the search giant said, is motivated by the fact that the list of harmful websites is growing at a rapid pace and that 60% of the phishing domains exist for less than 10 minutes, making it difficult to block.

“Not all devices have the resources necessary to maintain this growing list, nor are they always able to receive and apply updates to the list at the frequency necessary to benefit from full protection,” it added.

Thus, with the new architecture, every time a user attempts to visit a website, the URL is checked against the browser’s global and local caches containing known safe URLs and the results of previous Safe Browsing checks in order to determine the site’s status.

Should the visited URL be absent from the caches, a real-time check is performed by obfuscating the URL into 32-byte full hashes, which are then truncated into 4-byte long hash prefixes, encrypted, and sent to a privacy server.

“The privacy server removes potential user identifiers and forwards the encrypted hash prefixes to the Safe Browsing server via a TLS connection that mixes requests with many other Chrome users,” Google explained.

The Safe Browsing server subsequently decrypts the hash prefixes and matches them against the server-side database to return full hashes of all unsafe URLs that match one of the hash prefixes sent by the browser.

Finally, on the client side, the full hashes are compared against the full hashes of the visited URL, and a warning message is displayed if a match is found.

Google also confirmed that the privacy server is nothing but an Oblivious HTTP (OHTTP) relay operated by Fastly that sits between Chrome and the Safe Browsing server to prevent the latter from access users’ IP addresses, thereby preventing it from correlating the URL checks with a user’s internet browsing history.

“Ultimately, Safe Browsing sees the hash prefixes of your URL but not your IP address, and the privacy server sees your IP address but not the hash prefixes,” the company emphasized. “No single party has access to both your identity and the hash prefixes. As such, your browsing activity remains private.”

Jan 17, 2024NewsroomBrowser Security / Vulnerability

Google on Tuesday released updates to fix four security issues in its Chrome browser, including an actively exploited zero-day flaw.

The issue, tracked as CVE-2024-0519, concerns an out-of-bounds memory access in the V8 JavaScript and WebAssembly engine, which can be weaponized by threat actors to trigger a crash.

“By reading out-of-bounds memory, an attacker might be able to get secret values, such as memory addresses, which can be bypass protection mechanisms such as ASLR in order to improve the reliability and likelihood of exploiting a separate weakness to achieve code execution instead of just denial of service,” according to MITRE’s Common Weakness Enumeration (CWE).

Additional details about the nature of the attacks and the threat actors that may be exploiting them have withheld in an attempt to prevent further exploitation. The issue was reported anonymously on January 11, 2024.

“Out-of-bounds memory access in V8 in Google Chrome prior to 120.0.6099.224 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page,” reads a description of the flaw on the NIST’s National Vulnerability Database (NVD).

The development marks the first actively exploited zero-day to be patched by Google in Chrome in 2024. Last year, the tech giant resolved a total of 8 such actively exploited zero-days in the browser.

Users are recommended to upgrade to Chrome version 120.0.6099.224/225 for Windows, 120.0.6099.234 for macOS, and 120.0.6099.224 for Linux to mitigate potential threats.

Users of Chromium-based browsers such as Microsoft Edge, Brave, Opera, and Vivaldi are also advised to apply the fixes as and when they become available.

Dec 15, 2023NewsroomPrivacy / User Tracking

Google on Thursday announced that it will start testing a new feature called “Tracking Protection” beginning January 4, 2024, to 1% of Chrome users as part of its efforts to deprecate third-party cookies in the web browser.

The setting is designed to limit “cross-site tracking by restricting website access to third-party cookies by default,” Anthony Chavez, vice president of Privacy Sandbox at Google, said.

The tech giant noted that participants for Tracking Protection will be selected at random and that chosen users will be notified upon opening Chrome on either a desktop or an Android device.

The goal is to restrict third-party cookies (also called “non-essential cookies”) by default, preventing them from being used to track users as they move from one website to the other for serving personalized ads.

While several major browsers like Apple Safari and Mozilla Firefox have either already placed restrictions on third-party cookies via features like Intelligent Tracking Prevention (ITP) and Enhanced Tracking Protection in Firefox, Google is taking more of a middle-ground approach that involves devising alternatives where users can access free online content and services without compromising on their privacy.

In mid-October 2023, Google confirmed its plans to “disable third-party cookies for 1% of users from Q1 2024 to facilitate testing, and then ramp up to 100% of users from Q3 2024.”

Privacy Sandbox, instead of providing a cross-site or cross-app user identifier, “aggregates, limits, or noises data” through APIs like Protected Audience (formerly FLEDGE), Topics, and Attribution Reporting to help prevent user re-identification.

In doing so, the goal is to block third-parties from tracking user browsing behavior across sites, while still allowing sites and apps to serve relevant ads and enabling advertisers to measure the performance of their online ads without using individual identifiers.

“With Tracking Protection, Privacy Sandbox and all of the features we launch in Chrome, we’ll continue to work to create a web that’s more private than ever, and universally accessible to everyone,” Chavez said.

Dec 21, 2023NewsroomVulnerability / Zero-Day

Google has rolled out security updates for the Chrome web browser to address a high-severity zero-day flaw that it said has been exploited in the wild.

The vulnerability, assigned the CVE identifier CVE-2023-7024, has been described as a heap-based buffer overflow bug in the WebRTC framework that could be exploited to result in program crashes or arbitrary code execution.

Clément Lecigne and Vlad Stolyarov of Google’s Threat Analysis Group (TAG) have been credited with discovering and reporting the flaw on December 19, 2023.

No other details about the security defect have been released to prevent further abuse, with Google acknowledging that “an exploit for CVE-2023-7024 exists in the wild.”

Given that WebRTC is an open-source project and that it’s also supported by Mozilla Firefox and Apple Safari, it’s currently not clear if the flaw has any impact beyond Chrome and Chromium-based browsers.

The development marks the resolution of the eighth actively exploited zero-day in Chrome since the start of the year –

A total of 26,447 vulnerabilities have been disclosed so far in 2023, surpassing the previous year by over 1,500 CVEs, according to data compiled by Qualys, with 115 flaws exploited by threat actors and ransomware groups.

Remote code execution, security feature bypass, buffer manipulation, privilege escalation, and input validation and parsing flaws emerged as the top vulnerability types.

Users are recommended to upgrade to Chrome version 120.0.6099.129/130 for Windows and 120.0.6099.129 for macOS and Linux to mitigate potential threats.

Users of Chromium-based browsers such as Microsoft Edge, Brave, Opera, and Vivaldi are also advised to apply the fixes as and when they become available.