Migration

One of the things that is different about kernel-mode vulnerabilities in relation to user-mode vulnerabilities is that the Windows kernel operates internally at specific Interrupt Request Levels, also known as IRQLs. The purpose of IRQLs are to allow the kernel to mask off interrupts that occur at a lower level than the one that the processor is currently executing at. This ensures that a piece of code will run un-interrupted by threads and hardware/software interrupts that have a lesser priority. It also allows the kernel to define a driver model that ensures that certain operations are not performed at critical processor IRQLs. For instance, it is not permitted to block at any IRQL greater than or equal to DISPATCH_LEVEL. It is also not permitted to reference pageable memory that has been paged out at greater than or equal to DISPATCH_LEVEL.

The reason this is important is because the IRQL that the processor will be running at when a kernel-mode vulnerability is triggered is highly dependent upon the area in which the vulnerability occurs. For this reason, it may be generally necessary to have an approach for either directly or indirectly lowering the IRQL in such a way that permits the use of some of the common driver support routines. As an example, it is not possible to call nt!KeInsertQueueApc at an IRQL greater than PASSIVE_LEVEL.

This section will focus on describing methods that could be used to implement migration payloads. The purpose of a migration payload is to migrate the processor to an IRQL that will allow payloads to make use of pageable memory and common driver support routines as described above. The techniques that can be used to do this vary in terms of stability and simplicity. It's generally a matter of picking the right one for the job.

Subsections

Next: Direct IRQL Adjustment Up: Payload Components Previous: Payload Components Contents