Privilege Context Switching Error

Draft Base
Structure: Simple
Description

This vulnerability occurs when an application fails to properly manage user permissions while moving between different security contexts, potentially allowing unauthorized actions.

Extended Description

Think of this as a security guard who forgets to check their keys when moving between restricted areas. In software, this happens when a process or thread switches between different privilege levels—like going from a low-privilege user mode to a high-privilege kernel mode, or when handling data from different trust zones—but doesn't correctly reset or validate its access rights. The system might carry over elevated permissions from a previous task, creating a window where an attacker can execute code or access data they shouldn't have. For developers, the core issue is a broken trust boundary during state transitions. Common pitfalls include temporarily raising privileges for a specific task but failing to drop them immediately afterward, or incorrectly assuming a new context inherits a safe default. To prevent this, always adopt the principle of least privilege explicitly during context switches: deliberately set the required permissions for the new operation and never rely on implicit state. Audit any code that changes execution context, such as system calls, callback handlers, or data parsers, to ensure privilege cleanup is mandatory and fail-safe.

Common Consequences 1
Scope: Access Control

Impact: Gain Privileges or Assume Identity

A user can assume the identity of another user with separate privileges in another context. This will give the user unauthorized access that may allow them to acquire the access information of other users.

Potential Mitigations 3
Phase: Architecture and DesignOperation
Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
Phase: Architecture and DesignOperation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
Phase: Architecture and Design

Strategy: Separation of Privilege

Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.
Observed Examples 4
CVE-2002-1688Web browser cross domain problem when user hits "back" button.
CVE-2003-1026Web browser cross domain problem when user hits "back" button.
CVE-2002-1770Cross-domain issue - third party product passes code to web browser, which executes it in unsafe zone.
CVE-2005-2263Run callback in different security context after it has been changed from untrusted to trusted. * note that "context switch before actions are completed" is one type of problem that happens frequently, espec. in browsers.
References 2
Writing Secure Code
Michael Howard and David LeBlanc
Microsoft Press
04-12-2002
ID: REF-7
Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Modes of Introduction
Architecture and Design
Implementation
Operation
Related Weaknesses
Taxonomy Mapping
  • PLOVER
Notes
Research GapThis concept needs more study.