CWE-368, Context Switching Race Condition, describes a product that performs a series of non-atomic actions to switch between contexts that cross privilege or other security boundaries. A race lets an attacker change or misrepresent the product's behavior during the switch.
MITRE says this is commonly seen in web browser vulnerabilities. It is most relevant to people who build browsers, embedded web views, and any software that moves between trust levels in several steps.
How it happens
A switch between contexts is rarely one step. A browser, for example, starts navigation, updates what the user sees, tears down the old page and sets up the new one. Each step is separate. If something can happen between the steps, then an action can run with one domain's resources and another domain's trust level.
The record's examples show the variety.
- CVE-2004-2260: a browser updated the address bar as soon as the user clicked a link, instead of when the page had loaded. An attacker could redirect to a spoofed page while the address bar already showed the target.
- CVE-2004-0191: a browser ran JavaScript events in the context of a new page while it was still loading, allowing interaction with the previous page.
- CVE-2009-1837: a chain in which improper handling of a page transition while an applet was loading led to a race condition.
What an attacker gains
MITRE lists integrity and confidentiality: modifying and reading application data. In the browser setting, that can mean running script in the wrong origin, or showing the user a misleading location so they trust a page they should not.
How to find it
MITRE notes static analysis can find some instances. Design review does most of the work here.
- Map every context switch in your product and list its steps in order.
- For each gap between steps, ask what an attacker could trigger there.
- Look for UI state that updates before the underlying state has actually changed.
How to fix it
MITRE lists no mitigations for this entry. The fix follows from the definition: make the switch behave as one atomic step with respect to security.
- Change the security context and the visible state together, or hold input and events until both are done.
- Cancel or queue pending events from the old context when a switch begins.
- Never run code from the incoming context with the privileges of the outgoing one, or the reverse.
- Update indicators the user relies on, like an address bar, only after the new state is real.
If you ship browser engines or web views, keep them current. A free scan at gold.safeguard.sh/scan checks a dependency file in your browser, with no login, up to 100 dependencies, and the file stays on your machine.
Quick check
Why are browsers the typical home of this weakness?
Navigation moves from one domain's trust level to another in several non-atomic steps, and actions in the gaps can run with the wrong domain's resources.
Sources
- MITRE CWE-368: https://cwe.mitre.org/data/definitions/368.html
