Common Attack Pattern Enumeration and Classification
A Community Resource for Identifying and Understanding Attacks
Attackers can sometimes hijack a privileged thread from the underlying system through synchronous (calling a privileged function that returns incorrectly) or asynchronous (callbacks, signal handlers, and similar) means.
Having done so, the Attacker may not only likely access functionality the system's designer didn't intend for them, but they may also go undetected or deny other users essential service in a catastrophic (or insidiously subtle) way.
Attacker targets an application written using Java's AWT, with the 1.2.2 era event model. In this circumstance, any AWTEvent originating in the underlying OS (such as a mouse click) would return a privileged thread. The Attacker could choose to not return the AWT-generated thread upon consuming the event, but instead leveraging its privilege to conduct privileged operations.
Skill or Knowledge Level: High
Hijacking a thread involves knowledge of how processes and threads function on the target platform, the design of the target application as well as the ability to identify the primitives to be used or manipulated to hijack the thread.
None: No specialized resources are required to execute this type of attack. The attacker needs to be able to latch onto a privileged thread.
The Attacker does, however, need to be able to program, compile, and link to the victim binaries being executed so that it will turn control of a privileged thread over to the Attacker's malicious code. This is the case even if the attacker conducts the attack remotely.
The attacker may attach a debugger to the executing process and observe the spawning and cleanup of threads, as well as the switches in privilege levels.
The attacker can also observe the environment variables, if any, that affect executing threads and modify them in order to observe their effect on the execution.
Application Architects must be careful to design callback, signal, and similar asynchronous constructs such that they shed excess privilege prior to handing control to user-written (thus untrusted) code.
Application Architects must be careful to design privileged code blocks such that upon return (successful, failed, or unpredicted) that privilege is shed prior to leaving the block/scope.
Only those constructs within the application that cannot execute without elevated privileges must be granted additional privileges. Often times, the entire function or the entire process is granted privileges that are usually not necessary.
The callee must ensure that additional privileges are shed before returning to the caller. This avoids pinning the responsibility on an inadvertent caller who may not have a clue about the innards of the callee.
More information is available — Please select a different filter.