The Chromium Security Paradox

Chromium’s developers and security experts are at the forefront of tackling complex security challenges, shaping the future of web security. Their efforts span areas such as enforcing Same-Origin-Policy, advanced cryptographic implementations and process sandboxing - truly fascinating work, and there’s no criticism here. However, Chromium's threat model excludes local access attacks—attacks where malware, once executed on the victim’s machine, directly accesses and extracts sensitive browser data—a design choice that leaves users vulnerable to malware.

In this article, we’ll dive into one of the most pressing security challenges facing the Chromium browser, uncovering hidden vulnerabilities and blind spots through compelling case studies surfaced in Chromium’s own Issue Tracker.

The Numbers That Tell the Story

Let’s start with some statistics to illustrate the growing threat of info-stealing malware:

• 10+ million devices fell victim to info-stealing malware in 2023 alone [Kaspersky].
• 24% of all breaches in 2024 began with stolen credentials, making them the most common initial attack method used by hackers [Verizon].
• 56.7% of known malware in Q3 2024 consisted of info-stealers, making them the most prevalent malware category [Ahnlab].

These numbers raise a troubling reality: browsers, which serve as primary repositories for sensitive data, offer minimal defenses against info-stealing malware. This type of malware directly extracts high-value data such as credentials, cookies, and tokens from browsers, fueling a vicious cycle - the stolen data only broadens the attack surface. This raises a critical question: why doesn’t the Chromium browser defend against these attacks?

The Threat Model

With over 32 million lines of source code, the Chromium project is a haven for the security researcher. Securing such a massive codebase is an enormous challenge. To maintain focus, Chromium established a threat model that clearly defines how it aims to protect the browser.

Our primary security goal is to make it safe to click on links, so people can feel confident browsing to pages they haven’t visited before. (Google Security Blog)

Following the “Chromium Security FAQ”, their threat model focuses on protecting users from interactions with remote untrusted content, such as malicious web pages, that attempt to execute arbitrary code or access sensitive data. To protect against such threats, Chromium has developed and pioneered several security architectures such as:

• HTTPS for encrypted communication.
• Site Isolation via multi-process architecture.
• Process Sandboxing keeps potential exploits contained, limiting their impact.
• Content Security Policy (CSP) to restrict resource loading and prevent data leakage.
• and the list goes on…

These innovations are nothing short of groundbreaking. They don’t just protect Chromium users—they influence the entire browser ecosystem, setting a benchmark for web security. Thanks to its layered approach, Chromium is one of the most secure platforms for browsing the internet, shielding billions of users daily. Yet, even with this arsenal of cutting-edge technologies, Chromium’s threat model isn’t without gaps that reveal the inherent challenges of securing a project of this magnitude.

What’s Missing?

Chromium’s threat model, while robust, makes deliberate trade-offs to concentrate its focus on threats it can effectively control. Local and compromised environments fall outside its protection scope. Whether it’s an adversary gaining physical access to a device, tampering with browser files, or a malicious program running in the same environment as the browser, these scenarios are left to operating system-level defenses. Chromium’s developers recognize that protecting against such attacks lies beyond the browser’s capabilities.

On top of that, Chromium cannot shield users from human error. Actions like installing malicious extensions, falling for phishing schemes, or reusing weak passwords expose users to significant risks. While the browser provides safeguards like permission prompts and warnings, the ultimate responsibility lies with the user to make informed and cautious decisions.

As we’ve seen, malicious actors eagerly exploit these gaps. Info-stealing malware leverages these vulnerabilities to harvest sensitive data like credentials and cookies, turning Chromium browsers into lucrative targets. This reality has driven the development of enterprise browsers—platforms designed to address these blind spots and provide a more secure browsing experience.

Enter the Issue Tracker

The Chromium Issue Tracker is a dynamic platform where developers and security researchers come together to identify, report, and resolve bugs, vulnerabilities, and feature requests. Acting as an open window into the browser's development lifecycle, it reflects Chromium's commitment to transparency and open-source principles. But more importantly, it offers a rare glimpse into the evolving security landscape of one of the world’s most widely used browsers.

