Triggering the Prototype Pollution Primitive This prevents further security checks on the calling context.ģ - Call the GetComponents method to add the components object to the scope.
DOWNLOAD FIREFOX PATCH
Note that all this is made possible because the attacker script has already gained full native code execution within the renderer sandbox, as detailed in part one of this series:ġ - Mark the current JavaScript compartment as system by setting the corresponding flag in memory.Ģ - Patch CanCreateWrapper to always return NS_OK. To gain access to components, the attacker script performs the following steps. This is a different object than a much more limited object confusingly also named Components, which is intended to be exposed to untrusted script. In particular, what we need is access to an object called components. Now that we have a complete picture of what we want to do, let’s begin.Īchieving Privileged JavaScript ExecutionĪs mentioned above, before we can invoke NotificationDB, we need to access a privileged JavaScript context. The exploit will use this corruption to gain chrome-level XSS during tab restoration, leading to native code execution outside the sandbox. Since JavaScript execution contexts are largely shared, all chrome-level JavaScript modules are now exposed to unexpected properties in Object.prototype. This affects all JavaScript that runs in the chrome process, far beyond NotificationDB.jsm itself. Using this prototype pollution, we can corrupt the global JavaScript state in the chrome process. It allows us to write any serializable JavaScript value to any property of Object.prototype with only one restriction: the value we write must have an id property that matches the property name we are writing to. This gives us a prototype pollution primitive. This prototype is Object.prototype, since this.notifications is a plain Object. Instead, it will access the object’s prototype. If we set origin to the string "_proto_", then this.notifications will not access a normal data property. More specifically, we can set them to any values supported by the structured clone algorithm, since this is the algorithm used to marshal data from the renderer to the chrome process. This means we can set either of these to any serializable JavaScript value. In the case of a “Notification:Save” message, a “save” task is queued:Īt, both origin and notification.id are taken directly from the message data sent by the renderer, without any validation. It processes various messages, which it receives via the content process message manager. It is implemented almost entirely in JavaScript. One of the endpoints is called NotificationDB. As we will see, achieving “privileged” JavaScript execution will be the exploit’s first step.Īfter achieving privileged JavaScript execution, the exploit can reach out to various endpoints for communication with the chrome process. In fact, some of these interfaces can be reached directly from JavaScript when running in a “privileged” JavaScript context (not to be confused with any OS-level concept of privilege). How can the sandboxed renderer process affect JavaScript running in the chrome process? The answer is that the renderer can communicate with the chrome process via various interfaces. This second vulnerability exists in built-in JavaScript code that runs in the fully privileged parent process, also known as the chrome process (not to be confused with Google’s Chrome browser). For the sandbox escape part of the exploit, the researcher used a second prototype pollution vulnerability. Mozilla fixed this vulnerability along with the first one in Firefox 100.0.2 via Mozilla Foundation Security Advisory 2022-19.Īs described in the previous post, the exploit compromised the renderer by leveraging a prototype pollution vulnerability in some built-in JavaScript code that executes in the renderer process. This vulnerability is known as CVE-2022-1529 and is tracked as ZDI-22-798 on the Zero Day Initiative advisory page. In this blog post, we discuss a second prototype pollution vulnerability that allowed the execution of attacker-controlled JavaScript in the privileged parent process, escaping the sandbox.
In modern browser architecture design, compromising the renderer gets us just half the way there, since the sandbox prevents further damage. In the first part of this series, we reviewed how Pwn2Own contestant Manfred Paul was able to compromise the Mozilla Firefox renderer process via a prototype pollution vulnerability in the await implementation.
0 kommentar(er)
