Bugzilla

My analysis is that this is just a use-after-free and not specifically a sandbox escape. None the less, that still qualifies as a sec-high.

Many things can crash the GPU/parent processes, and these processes are designed to crash. This by itself doesn't mean this bug is some sort of sandbox escape. If crashing the GPU process in itself can lead to a sandbox escape, then that's a separate security issue that needs to be filed elsewhere as a follow-up bug.

There are plenty of asserts everywhere in the GPU process that would really be trivial to trigger, so it's not unique to this trigger here. But, we still lack proof of any mechanism of sandbox escape. If we had the proof, I'd rather that be addressed as a follow-up, because it represents a larger engineering issue with the GPU process that is best not to conflate with this bug.

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.

Many things can crash the GPU/parent processes, and these processes are designed to crash, and crash safely without taking down the browser. This by itself doesn't mean this bug is some sort of sandbox escape. If crashing the GPU process in itself can lead to a sandbox escape, then that's a separate security issue that needs to be filed elsewhere as a follow-up bug.

If there was a larger exploit here, it would have to happen as a consequence of using the corrupted memory of the freed DrawTarget, which still remains in the GPU/parent processes. That has not necessarily been demonstrated, but is conceivable as a potential exploit.

There are plenty of asserts everywhere in the GPU process that would really be trivial to trigger, so it's not unique to this trigger here and cause a release crash. But, we still lack proof of any mechanism of sandbox escape as a result of a release crash. If we had the proof of a larger issue with GPU process fallbacks, I'd rather that be addressed as a follow-up, because it represents a larger engineering issue with the GPU process that is best not to conflate with this bug.

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.

Many things can crash the GPU/parent processes, and these processes are designed to crash, and crash safely without taking down the browser. This by itself doesn't mean this bug is some sort of sandbox escape. If crashing the GPU process in itself can lead to a sandbox escape, then that's a separate security issue that needs to be filed elsewhere as a follow-up bug.

If there was a larger exploit here, it would have to happen as a consequence of using the corrupted memory of the freed DrawTarget, which still remains in the GPU/parent processes. That has not been demonstrated, but is conceivable as a potential exploit.

There are plenty of asserts everywhere in the GPU process that would really be trivial to trigger, so it's not unique to this trigger here and cause a release crash, and I do not believe it warrants focusing on this bug as any type of sandbox escape, or else you would have to treat every single release assert in the GPU process as a sandbox escape (which to my knowledge it is not). But, we still lack proof of any mechanism of sandbox escape as a result of a release crash. If we had the proof of a larger issue with GPU process fallbacks, I'd rather that be addressed as a follow-up, because it represents a larger engineering issue with the GPU process that is best not to conflate with this bug.

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.

Many things can crash the GPU/parent processes, and these processes are designed to crash, and crash safely without taking down the browser. This by itself doesn't mean this bug is some sort of sandbox escape. If crashing the GPU process in itself can lead to a sandbox escape, then that's a separate security issue that needs to be filed elsewhere as a follow-up bug.

If there was a larger exploit here, it would have to happen as a consequence of using the corrupted memory of the freed DrawTarget, which still remains in the GPU/parent processes. That has not been demonstrated, but is conceivable as a potential exploit.

There are plenty of asserts everywhere in the GPU process that would really be trivial to trigger, so it's not unique to this trigger here and cause a release crash, and I do not believe it warrants focusing on this bug as any type of sandbox escape, or else you would have to treat every single release assert in the GPU process as a sandbox escape (which to my knowledge it is not).

But, we still lack proof of any mechanism of sandbox escape as a result of a release crash. If we had the proof of a larger issue with GPU process fallbacks, I'd rather that be addressed as a follow-up, because it represents a larger engineering issue with the GPU process that is best not to conflate with this bug.

My analysis is that this is just a use-after-free and not 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.

Many things can crash the GPU/parent processes, and these processes are designed to crash, and crash safely without taking down the browser. This by itself doesn't mean this bug is some sort of sandbox escape. If crashing the GPU process in itself can lead to a sandbox escape, then that's a separate security issue that needs to be filed elsewhere as a follow-up bug.

If there was a larger exploit here, it would have to happen as a consequence of using the corrupted memory of the freed DrawTarget, which still remains in the GPU/parent processes. That has not been demonstrated, but is conceivable as a potential exploit.

There are plenty of asserts everywhere in the GPU process that would really be trivial to trigger, so it's not unique to this trigger here and cause a release crash, and I do not believe it warrants focusing on this bug as any type of sandbox escape, or else you would have to treat every single release assert in the GPU process as a sandbox escape (which to my knowledge it is not).

But, we still lack proof of any mechanism of sandbox escape as a result of a release crash. If we had the proof of a larger issue with GPU process fallbacks, I'd rather that be addressed as a follow-up, because it represents a larger engineering issue with the GPU process that is best not to conflate with this bug.