For browser security enthusiasts, it’s an absolute treasure trove. Some of Chromium’s most significant CVEs have been discovered and reported through this system, shedding light on the vulnerability reporting process. While many of these reports evolve into CVEs—bringing both bug bounties and well-deserved recognition to their discoverers—there’s a recurring trend worth exploring: local attack issues are often labeled as out of scope. 

This opens up a fascinating opportunity. We noticed that when security problems fall outside Chromium’s threat model, the response often includes a link to the "Chromium Security FAQ" explaining why such cases are excluded: 

Using this pattern, we searched the Issue Tracker to compile a list of such cases: https://issues.chromium.org/issues?q=physically_local-attacks-in-chromes-threat-model

The results were astonishing. Over the past eight years, more than 400 findings surfaced, while less than 30 are labeled as “Fixed”. While this isn’t an exhaustive list—there could be findings where the FAQ link wasn’t used, along with duplicates and false positives—it still highlights some truly intriguing vulnerabilities and attack techniques. 

Let’s dive into a few case studies.

Storing Sensitive Data

One of the most highly debated aspects of Chromium’s architecture on the Issue Tracker is how it handles the storage of sensitive data like cookies and passwords. 

Here’s how Chromium’s encryption mechanism works: data is first encrypted using a symmetric encryption algorithm. The encryption key used for this process is then encrypted with a system API—on Windows, for instance, the Data Protection API (DPAPI) is used to bind the key to the user’s account. Later the encrypted keys are stored in the Local State file, which is located in the browser's profile directory. And that’s it.

This design is problematic. Any process running under the same user context as the browser can access the encryption keys and decrypt them with ease, even without the need to interact with the browser. This design inadvertently leaves cookies and passwords vulnerable to local attacks, allowing even basic tools to extract this sensitive information.    

This behavior has been publicly documented for over a decade, with one notable instance appearing in the Issue Tracker as early as 2008. In this report, a user highlighted how a widely available tool, NirSoft, could extract saved passwords from Chrome without significant effort.

Over the years, this approach has become a cornerstone for cybercriminals, fueling the rise of countless info-stealers and data extraction tools. From open-source utilities to sophisticated malware sold in underground marketplaces, these tools make exploiting Chromium-based browsers alarmingly easy. Popular examples like RedLine Stealer, Raccoon, and Vidar are just the tip of the iceberg in a rapidly growing ecosystem of data-harvesting tools.

What’s more, this technique is so accessible that even legitimate applications, like competing browsers, have used it to enable seamless data migration. By leveraging the same methods as cybercriminals, these apps demonstrate just how straightforward it is to extract passwords, cookies, and other sensitive information directly from the browser.

Only recently, in late 2024, a new technique called "App Bound Encryption" was introduced in Chromium to enhance the security of browser cookies. This method leverages an elevated system proces​​s with privileged access to manage cookie encryption. The encryption keys are stored and accessed exclusively by this process, ensuring that only the originating Chromium-based browser can request and decrypt the cookies. This technique was designed to prevent other processes, even those running with user-level permissions, from accessing the encryption keys.

Yet, despite these advancements, it took only a couple of months for researchers and attackers to bypass this implementation. Techniques to bypass "App Bound Encryption" were analyzed and published across various online forums, blogs and repositories (like this), including a widely discussed GitHub repository.

The extension which can not be removed

This issue is a personal favorite. The first instance of this finding on the Issue Tracker dates back to 2013, when a user reported that an extension had forcefully installed itself into the browser using the ExtensionInstallForcelist registry key, typically stored in the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome registry hive.

This registry is used to configure the list of force-installed apps and extensions, originally intended for organizational environments to enforce the installation of necessary extensions.

Extensions added to this key are virtually immovable—they can’t be uninstalled through the extensions page, and even if you delete the extension files from disk, the browser immediately redownloads and reinstalls them. It’s the ultimate persistence mechanism for malicious extensions. It’s easy to see why this method has become wildly popular in malware.

