Bugzilla

(In reply to Andrew McCreight [:mccr8] from comment #11)
> (In reply to Lee Salzman [:lsalzman] from comment #10)
> > My analysis is that this is just a use-after-free and not specifically a sandbox escape. I believe any actual nefarious consequences of using a freed DrawTarget in the GPU or parent process will be confined to those processes.
> 
> It is a sandbox escape because a lower privileged process can cause a UAF in a higher privileged process. The way this would be exploited would be by a compromised content process sending some other message after the `RecordEventSelfSkipFlushTransform` call that causes the free to happen that allocates an object with the same size as the freed object, but with an attacker-controlled value. Then, a later message could cause a method to be called on the dead `mCurrentDT` pointer. DrawTarget has virtual methods, so its first word will be a vtable pointer. Thus if the first word of the object the attacker gets allocated in the parent process is an attacker controlled integer then it could make it do all sorts of things. Exploiting this kind of issue is not trivial, but it is a well-studied problem. You can see bug 1758070 for an example of a use-after-free in the parent process that was exploited by attackers as part of a zero day on Firefox users.

To be clear, this would only happen in the situation that the platform doesn't support the GPU process. If we ever are in a situation where the GPU process is used, then we stop remoting when we fall back to the parent process, was my understanding. So only some platforms would be impacted that don't currently employ the GPU process.

(In reply to Andrew McCreight [:mccr8] from comment #11)
> (In reply to Lee Salzman [:lsalzman] from comment #10)
> > My analysis is that this is just a use-after-free and not specifically a sandbox escape. I believe any actual nefarious consequences of using a freed DrawTarget in the GPU or parent process will be confined to those processes.
> 
> It is a sandbox escape because a lower privileged process can cause a UAF in a higher privileged process. The way this would be exploited would be by a compromised content process sending some other message after the `RecordEventSelfSkipFlushTransform` call that causes the free to happen that allocates an object with the same size as the freed object, but with an attacker-controlled value. Then, a later message could cause a method to be called on the dead `mCurrentDT` pointer. DrawTarget has virtual methods, so its first word will be a vtable pointer. Thus if the first word of the object the attacker gets allocated in the parent process is an attacker controlled integer then it could make it do all sorts of things. Exploiting this kind of issue is not trivial, but it is a well-studied problem. You can see bug 1758070 for an example of a use-after-free in the parent process that was exploited by attackers as part of a zero day on Firefox users.

To be clear, this would only happen in the situation that the platform doesn't support the GPU process by default. If we ever are in a situation where the GPU process is used by default, then we stop remoting when we fall back to the parent process, was my understanding, because then we punt to SWGL which also disables Accelerated Canvas2D.

(In reply to Andrew McCreight [:mccr8] from comment #11)
> (In reply to Lee Salzman [:lsalzman] from comment #10)
> > My analysis is that this is just a use-after-free and not specifically a sandbox escape. I believe any actual nefarious consequences of using a freed DrawTarget in the GPU or parent process will be confined to those processes.
> 
> It is a sandbox escape because a lower privileged process can cause a UAF in a higher privileged process. The way this would be exploited would be by a compromised content process sending some other message after the `RecordEventSelfSkipFlushTransform` call that causes the free to happen that allocates an object with the same size as the freed object, but with an attacker-controlled value. Then, a later message could cause a method to be called on the dead `mCurrentDT` pointer. DrawTarget has virtual methods, so its first word will be a vtable pointer. Thus if the first word of the object the attacker gets allocated in the parent process is an attacker controlled integer then it could make it do all sorts of things. Exploiting this kind of issue is not trivial, but it is a well-studied problem. You can see bug 1758070 for an example of a use-after-free in the parent process that was exploited by attackers as part of a zero day on Firefox users.

To be clear, this would only happen in the situation that the platform doesn't support the GPU process by default. If we ever are in a situation where the GPU process is used by default (the assumption being we can only accelerate anything in the GPU process), then we stop remoting canvas when we fall back to the parent process, because then we punt from HW-WR to SW-WR which also disables Accelerated Canvas2D.

(In reply to Andrew McCreight [:mccr8] from comment #11)
> (In reply to Lee Salzman [:lsalzman] from comment #10)
> > My analysis is that this is just a use-after-free and not specifically a sandbox escape. I believe any actual nefarious consequences of using a freed DrawTarget in the GPU or parent process will be confined to those processes.
> 
> It is a sandbox escape because a lower privileged process can cause a UAF in a higher privileged process. The way this would be exploited would be by a compromised content process sending some other message after the `RecordEventSelfSkipFlushTransform` call that causes the free to happen that allocates an object with the same size as the freed object, but with an attacker-controlled value. Then, a later message could cause a method to be called on the dead `mCurrentDT` pointer. DrawTarget has virtual methods, so its first word will be a vtable pointer. Thus if the first word of the object the attacker gets allocated in the parent process is an attacker controlled integer then it could make it do all sorts of things. Exploiting this kind of issue is not trivial, but it is a well-studied problem. You can see bug 1758070 for an example of a use-after-free in the parent process that was exploited by attackers as part of a zero day on Firefox users.

To be clear, this would only happen in the situation that the platform doesn't support the GPU process by default, currently only macOS and Linux don't support it. If we ever are in a situation where the GPU process is used by default (the assumption being we can only accelerate anything in the GPU process), then we stop remoting canvas when we fall back to the parent process, because then we punt from HW-WR to SW-WR which also disables Accelerated Canvas2D.