Chrome: Interface ID reuse leading to memory corruption in IPC::ChannelAssociatedGroupController

We discussed this vulnerability during Episode 112 on 18 January 2022

Basic idea is that the identifier pulled out of a message can point to a different handler between the initial check to redirect the message to the proper “sequence” and that sequence finding the proper endpoint/handler for it.

The flow is that a message comes in on one sequence (A), but the message is for an endpoint on another sequence (B). So A creates a task for B, to handle the message. The handler there just looks up the proper endpoint for the message using an identifier from the original message and calls that identified endpoint.

The problem is that even if A ensures that the endpoint belongs to B when it creates the task and tells B about the message, the endpoint for that identifier can change between task creation and B’s lookup of the endpoint. Leading to the wrong sequence handling the message, which I assume can lead to race condition style issues but I don’t have much knowledge of Chrome internals to comment on that.

The overall issue reminds me of sort-of pid reuse attacks where you have an identifier that code might assume always points to the same thing, not realizing that other programs might start using that pid without your program knowing, and I think thats the main idea to take away here, don’t trust that identifiers won’t be changed out from under you if they are not unique.