The frustration of the original reporter is hard to miss. Responses to the report simply directed users to manually edit the registry key to remove the extension—a solution far from accessible for the average user. Over the years, this problem has been raised repeatedly, yet millions of users continued to fall victim to this malware technique. Numerous security firms have flagged and reported malicious extensions abusing this feature, but the issue remains unresolved to this day, more than 10 years later (as seen here, here, and here).

DLL Hijacking

DLL hijacking is one of the oldest tricks in the exploitation playbook—and for good reason. It’s simple, effective, and difficult to detect. Chromium, like many modern software applications, relies on a mix of external and internal dependencies. While this is standard practice, the management of these dependencies and integrity checks for DLLs can sometimes fall short, leaving Chromium-based browsers vulnerable to DLL hijacking attacks.

The appeal of DLL hijacking lies in its simplicity. All it takes is to place a malicious DLL in the right location, and the browser will load it as if it were a legitimate part of the application. This approach allows the attacker to avoid detection, as the malicious file blends seamlessly with the application’s structure. Once in place, the malicious DLL persists indefinitely, loading into the browser every time it’s launched.

Over the years, numerous DLL hijacking vulnerabilities have surfaced in Chromium’s Issue Tracker. Many of these were labeled as “won’t fix”, leaving the door open for exploitation.

This technique has powered several high-profile malware campaigns. One example is the AdService malware, which used DLL hijacking to exfiltrate sensitive user data, including Facebook and Twitter account information. By placing a malicious version of winhttp.dll in the browser’s Program Files directory, the malware ensured that it would be loaded by the browser, giving attackers seamless access to valuable user data.

A year after this report, the Issue Tracker saw discussions about winhttp.dll and other similar DLLs, emphasizing their potential to be hijacked. 

To their credit, Chromium’s team has made several attempts over the years to mitigate these issues. One initiative aimed to reduce crashes caused by third-party software injecting DLLs into the browser. Another attempt involved changing the DLL search order to block common sideloading patterns—but these changes were eventually rolled back.

Despite these efforts, DLLs like winhttp.dll remain vulnerable to hijacking today. This persistent security gap continues to leave Chromium-based browsers exposed to one of the oldest, yet most reliable, exploitation techniques in the wild.

The Path Forward: Chromium's Role and the Enterprise Solution

The Chromium browser remains a pillar of innovation in the world of web security, offering robust defenses against a wide array of online threats. Yet, as this article explores, its focus on protecting users from remote content leaves local access vulnerabilities exposed—gaps that malicious actors eagerly exploit.

Importantly, this is not a failure of Chromium or its developers. Chromium was designed as a commercial browser for the masses, prioritizing usability and protection against remote threats. It was never designed to eliminate all potential vulnerabilities, especially those arising from local access scenarios. Expecting a consumer browser to single-handedly secure against all forms of attack is neither realistic nor fair.

For enterprises, where the stakes are exponentially higher and the attack surface much broader, relying solely on a consumer-focused browser security is insufficient. This is where the concept of an enterprise browser shines. By building on Chromium’s strong foundation and embedding additional protections tailored to organizational needs, companies can address these overlooked vulnerabilities.

The future of secure browsing lies in combining Chromium's open-source innovation with enterprise-grade customizations. By understanding its threat model and augmenting it with solutions that cover local access vulnerabilities, enterprises can create a truly resilient browsing environment—one that safeguards the users as well as critical systems and data they interact with every day.

The Island Enterprise Browser fundamentally transforms how the world’s leading organizations work by embedding enterprise-grade IT, security, network controls, data protections, app access, and productivity enhancements directly into the browser itself, enabling secure access to any application, protecting sensitive data, streamlining IT operations, and delivering a superior end-user experience while actually boosting productivity.

To learn more about how we're reimagining the enterprise workspace from the browser up, start here.

If you’re interested in building something that’s changing everything, check out our open positions here.