CVE-2023-28162 - Deep Dive Into the Firefox AudioWorklet Vulnerability

In early 2023, researchers found a critical bug in Mozilla Firefox, Firefox ESR, and Thunderbird, officially tracked as CVE-2023-28162. This vulnerability revolved around the implementation of AudioWorklets—modern APIs essential for real-time audio processing in browsers. If you'd like to understand how a subtle bug in type casting could put millions of users at risk of browser crashes and potentially even takeovers, read on.

This post will break down the flaw in plain English, see how the bug emerged, and show code snippets—even how an attacker might try to leverage the crash. Finally, we’ll talk about protection steps and link to original references.

What Is An AudioWorklet?

AudioWorklets let developers process and generate audio directly within the browser, often for games or music production. They run in their own worklet thread for better performance and low latency. In other words, they're supercharged background workers—but just for audio.

Mozilla's *C++* code, like in all browsers, has to be very careful when shuffling around different types of data between JavaScript and the browser engine. If something goes wrong, the browser can crash or, worst-case, run malicious code.

The Core Issue: Type Casting Gone Wrong

Here’s what Mozilla’s vulnerability note says:

> “While implementing AudioWorklets, some code may have casted one type to another, invalid, dynamic type. This could have led to a potentially exploitable crash.”

Let’s break that down.

- Type casting is when you tell code to treat some data as if it’s something else—think “pretend this apple is an orange.”
- In C++ (which powers Firefox), you can use static_cast or dynamic_cast for this, but it’s risky—if the object *isn’t* actually the right type, things explode.

Imagine the following (simplified) C++ snippet, which reveals just how things can go south

BaseAudioWorkletNode* node = /* get a node from somewhere */;
SpecialAudioWorkletNode* special = dynamic_cast<SpecialAudioWorkletNode*>(node);
special->doSpecialProcessing();

If node *isn't* really a SpecialAudioWorkletNode, the dynamic_cast returns nullptr, and then the next call to doSpecialProcessing() will crash the browser ("use after null"). Under certain circumstances, this can be used to trigger controlled memory corruption.

2. Crafting Malicious Web Content

An attacker could build a website that generates AudioWorklets with the exact objects and behaviors that cause the browser to make an invalid cast from the wrong object type. This could be triggered just by visiting the web page—no user interaction needed.

A simplified example in JavaScript

class EvilProcessor extends AudioWorkletProcessor {
    constructor(options) {
        super();
        // Setup confusing state for the C++ backend
    }
    process(inputs, outputs, parameters) {
        // Manipulate audio buffers to cause confusion
        return true;
    }
}
registerProcessor('evil-processor', EvilProcessor);

// Creating the malicious AudioWorklet node
(async function(){
    await audioContext.audioWorklet.addModule('evil-worklet.js');
    let node = new AudioWorkletNode(audioContext, 'evil-processor');
})();

The critical part happens under the hood in C++ when the malicious state causes the browser’s code to try and treat a generic object as a more-specialized one, triggering the crash.

Browser Crash: The most consistent result—browser or tab unexpectedly closes.

- Remote Code Execution (Theoretical): With precise memory tricks, a crash can sometimes be manipulated to execute the attacker’s code. There’s no public report of a working RCE exploit, but it’s not impossible given past browser history.

Let's illustrate a risky cast like the one in question (C++)

// Somewhere deep in Firefox's Web Audio backend
AudioNode* node = /* gets a pointer from JS world */;
AudioWorkletNode* worklet = static_cast<AudioWorkletNode*>(node);
worklet->ProcessAudio();

If node isn't actually an AudioWorkletNode, this could cause invalid access and crash.

A safer approach would be

if (auto* worklet = dynamic_cast<AudioWorkletNode*>(node)) {
    worklet->ProcessAudio();
} else {
    // Handle the error safely
}

Mitigation and Fix

The fix was quickly applied in Firefox 111, Firefox ESR 102.9, and Thunderbird 102.9. Developers improved the casting logic so the browser no longer treats arbitrary audio nodes as specialized ones in an unsafe way.

Yes, if you use Firefox 111 or later, or recent Thunderbird.

- It's crucial to keep browsers and mail clients up-to-date—this is one of dozens of critical media-processing bugs patched every year.

References

- Mozilla Security Advisory 2023-10 (CVE-2023-28162)
- NVD Entry (CVE-2023-28162)
- AudioWorklet Explainer on MDN

Conclusion

CVE-2023-28162 teaches us that even modern browser technologies like AudioWorklets can hide deep bugs arising from simple programming mistakes—like casting variables to the wrong kind of object. If you haven’t updated your browser in a while, now’s a good time. Developers: always use safe casting and check your types!

Timeline

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