Introduction

Hello and welcome to the first in a new series of blog posts in which we will discuss some issues that are commonly reported through our Researcher Incentive (Bug Bounty) Program, but do not meet the criteria for reward. The purpose of the series is to provide insight and demystify some complexities of a modern browser’s threat model. The series we will primarily cover the security of Microsoft Edge, but the concepts covered are applicable to all modern browsers, including Google Chrome and other Chromium browsers.

For our first topic, we will address the subject of local attacks on the client from either a malicious user with physical access to the device, or from other software running alongside the browser. Examples of such attacks include modification of the browser executable, injection of additional code into the running processes, or tampering with settings or data residing in local storage.

Web browsers are designed to mitigate threats from the internet. However, if a malicious actor has either physical access to, or existing code execution on the device which the browser is running, they can bypass these protections.

It is important to note that Microsoft Edge makes every effort to ensure that the user is as well protected as possible against these threats, and continues to make investments in this area, however there are always trade-offs.

Common Submissions

I would like to walk through some examples of the submissions that the Edge Security Team has received over the past few years. The bug reports have been anonymised and simplified to focus on their core principle. With each one, I will address the attack in question, and provide an explanation as to why the case did not meet our security bar.

“When I open the database of stored credentials on my computer, I can see my stored credentials.”

This is probably one of the most common reports that we receive through our researcher incentive program, likely due to the vast array of articles and tools available online. Edge, along with most other mainstream browsers, provides a facility to both generate and store your login credentials. Indeed, password generation is often regarded as being beneficial to browser security since it provides a systematic solution to password reuse.

For the browser to access and use the credential data, it first stores them in an SQLite database on the local hard drive. The passwords are encrypted with the industry standard Advanced Encryption Standard (AES), using key generation and storage provided by Chromium’s OSCrypt which on Windows is backed by the Data Protection API (DPAPI).

We are currently making substantial investments in this area (more details in an upcoming blog!) but it is important to clarify that the current protections afforded to data at rest in these scenarios are intended primarily as a deterrent to attackers and do not constitute a hard security boundary. The current cryptographic architecture is by no means bulletproof and there are several ways that a determined malicious actor with code or physical access can retrieve the credentials. To give just one example, the Windows process model allows any Medium Integrity Level (IL) process to execute code within the process space of any other process on the device (including Edge). An attacker can abuse this privilege to simply siphon the credentials from memory as they are retrieved from disk (more on code injection later). For this reason, until more defensible mitigations are put in place, attacks of this nature are not currently considered within the scope of our threat model.

“If I place a malicious DLL in the Edge application install path, I will achieve code execution when I run Edge.”

Perhaps more simply paraphrased to “If I add executable code to a device, said device can execute it,” this is something of a self-fulfilling prophecy. Once again, the same adage applies; if an attacker can place a DLL file in an Administrator-writable directory, then there is no end to actions they can perform (execute shell scripts, delete files, create accounts, etc).

However, these cases are not always without their merit. One such nuanced case related to a browser feature wherein Edge downloaded a feature application installer to the user’s Downloads directory temporarily. Should an attacker trigger a download of a file called “version.dll” then the malicious code could subsequently execute, if an executable dependent on version.dll is later executed from the Downloads folder. This behaviour is why downloading a DLL will always result in a security prompt (while downloading an exe file might not). See Eric Lawrence’s article for more detail.

As is often then case, the devil is in the detail; the Downloads folder is not considered a protected directory. Moreover, the ability to fetch files from the web and write them to this folder (albeit with the Mark of the Web) is expected behaviour for a web browser. The bug in this case was using the Downloads folder as a temporary directory for the installer, and not the attacker’s ability to download or plant a DLL.

“If I run a program to inject a DLL in Edge, I can read secrets and modify the behaviour of Edge.”

As citizens of a computer system, web browsers fall prey to the idiosyncrasies of the Operating System’s process model. Most modern desktop operating systems have extremely loose process separation, exacerbated by overly-powerful default run levels for user accounts. On Windows, for example, applications launched by a user run at Medium IL and are capable of loading and executing arbitrary code within the environment of another process running at the same or lower level. This technique is often referred to as “DLL Injection” and it only requires the use of three syscalls and there are many tools and projects available to facilitate it.

Edge have been investing in various mitigations for these styles of attack to protect the user as much as possible, with varying degrees of success. At least for the foreseeable future, desktop browsers cannot guarantee the operational or security integrity of their operation if third party code is injected into their process.