Copy Link
Add to Bookmark
Report
Phrack Inc. Volume 12 Issue 65 File 04
==Phrack Inc.==
Volume 0x0c, Issue 0x41, Phile #0x04 of 0x0f
|=-----------------------------------------------------------------------=|
|=---=[ Stealth hooking : Another way to subvert the Windows kernel ]=---=|
|=-----------------------------------------------------------------------=|
|=--------------------=[ by mxatone and ivanlef0u ]=---------------------=|
|=-----------------------------------------------------------------------=|
1 - Introduction on anti-rookits technologies and bypass
1.1 - Rookits and anti-rootkits techniques
1.2 - About kernel level protections
1.3 - Concept key: use kernel code against itself
2 - Introducing stealth hooking on IDT.
2.1 - How Windows manage hardware interrupts
2.1.1 - Hardware interrupts dispatching on Windows
2.1.2 - Hooking hardware IT like a ninja
2.1.3 - Application 1 : Kernel keylogger
2.1.4 - Application 2 : NDIS incoming packets sniffer
2.2 - Conclusion about stealth hooking on IDT
3 - Owning NonPaged pool using stealth hooking
3.1 - Kernel allocation layout review
3.1.1 - Difference between Paged and NonPaged pool
3.1.2 - NonPaged pool tables
3.1.3 - Allocation and free algorithms
3.2 - Getting code execution abusing allocation code
3.2.1 - Data corruption of MmNonPagedPoolFreeListHead
3.2.2 - Expend it for every size
3.3 - Exploit our position
3.3.1 - Generic stack redirection
3.3.2 - Userland process code injection
4 - Detection
5 - Conclusion
6 - References
---[ 1 - Introduction on anti-rookits technologies and bypass
Nowadays rootkits and anti-rootkits are becoming more and more important
into the IT security landscape. Loved by some, hated by others, rootkits
can be considered as the holy grail of backdoors : stealthy, little,
close to hardware, ingenious, vicious... Their control over a computer
locally or remotely make them the best choice for an attacker.
Anti-rootkits try to detect and eradicate those malicious programs.
Rk techniques and complexity are evolving fast and today developing a rk or
anti-rk is a very hard mission.
This paper deals about rootkits on Windows platform. More precisely about
new kind of hijacking techniques that can be applied to the Windows kernel.
Readers are assumed to be aware about rootkits techniques on Windows.
----[ 1.1 - Rootkits and anti-rootkits technics
A rootkit hijacks an operating system's behavior. In order to achieve this
task, it can simply modify the operating system's binaries but that's not
very stealthy. Most rk's use hooks on important functions and change theirs
results. A basic hook redirects execution flow by changing function start
or a function pointer but there is no single way to hook a routine. The
most common example is the SSDT (System Service Descriptor Table), this
table contains the syscall list which is a set of functions pointers. If
you can modify a pointer in this table, you are able to control the
behavior of one function. That's an example of how rootkits proceed,
obviously there is a lot of critical areas that can be controlled by an
attacker.
Anti-rootkits try to check those areas, but the task is very hard. Most of
the time, anti-rk software makes a comparison between the memory image of
the program and its binary on the disk or verify some function pointer
tables to see if something has changed.
That's how the war between rk-makers and anti-rk-junkies began, trying
to find the best way, the best area, for hooking critical operating
system features. On Windows those following areas are often used by
rootkits :
- SSDT (kernel syscalls table) and shadow SSDT (win32k syscall table) are
the simplest solution.
- MSR (Model Specific Registers) can be modified by a rootkit. On Windows
the MSR_SYSENTER_EIP is used by the assembly instructions 'sysenter' to
enter into ring0 mode. Hijacking this MSR allow an attacker to control
the system.
- MajorFunctions are functions used by drivers for I/O processing with
others devices, hooking those functions can be useful for a rootkit.
- IDT (Interrupt Descriptor Table) is table used by the system for
handling exceptions and interruptions.
Another kind of techniques has appeared. By accessing to the kernel
objects a rootkit can easily change information about processes, threads,
loaded modules and other stuff. Those techniques are called DKOM (Direct
Kernel Object Manipulation). For example, the Windows kernel maintains a
double linked list called PsActiveProcessList (EPROCESS structures)
containing information about running processes. Unlink one of them and
your process will disappear from process lists like task manager, whereas
the process is still running.
To block those kernel objects modifications, anti-rk checks other
sections. For processes, they used to read the PspCidTable which
has a table of PID (Process IDentifier) and TID (Thread IDentifier).
A comparison between this table and PsActiveProcessList shows hidden
processes. Against those attacks anti-rk tools have to find others
sections and tricks to detect altered objects.
One of the first paper about Windows stealth was written by Holy Father,
"Invisibility on NT boxes" [1]. With this paper came one of the first
public implementations of a rootkit with a ring0 driver, Hacker
Defender [2], coded by Holy Father and Ratter of the famous VXing mag 29A
[3]. This driver was able to elevate process rights using token
manipulation. The rest of the rootkit uses user-land hooks to perform files
and registry hiding, process infection with dll injection. A good example
of a full ring0 rootkit is NT Rootkit of Greg Hoglund [4], this driver uses
SSDT hooks to perform stealth operation. It registers a Filter Device
Object above the NTFS file system and above the keyboard device for
filtering IRP (I/O Request Packets). It also provides a NDIS protocol
driver to hide communication on the network. Even if this rk was written
for NT 4.0 and Win2K it's a perfect example for beginners.
After came more advanced ring0 rk like FU [5], written by Fuzen_op and its
improvement FUto published in the famous technical journal Uninformed [6].
Vista improvement on driver verification introduces new rootkits mostly
based on hardware features. Like BootRoot [7] and Pixie [8] by Eeye
loaded before any protection. Finally Joanna Rutkowska with her Blue
Pill [9] used virtualization technology to create layer between the
operating system and the hardware.
In the wild the rk are used most of the time for lame mail spamming or
botnets. They often use old techniques but some of them are interesting
like Rustock [10] series or StormWorm [11] and the MBR rootkit [12]. They
implement a lot of tricks as ADS (Alternate Data Stream), code obfuscation,
anti-debug, anti-VM or polymorphic code. The goal is not only subverting
the kernel but also slow down their analysis and make them harder to
defeat.
Even if the technology used by rootkits are more and more sophisticated,
the underground community is still developing POCs to improve current
techniques. Unreal [13] and AK992 [14] are both great examples. The first
uses an ADS and a NTFS MajorFunctions hooking to hide itself, the second
checks IRP completion when sended to disk's devices. You can find plenty
examples of rootkit techniques on rootkit.com.
Finally, this part would not be complete if we don't speak about anti-rk.
The most famous is Rk Unhooker by MP_ART & EP_X0FF and their team UG North.
Others anti-rk are DarkSpy [15] by CardMagic, IceSword [16] by pjf and
Gmer [17].
----[ 1.2 - About kernel level protections
When we talk about protection, we must notice where the protection takes
place into the system. A protection has an advantage on an attack only
if it operates from a higher level. Protections like PaX or Exec Shield
are efficient because they protecting userland from kernel.
Protections like PatchGuard and other HIPS also protect the system
integrity but as far as an attacker can find a way to attack those
protections at their own level they will be useless. A protection is
reliable only if it can't be corrupted by an attacker. Assuming an
attacker find a way to inject code into the protection and you can
consider that your b0x is dead.
That's why PatchGuard isn't so efficient [18]. But we know that disabling
or destroying a protection is very noisy. No, the best way is to fly under
the radar by working with special objects and events that cannot be
checked because of their volatility.
In June 2006, Greg Hoglund presented the concept of KOH (Kernel Object
Hooking) [19]. A new way of detouring code execution, you don't have to
modify static code section but rather you work on dynamic allocated
structures/codes like DPC (Deferred Procedure Calls). For protections,
it's hard to find and verify those areas due to their instabilities.
Others cool objects are IRP. They are the object used by the Windows
kernel I/O manager to communicate with devices. Each I/O operation on
hardware generates an IRP, sycalls send IRP to a driver through his
device. In general a driver owns several devices; one of them is used to
communique with the userland by using IOCTL and others devices are
managing IRP by filtering them or performing a requested task.
IRP are sent to a driver using its MajorFunctions table. This table
includes the different functionalities provided by the driver. You can
check the result returned by a MajorFunction by installing a completion
routine on an IRP. They are very volatile objects; controlling and
checking them is very hard.
In fact, if you want to check everything you would need to completely
redesign operating system architecture. So keep in mind that protection
cannot be everywhere at every time and we will demonstrate it in the
following parts.
----[ 1.3 - Concept key: use kernel code against itself
The idea behind this paper is exploiting kernel code. Exploitation is
possible because input defines code behavior. Submitting a crafted input
to a vulnerable software can leads into code execution. Dangerous input is
of course defined by your target. Kernel space contains more exploitation
scenarios because you can change its environment. A rootkit can not
change basic inputs as arguments. But it can change the environment around
a code. Heap exploitation techniques such as unlinking is a perfect
example. By changing a memory block structure, you are able to overwrite
4 bytes. Some techniques can even change next allocated block address [20].
It does work because a program trusts those information. In kernel, you
have a total control on the environment. Also completely checking the
kernel is bad for performance and totally impossible.
Changing code environment has been used successfully for the phide2
rootkit [21] technique. This rootkit can hide threads without hooking
Windows scheduler which is impressive. As it relies on code behavior, it
needs strong reverse knowledge. It extends this concept into unknown
operating system behaviors. Generic protections are based on generic
assumptions. Such as checking only driver images for code hooks. These
days operating systems design is against those protections and requires
advanced software rootkit techniques.
---[ 2 - Introducing stealth hooking on IDT
Let's introduce our concept about stealth hooking with an example based on
IDT. First we will see what is the IDT and its purpose. Then we will
discuss about hardware interrupts and how Windows deals with them.
IDT (Interrupt Descriptor Table) is a CPU specific linear table localized
in kernel-land. IDT can be read with ring3 privilege level but you must
have ring0 privilege if you want to write into it. IDT is composed of 256
entries of KIDTENTRY structures and you can use the Kernel Debugger (KD)
included into the Debugging Tools for Windows [22] to see the definition
of an IDT entry.
kd> dt nt!_KIDTENTRY
+0x000 Offset : Uint2B
+0x002 Selector : Uint2B
+0x004 Access : Uint2B
+0x006 ExtendedOffset : Uint2B
Here we don't want to (re)explain the architecture of the IDT so we advise
you to read Kad's paper published in Phrack 59 about IDT and about how it
works [23].
The first 32 entries of IDT are reserved by the CPU for exceptions. Others
are use to handle hardware interrupts and special system events.
Here is a dump of the first 64 entries of the Windows' IDT.
kd> !idt -a
Dumping IDT:
00: 804df350 nt!KiTrap00
01: 804df4cb nt!KiTrap01
02: Task Selector = 0x0058
03: 804df89d nt!KiTrap03
04: 804dfa20 nt!KiTrap04
05: 804dfb81 nt!KiTrap05
06: 804dfd02 nt!KiTrap06
07: 804e036a nt!KiTrap07
08: Task Selector = 0x0050
09: 804e078f nt!KiTrap09
0a: 804e08ac nt!KiTrap0A
0b: 804e09e9 nt!KiTrap0B
0c: 804e0c42 nt!KiTrap0C
0d: 804e0f38 nt!KiTrap0D
0e: 804e164f nt!KiTrap0E
0f: 804e197c nt!KiTrap0F
10: 804e1a99 nt!KiTrap10
11: 804e1bce nt!KiTrap11
12: 804e197c nt!KiTrap0F
13: 804e1d34 nt!KiTrap13
14: 804e197c nt!KiTrap0F
15: 804e197c nt!KiTrap0F
16: 804e197c nt!KiTrap0F
17: 804e197c nt!KiTrap0F
18: 804e197c nt!KiTrap0F
19: 804e197c nt!KiTrap0F
1a: 804e197c nt!KiTrap0F
1b: 804e197c nt!KiTrap0F
1c: 804e197c nt!KiTrap0F
1d: 804e197c nt!KiTrap0F
1e: 804e197c nt!KiTrap0F
1f: 804e197c nt!KiTrap0F
20: 00000000
21: 00000000
22: 00000000
23: 00000000
24: 00000000
25: 00000000
26: 00000000
27: 00000000
28: 00000000
29: 00000000
2a: 804deb92 nt!KiGetTickCount
2b: 804dec95 nt!KiCallbackReturn
2c: 804dee34 nt!KiSetLowWaitHighThread
2d: 804df77c nt!KiDebugService
2e: 804de631 nt!KiSystemService
2f: 804e197c nt!KiTrap0F
30: 806f3d48 hal!HalpClockInterrupt
31: 80dd816c i8042prt!I8042KeyboardInterruptService (KINTERRUPT 80dd8130)
32: 804ddd04 nt!KiUnexpectedInterrupt2
33: 80dd3224 serial!SerialCIsrSw (KINTERRUPT 80dd31e8)
34: 804ddd18 nt!KiUnexpectedInterrupt4
35: 804ddd22 nt!KiUnexpectedInterrupt5
36: 804ddd2c nt!KiUnexpectedInterrupt6
37: 804ddd36 nt!KiUnexpectedInterrupt7
38: 806edef0 hal!HalpProfileInterrupt
39: 80f0827c ACPI!ACPIInterruptServiceRoutine (KINTERRUPT 80f08240)
3a: 80dc67cc vmsrvc+0x1C16 (KINTERRUPT 80dc6790)
3b: 80df6414 NDIS!ndisMIsr (KINTERRUPT 80df63d8)
3c: 80de040c i8042prt!I8042MouseInterruptService (KINTERRUPT 80de03d0)
3d: 804ddd72 nt!KiUnexpectedInterrupt13
3e: 80ed78a4 atapi!IdePortInterrupt (KINTERRUPT 80ed7868)
3f: 80f01dd4 atapi!IdePortInterrupt (KINTERRUPT 80f01d98)
40: 804ddd90 nt!KiUnexpectedInterrupt16
[...]
This dump represents a typical Windows IDT, you can see the IDT entries
index followed by the address of the handler and this name. The first 32
entries are filled by KiTrap* functions that manage exceptions. The rest
of the table is left to the system, you can see specials system interrupts
like KiSystemService and KiCallbackReturn and handlers used by drivers
like I8042KeyboardInterruptService or I8042MouseInterruptService.
----[ 2.1 - How Windows manage hardware interrupts
When we talk about interrupts we must introduce the concept of IRQL
(Interrupt ReQuest Level). The kernel represents IRQLs internally as a
number from 0 through 31 on x86 with higher numbers representing higher
priority interrupts. Although the kernel defines the standard set of IRQLs
for software interrupts, the HAL (Hardware Abstraction Layer) maps
hardware interrupt numbers to the IRQLs.
+----------------+
31 | Highests | \
to | IRQLs | | Clock, system failure.
27 | | /
+----------------+
26 | | \
to | DEVICE_IRQL | | Hardware interrupts.
3 | | /
+----------------+
2 | DISPATCH_LEVEL | Scheduler, DPC.
+----------------+
1 | APC_LEVEL | Used when dispatching APC.
+----------------+
0 | PASSIVE_LEVEL | Threads run at this IRQL.
+----------------+
Each processor has its own IRQL. You can have a core running at an IRQL=
DISPATCH_LEVEL whereas another is running at PASSIVE_LEVEL. In fact IRQL
represents the "mask ability" of the current running code. Interrupts from
a source with an IRQL above the current level interrupt the processor,
whereas interrupts from sources with IRQLs equal to or below the current
level are masked until an executing thread decrease the IRQL.
Some system components are not accessible when code is running at
IRQL>=DISPATH_LEVEL. Accessing to paged memory (memory which can be
swapped on disk) is impossible and lots of kernel functions cannot be used.
Hardware interrupts are asynchronous and reached by external peripherals.
For example when you hit a key, your keyboard device sends an IRQ
(Interrupt ReQuest) routed by the Southbridge [24] on your interrupt
controller through the Northbridge [25]. The Southbridge is a chip that can
be described like a I/O controller hub. This chip receives all the I/O
externals interrupt and send them to the Northbridge. The Northbridge is
directly connected to your memory and high speed graphic bus also to your
CPU. This chip is also known as the memory controller hub.
On most x86 systems we find a chipset called i82489, Advanced Programmable
Interrupt Controller (APIC). The APIC is composed by 2 main components, a
I/O APIC, one per CPU, and a LAPIC (Local APIC) on each core. I/O APIC
uses a routing algorithm to dispatch an interrupt on the best adapted core.
According to the principle of locality, I/O APIC will deliver the device
interrupt on the core which handled it the previous time [26].
After this LAPIC translates the IRQ to an 8-bits value, an interrupt
vector. This interrupt vector represents IDT's entry index associated with
the handler. When the core is ready to handle the interrupt, its
instruction flow is redirected on the IDT entry.
IDT IDT IDT IDT
1 2 3 4
+---+ +---+ +---+ +---+
| | | | | | | |
|---| |---| |---| |---|
| | | | | | | |
|---| |---| |---| |---|
| | | | | | | |
+---+ +---+ +---+ +---+
| | | |
+--------+ +--------+ +--------+ +--------+
| | | | | | | |
| core 1 | | core 2 | | core 3 | | core 4 |
| | | | | | | |
+--------+ +--------+ +--------+ +--------+
| LAPIC | | LAPIC | | LAPIC | | LAPIC |
+---+----+ +---+----+ +---+----+ +---+----+
| | | |
| | | |
<---+--------------+------+-------+-------------+----->
Interrupt | Processor system bus
Messages |
|
|
External +------+------+
Interrupts | |
---------------> I/O APIC |
| |
+-------------+
-----[ 2.3.1 Hardware interrupts dispatching on Windows
On Windows, the interrupt handler isn't executed immediately, there is a
code template first. This template is implemented in the function
KiInterruptTemplate and does two things. First, it saves the current
core state in the stack and dispatches code flow to the right "interrupt
dispatcher".
When a interrupt is raised, after the core status core is saved, code flow
is transferred to the interrupt handler as defined in the IDT. In fact
each interrupt handler in the IDT points to a KiInterruptTemplate
routine [27]. KiInterruptTemplate will call KiInterruptDispatch which
performs the following operations :
- Acquire the service routine spinlock.
- Raise IRQL to DEVICE_IRQL, the IRQL of a given interrupt vector is
calculated by subtracting the interrupt vector from 27d.
- Call the interrupt handler, an ISR (Interrupt Service Routine).
- Lower IRQL.
- Release the service routine spinlock.
For example, the keyboard device ISR is I8042KeyboardInterruptService.
ISR are routines for handling interrupts like top-halves in the linux
kernel. According to the WDK (Windows Driver Kit), the ISR must do
whatever is appropriate to the device to dismiss the interrupt. Then, it
should do only what is necessary to save stage and queue a DPC. It means it
interruption management will take place on a lower IRQL than during ISR
execution. The I/O processing is done into the DPC.
DPC (Deferred Procedure Call) are equivalent of bottom-halves in linux.
DPC works at IRQL DISPATCH_LEVEL, lower than the ISR's IRQL. In fact the
ISR will queue a DPC to process the entire interrupt at a lower IRQL in
order to avoid the core preemption taking too much time. For the keyboard
the DPC is I8042KeyboardIsrDpc. Here a figure to sum up the interrupt
processing :
+-------------------------+
Hardware Interrupt /----> Here we are at |
| | | IRQL=DEVICE_LEVEL |
| | | The KiInterruptDispatch |
/---> IDT ---\ | | routine calls the ISR. |
| | | |
| | | ISR handles interrupt |
+-----------------------+ | | and queue a DPC for |
| KiInterruptTemplate ------/ | later processing |
+-----------------------+ | |
+-------------------------+
KiInterruptDispatch receives one main argument from KiInterruptTemplate,
a pointer to an interrupt object stored in the EDI register. Interrupt
objects are defined by a KINTERRUPT structure :
kd> dt nt!_KINTERRUPT
+0x000 Type : Int2B
+0x002 Size : Int2B
+0x004 InterruptListEntry : _LIST_ENTRY
+0x00c ServiceRoutine : Ptr32 unsigned char
+0x010 ServiceContext : Ptr32 Void
+0x014 SpinLock : Uint4B
+0x018 TickCount : Uint4B
+0x01c ActualLock : Ptr32 Uint4B
+0x020 DispatchAddress : Ptr32 void
+0x024 Vector : Uint4B
+0x028 Irql : UChar
+0x029 SynchronizeIrql : UChar
+0x02a FloatingSave : UChar
+0x02b Connected : UChar
+0x02c Number : Char
+0x02d ShareVector : UChar
+0x030 Mode : _KINTERRUPT_MODE
+0x034 ServiceCount : Uint4B
+0x038 DispatchCount : Uint4B
+0x03c DispatchCode : [106] Uint4B
We retrieve in this structure, the SpinLock and the ServiceRoutine. Notice
that SynchronizeIrql contains the IRQL when the ISR will be executed.
For each entry in the IDT which handles a hardware interrupt, the
KiInterruptTemplate is contained in the DispatchCode table of the
KINTERRUPT structure.
For the keyboard device we have this KINTERRUPT :
kd> dt nt!_KINTERRUPT 80dd8130
+0x000 Type : 22
+0x002 Size : 484
+0x004 InterruptListEntry : _LIST_ENTRY [ 0x80dd8134 - 0x80dd8134 ]
+0x00c ServiceRoutine : 0xfa815495 unsigned char
->i8042prt!I8042KeyboardInterruptService+0
+0x010 ServiceContext : 0x80e2ec88
+0x014 SpinLock : 0
+0x018 TickCount : 0xffffffff
+0x01c ActualLock : 0x80e2ed48 -> 0
+0x020 DispatchAddress : 0x804da8d8 void nt!KiInterruptDispatch+0
+0x024 Vector : 0x31
+0x028 Irql : 0x1a ''
+0x029 SynchronizeIrql : 0x1a ''
+0x02a FloatingSave : 0 ''
+0x02b Connected : 0x1 ''
+0x02c Number : 0 ''
+0x02d ShareVector : 0 ''
+0x030 Mode : 1 ( Latched )
+0x034 ServiceCount : 0
+0x038 DispatchCount : 0xffffffff
+0x03c DispatchCode : [106] 0x56535554
Let's have a look at the beginning of KiInterruptTemplate :
nt!KiInterruptTemplate:
804da972 54 push esp
804da973 55 push ebp
804da974 53 push ebx
804da975 56 push esi
804da976 57 push edi
804da977 83ec54 sub esp,54h
804da97a 8bec mov ebp,esp
804da97c 89442444 mov dword ptr [esp+44h],eax
804da980 894c2440 mov dword ptr [esp+40h],ecx
804da984 8954243c mov dword ptr [esp+3Ch],edx
804da988 f744247000000200 test dword ptr [esp+70h],20000h
804da990 0f852a010000 jne nt!V86_kit_a (804daac0)
804da996 66837c246c08 cmp word ptr [esp+6Ch],8
804da99c 7423 je nt!KiInterruptTemplate+0x4f (804da9c1)
804da99e 8c642450 mov word ptr [esp+50h],fs
804da9a2 8c5c2438 mov word ptr [esp+38h],ds
804da9a6 8c442434 mov word ptr [esp+34h],es
804da9aa 8c6c2430 mov word ptr [esp+30h],gs
804da9ae bb30000000 mov ebx,30h
804da9b3 b823000000 mov eax,23h
804da9b8 668ee3 mov fs,bx
804da9bb 668ed8 mov ds,ax
804da9be 668ec0 mov es,ax
804da9c1 648b1d00000000 mov ebx,dword ptr fs:[0]
804da9c8 64c70500000000ffffffff mov dword ptr fs:[0],0FFFFFFFFh
804da9d3 895c244c mov dword ptr [esp+4Ch],ebx
804da9d7 81fc00000100 cmp esp,10000h
804da9dd 0f82b5000000 jb nt!Abios_kit_a (804daa98)
804da9e3 c744246400000000 mov dword ptr [esp+64h],0
804da9eb fc cld
804da9ec 8b5d60 mov ebx,dword ptr [ebp+60h]
804da9ef 8b7d68 mov edi,dword ptr [ebp+68h]
804da9f2 89550c mov dword ptr [ebp+0Ch],edx
804da9f5 c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
804da9fc 895d00 mov dword ptr [ebp],ebx
804da9ff 897d04 mov dword ptr [ebp+4],edi
804daa02 f60550f0dfffff test byte ptr ds:[0FFDFF050h],0FFh
804daa09 750d jne nt!Dr_kit_a (804daa18)
nt!KiInterruptTemplate2ndDispatch:
804daa0b bf00000000 mov edi,0
nt!KiInterruptTemplateObject:
804daa10 e9c3fcffff jmp nt!KeSynchronizeExecution+0x2 (804da6d8)
[...]
Remember, this code is unique for each KINTERRUPT. We said before that
KiInterruptDispatch receives its arguments from the EDI register (a
pointer to the KINTERRUPT of the interrupt). In the KiInterruptTemplate
we can see this little code :
[...]
nt!KiInterruptTemplate2ndDispatch:
804daa0b bf00000000 mov edi,0
nt!KiInterruptTemplateObject:
804daa10 e9c3fcffff jmp nt!KeSynchronizeExecution+0x2 (804da6d8)
[...]
Here we have a mov "edi, 0" and a jmp, but if we look at the
KiInterruptTemplate code contained in the keyboard's KINTERRUPT we have :
ffb72525 bf5024b7ff mov edi,0FFB72450h ; Keyboard KINTERRUPT
ffb7252a e9a9839680 jmp nt!KiInterruptDispatch (804da8d8)
Wow, instructions are modified! The kernel will dynamically changes those
2 instructions in the KiInterruptTemplate code. In EDI we find the
KINTERRUPT object and the jmp branch on KiInterruptDispatch.
Why this implementation ? Because we can easily change the dispatch
handler. Even if we often have the KiInterruptDispatch we can find
KiFloatingDispatch or KiChainDispatch. KiChainedDispatch is for vectors
shared among multiple interrupt objects and KiFloatingDispatch is like
KiInterruptDispatch, but it saves the floating core state too.
Windows provides APIs for connecting interrupts on IDT. IoConnectInterrupt
and IoConnectInterruptEx, according to the WDK :
NTSTATUS
IoConnectInterrupt(
OUT PKINTERRUPT *InterruptObject,
IN PKSERVICE_ROUTINE ServiceRoutine,
IN PVOID ServiceContext,
IN PKSPIN_LOCK SpinLock OPTIONAL,
IN ULONG Vector,
IN KIRQL Irql,
IN KIRQL SynchronizeIrql,
IN KINTERRUPT_MODE InterruptMode,
IN BOOLEAN ShareVector,
IN KAFFINITY ProcessorEnableMask,
IN BOOLEAN FloatingSave
);
As you can see IoConnectInterrupt returns in the InterruptObject parameter
a KINTERRUPT structure, the same that we retrieve in the IDT. Previously
you have seen in the KiInterruptTemplate two labels,
KiInterruptTemplateObject and KiInterruptTemplate2ndDispatch. Those two
labels are used by kernel function to find the two instructions in the
KiInterruptTemplateRoutine. KeInitializeInterrupt uses the
KiInterruptTemplateObject label to update the "jmp Ki*Dispatch" and the
KiConnectVectorAndInterruptObject function uses
KiInterruptTemplate2ndDispatch to modify the "mov edi, <&Kinterrupt>".
-----[ 2.3.2 Hooking hardware IDT like a ninja
Now, think about this. We want to hook the IDT in a stealth way, we know
that replacing an entry directly is not the best solution. Anti-rooktits
don't check the dynamically allocated KiInterruptTemplate routine. So we
can modify this routine as we wish. There are three possible ways :
- Redirect the "jmp Ki*Dispatch" on our dispatch routine, we have to code
our dispatch routine, not so hard.
- Change the kinterrupt address passed in EDI by the instruction
"mov edi, <&Kinterrupt>". The new KINTERRUPT will be the same than the
previous one, only the ServiceRoutine will be modified by us.
- Create our own KiInterruptTemplate, hard ...
In this paper, we choosed the simplest way. We change the
"mov edi, <&kinterrupt>" by a "mov edi, <&OurKinterrupt>" and we implement
our ServiceRoutine. We know that this instruction is followed by a jmp, so
with a disassembly engine we can retrieve the instruction before the jmp
nt!KiInterruptDispatch and modify it. We must keep in mind, when the
ServiceRoutine is running, the interrupt is not handled yet and we are
running at DEVICE_IRQL IRQL. This is not a fair situation, because a
lot of Windows kernel functions are not accessible. We know, that most
ISR queued a DPC, so after the ISR has been executed, the last entry in
the current core DPC queue should contain the DPC routine of our interrupt.
If we want to access data generated by the interrupt we must proceed like
the ISR. Replacing the original ISR by our own ISR handler is very hard,
because it depends too much on the hardware device. But we know that the
real I/O is done by the DPC, so when KiInterruptTemplate will call our
ServiceRoutine, first we call the original ServiceRoutine and we modify
the last DPC entry by our.
DPC are represented by KDPC structures :
kd> dt nt!_KDPC
+0x000 Type : Int2B
+0x002 Number : UChar
+0x003 Importance : UChar
+0x004 DpcListEntry : _LIST_ENTRY
+0x00c DeferredRoutine : Ptr32 void
+0x010 DeferredContext : Ptr32 Void
+0x014 SystemArgument1 : Ptr32 Void
+0x018 SystemArgument2 : Ptr32 Void
+0x01c Lock : Ptr32 Uint4B
DPC list can be found in the KPRCB (Kernel Processor Control Region Block)
structure of the current processor. KPRCB is preceded by a KPCR (Kernel
Processor Control Block) structure which is located at FS:[0x1C] on the
current processor. KPRCB is a 0x120 bytes from the beginning of the KPCR
structure.
dt nt!_KPRCB
[...]
+0x860 DpcListHead : _LIST_ENTRY
+0x868 DpcStack : Ptr32 Void ; DPC arguments
+0x86c DpcCount : Uint4B ; DPC core counter
+0x870 DpcQueueDepth : Uint4B ; Numbers of DPC in the list
+0x874 DpcRoutineActive : Uint4B
+0x878 DpcInterruptRequested : Uint4B
+0x87c DpcLastCount : Uint4B
+0x880 DpcRequestRate : Uint4B
+0x884 MaximumDpcQueueDepth : Uint4B
+0x888 MinimumDpcRate : Uint4B
Now we know how to retrieve the DPC of our interrupt, we can easily
change it to our own and handle the data.
For the keyboard the DPC is queued by KeInsertQueueDpc in the
I8xQueueCurrentKeyboardInput routine called by the keyboard's ISR.
kd> dt nt!_KDPC 80e3461c
+0x000 Type : 19 ; 19=DpcObject
+0x002 Number : 0 ''
+0x003 Importance : 0x1 ''
+0x004 DpcListEntry : _LIST_ENTRY [ 0xffdff980 - 0x80559684 ]
+0x00c DeferredRoutine : 0xfa815650 void i8042prt!I8042KeyboardIsrDpc
+0x010 DeferredContext : 0x80e343b8
+0x014 SystemArgument1 : (null)
+0x018 SystemArgument2 : (null)
+0x01c Lock : 0xffdff9c0 -> 0
Here is the figure of the attack :
MyKinterrupt structure
+---------------------+
Hardware Interrupt /----> MyServiceRoutine |
| | | Calls the original |
| | | ISR ------\
\---> IDT ---\ | | And modify the DPC | |
| | | queue. | |
| | +---------------------+ |
+---------------------+ | |
| KiInterruptTemplate -----/ Original Kinterrupt |
+---------------------+ +---------------------+ |
Core | | |
+------------+ | ServiceRoutine <-----/
| | | Queues the ISR's DPC|
|DpcListHead |--\ +---------------------+
| | |
+------------+ |
| +-----+ +-----+ +-----+ +-----+
\-> DPC |---->| DPC |---->| DPC |---->| DPC |-->DpcListHead
DpcListHead<---| |<----| |<----| |<----| |
+-----+ +-----+ +-----+ +-----+
/\
||
Last DPC entry
Modified after the call
to the ServiceRoutine.
-----[ 2.3.3 - Application 1 : Kernel keylogger
It's time to design a POC. In this sample we will see how to sniff
keyboard keystrokes. As you see previously, we are now able to control the
DPC generated by an interrupt. For the keyboard we will hijack the
I8042KeyboardIsrDpc routine which is set into the DPC's keyboard
interruption. With our own DPC handler we will reproduce the behavior of
the original routine, unfortunately this kind of routine is hard to write
so we ripped some pieces of codes and used reversing techniques (notice the
lazy hacker style).
In our DPC handler we must call the KeyboardClassServiceCallback [28]
routine, this routine is provided by the Kbdclass driver. This callback
transfers input data buffer of a device to the class data queue. A function
keyboard driver must calls this class service callback in its DPC routine.
Here is the KeyboardClassServiceCallback's prototype :
VOID
KeyboardClassServiceCallback (
IN PDEVICE_OBJECT DeviceObject,
IN PKEYBOARD_INPUT_DATA InputDataStart,
IN PKEYBOARD_INPUT_DATA InputDataEnd,
IN OUT PULONG InputDataConsumed
);
Parameters :
DeviceObject : Pointer to the class device object.
InputDataStart : Pointer to the first keyboard input data packet in
the input data buffer of the port device.
InputDataEnd : Pointer to the keyboard input data packet that
immediately follows the last data packet in the input data buffer of
the port device.
InputDataConsumed : Pointer to the number of keyboard input data
packets that are transferred by the routine.
KEYBOARD_INPUT_DATA is defined by :
typedef struct _KEYBOARD_INPUT_DATA {
USHORT UnitId;
USHORT MakeCode;
USHORT Flags;
USHORT Reserved;
ULONG ExtraInformation;
} KEYBOARD_INPUT_DATA, *PKEYBOARD_INPUT_DATA;
So in our DPC handler we just have to check the MakeCode member of the set
of KEYBOARD_INPUT_DATA structures. The MakeCode (or scancode) represents
the data sent by the keyboard to the system when you hit or release a
key, each key has it's own scancode and the system usually translates the
scancode into a character depending on you code page. For example the
scancode 19d on classical US keyboard is translated into the keycode 'e'.
In order to know if CAPSLOCK is activated we send an IOCTL to the
functional keyboard device but we can only send IOCTL at a PASSIVE_LEVEL
IRQL. For that we use a system thread which will sent IOCTL with the
kernel API IoBuildDeviceIoControlRequest. In fact the scancodes are queued
in a list locked by a spinlock and thread synchronized with a semaphore.
The thread is listening to incoming keystrokes then converts scancodes into
keycodes. Like the kernel keylogger Klog does [29].
-----[ 2.3.4 - Application 2 : NDIS packet sniffer
In the same way, an interrupt is raised when your network card receives
a packet. When this kind of interrupt is raised NDIS ISR handler
(ndisMIsr) routine launches the miniport ISR interrupt handler. The
ndisMIsr routine is used as a wrapper for miniport ISR and DPC. You can
see in the IDT the following entry :
3b: 80df6414 NDIS!ndisMIsr (KINTERRUPT 80df63d8)
It means, your ISR handler is not called directly when an interrupt
occurs, it is the ndisMIsr routine. Miniport's ISR is called by ndisMIsr
and the miniport DPC is also queued in this routine. The DPC queued is
the ndisMDpc routine which wraps your own DPC miniport handler. Finally
NDIS wraps all the interrupt process with ndisMIsr and ndisMDpc routines on
Windows XP with NDIS 5.1. We don't know if this implementation is still
present on Windows Vista with NDIS 6.0.
We know we can hijack the ndisMDpc handler by our own handler. With NDIS
we will proceed in the same way but we will not hook the MiniportDpc
routine but directly hook the ndisMDpc routine. Why? Because we know that
ndisMDpc wraps the MiniportDpc routine and in fact MiniportDpc depends too
much on the hardware of the miniport device. Each miniport device is
represented by an NDIS_MINIPORT_BLOCK [30] structure, in this structure
we find a reference to a NDIS_MINIPORT_INTERRUP structure, which looks
like :
kd> dt ndis!_NDIS_MINIPORT_INTERRUPT
+0x000 InterruptObject : Ptr32 _KINTERRUPT
+0x004 DpcCountLock : Uint4B
+0x008 Reserved : Ptr32 Void
+0x00c MiniportIsr : Ptr32 Void
+0x010 MiniportDpc : Ptr32 Void
+0x014 InterruptDpc : _KDPC
+0x034 Miniport : Ptr32 _NDIS_MINIPORT_BLOCK
+0x038 DpcCount : UChar
+0x039 Filler1 : UChar
+0x03c DpcsCompletedEvent : _KEVENT
+0x04c SharedInterrupt : UChar
+0x04d IsrRequested : UChar
If we look at the ndisMDpc routine we notice that only the first parameter
is used and this parameter refers to a NDIS_MINIPORT_INTERRUPT structure.
The ndisMDpc function will call the MiniportDpc field of this structure.
We just have to hijack this pointer by our routine in order to control the
incoming packets on the system.
The NDIS documentation specifies that a miniport DPC routine must
notify the bound protocol driver that an that an array of received
packets is available by calling the NdisMIndicateReceivePacket function
[31].
VOID
NdisMIndicateReceivePacket(
IN NDIS_HANDLE MiniportAdapterHandle,
IN PPNDIS_PACKET ReceivePackets,
IN UINT NumberOfPackets
);
In the ndis.h header we have :
#define NdisMIndicateReceivePacket(_H, _P, _N) \
{ \
(*((PNDIS_MINIPORT_BLOCK)(_H))->PacketIndicateHandler)( \
_H, \
_P, \
_N); \
}
So in our MiniportDpc routine we will hihjack the PacketIndicateHandler,
which is often the ethFilterDprIndicateReceivePacket routine in the
NDIS_MINIPORT_BLOCK structure, in order to filter the incoming packets on
the miniport. After we have hijacked this pointer we call the original
MiniportDpc routine that will process everything. After that, we restore
the PacketIndicateHandler handler in the NDIS_MINIPORT_BLOCK for stealth
reasons. To sum up we must :
- Hijack the routine into the DPC queued by the ndisMIsr routine.
- Now that we have hijacked the ndisMDpc we modify the
PacketIndicateHandler into the NDIS_MINIPORT_BLOCK of the miniport.
- We call the ndisMDpc routine. It will call the original MiniportDpc
handler
- The MiniportDpc routine calls the NdisMIndicateReceivePacket macro. Our
filter function is called and we do our job.
- When the ndisMDpc returns we restore the original PacketIndicateHandler
into the NDIS_MINIPORT_BLOCK of the miniport.
With this filter, we can monitor or modify the incoming packets. For
example, our PacketIndicateHandler hook can search in the incoming packets
for a tag, when this tag his found the rootkit triggers a function.
---[ 2.2 - Conclusion about stealth hooking on IDT
In this part we have seen how Windows manages his hardware interrupts by
using a global template function dedicated to all interrupts. The fact
that this template routine his forged for each interrupts is the main
point of this attack, with that we can create a fake template routine that
cannot be detected directly. The stealth of our attack remains on two
points :
- We modify only dynamic allocated and forged code
- We hijack highly temporal dynamic allocated structures which when
running, are always preempting the core.
So, even if the scope of our attack is restricted, controlling the hardware
is the best way for a rk to reach critical components. Finally, we have
just cheated the system with its own features and that's the purpose of a
stealth rootkit.
--[ 3 - Owning NonPaged pool using stealth hooking
Rootkit sophistication depends on how it subverts the kernel. More
complex techniques come out as kernel and hardware understanding evolve.
Nowadays there is so many ways to subvert the kernel, in consequence
protections become harder to defeat. We're going to present a different
means to gain control. Next techniques apply this approach to the kernel
memory allocator.
Our goal is getting execution on every NonPaged allocation without using
any hook. It must bypass any hooking verification even those based on code
page comparison or hashing. It will be done by modifying data used by the
allocator. We just apply the concept of using code against itself. We do
believe that this concept can be used on others components and in
different ways successfully.
We won't try to convince you that this technique is perfect. It evades
current protections and detection systems. The more important is that they
would need more than a simple modification to prevent and block an attack
based on kernel code behavior.
---[ 3.1 - Kernel allocation layout review
As every operating system, Windows kernel puts forward some functions in
order to allocate or free memory. Virtual memory is organized as block of
memory called pages. In Intel x86 architecture, a page size is 4096 bytes
and most allocations requests are smaller. Thus, kernel functions like
ExAllocatePoolWithTag and ExFreePoolWithTag kept unused memory blocks for
next allocations. Internal functions directly interact with hardware each
time a page is needed. All those procedures are complex and delicate that's
why drivers trust kernel implementation.
-----[ 3.1.1 - Difference between Paged and NonPaged pool
Kernel system memory is divided in two different kind of pool. It has been
separated to distinguish most used memory blocks. The system must know
which pages should be resident and which can be temporarily discarded. The
page fault handler restores pageable memory only when IRQL is inferior of
DPC or DISPATCH level. Paged pool can be paged in or out of the system. A
memory block paged out will be saved on the file system and so unused part
of paged memory will not be resident in memory. NonPaged pool is present
in every IRQL level and then is put-upon for important tasks.
The file pagefile.sys contains paged out memory. It was attacked to inject
unsigned code into Vista kernel [32]. Some solutions was discussed as
disabling kernel memory paging. Joanna Rutkowska defended this solution as
more secure than others but with a small physical memory loss. Microsoft
just denied raw disk access, which may prove that Paged and NonPaged
layout is an important feature of Windows kernel [33].
This article focuses on NonPaged pool layout as PagedPool handling is
totally different. NonPaged pool can be more or less considered as
following a typical heap implementation. Global information about system
pool can be found in Microsoft Windows Internals [34].
-----[ 3.1.2 - NonPaged pool tables
The allocation algorithm must be fast allocating on the most used sizes.
That why three different tables exist and each one is devoted to a size
range. We found this organization in most memory management algorithms.
Retrieving memory blocks from hardware takes time. Windows balances between
response faster and avoid memory wasting. Response time becomes faster if
memory blocks are stored for next allocations. In the other hand, if you
keep too much memory, it can penalize memory demands.
Each table implements a different way to store memory blocks. We will
present each table and where you can find them.
The NonPaged lookaside is a per-processor table covering size inferior or
equal to 256 bytes. Each processor has a processor control register (PCR)
storing data concerning only a single processor like IRQL level, GDT, IDT.
Its extension called processor control region (PCRB) contains lookasides
tables. Next windbg dump presents NonPaged lookaside table and its
structure.
kd> !pcr
KPCR for Processor 0 at ffdff000:
Major 1 Minor 1
NtTib.ExceptionList: 805486b0
NtTib.StackBase: 80548ef0
NtTib.StackLimit: 80546100
NtTib.SubSystemTib: 00000000
NtTib.Version: 00000000
NtTib.UserPointer: 00000000
NtTib.SelfTib: 00000000
SelfPcr: ffdff000
Prcb: ffdff120
Irql: 00000000
IRR: 00000000
IDR: ffffffff
InterruptMode: 00000000
IDT: 8003f400
GDT: 8003f000
TSS: 80042000
CurrentThread: 80551920
NextThread: 00000000
IdleThread: 80551920
DpcQueue: 0x80551f80 0x804ff29c
kd> dt nt!_KPRCB ffdff120
[...]
+0x5a0 PPNPagedLookasideList : [32]
+0x000 P : 0x819c6000 _GENERAL_LOOKASIDE
+0x004 L : 0x8054dd00 _GENERAL_LOOKASIDE
[...]
kd> dt nt!_GENERAL_LOOKASIDE
+0x000 ListHead : _SLIST_HEADER
+0x008 Depth : Uint2B
+0x00a MaximumDepth : Uint2B
+0x00c TotalAllocates : Uint4B
+0x010 AllocateMisses : Uint4B
+0x010 AllocateHits : Uint4B
+0x014 TotalFrees : Uint4B
+0x018 FreeMisses : Uint4B
+0x018 FreeHits : Uint4B
+0x01c Type : _POOL_TYPE
+0x020 Tag : Uint4B
+0x024 Size : Uint4B
+0x028 Allocate : Ptr32 void*
+0x02c Free : Ptr32 void
+0x030 ListEntry : _LIST_ENTRY
+0x038 LastTotalAllocates : Uint4B
+0x03c LastAllocateMisses : Uint4B
+0x03c LastAllocateHits : Uint4B
+0x040 Future : [2] Uint4B
Lookaside tables permit faster block retrieving than typical double linked
list. For this optimization lock time is really important and a single
linked list is a faster mechanism than software locking.
ExInterlockedPopEntrySList function is used to pop an entry from a single
linked list using hardware locking instruction "lock".
PPNPagedLookasideList is the lookaside table we were talking about. It
contains two lookaside lists P and L. Depth field of the GENERAL_LOOKASIDE
structure defines how many entries can be in ListHead single list. The
system updates regularly the depth using different counters. The update
algorithm is based on processor number and is different for P and L. Depth
of the P list is updated more frequently than L list as it optimizes
performances on very small blocks.
The second table depends how many processors are used and how system
managed them. Allocation system walk it if size is inferior or equal to
4080 bytes or if lookaside research failed. Even if target table can
change, it always has the same POOL_DESCRIPTOR structure. On single
processor, a variable called PoolVector is used to retrieve
NonPagedPoolDescriptor pointer. On multi processor, the
ExpNonPagedPoolDescriptor table has 16 slots containing pool descriptors.
Each processor PRCB points on a KNODE structure. A node can be linked on
more than one processor and contains a color field used as an index in
ExpNonPagedPoolDescriptor. Next figures illustrate this algorithm.
PoolVector
+------------+
| NonPaged | --------------> NonPagedPoolDescriptor
|------------+
| Paged |
+------------+
[ Figure 1 - Single processor pool descriptor ]
Processor #1
+------------+
| | ExpNonPagedPoolDescriptor
| PRCB ------\ +-------------------+
| | | /---------> SLOT #01 |
+------------+ | | | SLOT #02 |
/---------/ | | SLOT #03 |
| KNODE | | SLOT #04 |
|---> +------------+ | | SLOT #05 |
| | Proc mask | | | SLOT #06 |
| | color (01) --/ | SLOT #07 |
| | ... | | SLOT #08 |
| +------------+ | SLOT #09 |
| | SLOT #10 |
\---------\ | SLOT #11 |
Processor #2 | | SLOT #12 |
+------------+ | | SLOT #13 |
| | | | SLOT #14 |
| PRCB ------/ | SLOT #15 |
| | | SLOT #16 |
+------------+ +-------------------+
[ Figure 2 - Multiple processor pool descriptor ]
A global variable ExpNumberOfNonPagedPools defines if multi processor case
is used. It should reflect processor number but it can change between
operating system versions.
The next dump shows POOL_DESCRIPTOR structure from windbg.
kd> dt nt!_POOL_DESCRIPTOR
+0x000 PoolType : _POOL_TYPE
+0x004 PoolIndex : Uint4B
+0x008 RunningAllocs : Uint4B
+0x00c RunningDeAllocs : Uint4B
+0x010 TotalPages : Uint4B
+0x014 TotalBigPages : Uint4B
+0x018 Threshold : Uint4B
+0x01c LockAddress : Ptr32 Void
+0x020 PendingFrees : Ptr32 Void
+0x024 PendingFreeDepth : Int4B
+0x028 ListHeads : [512] _LIST_ENTRY
Queued spinlock synchronization, part of HAL library, is used to restrict
concurrency on a pool descriptor. It assures that only one thread and one
processor will access and unlink an entry from a pool descriptor. HAL
library changes on different architectures and what is a simple IRQL
raising on single processor becomes a more complex queued system on
multi-processor. For default pool descriptor, general NonPaged queued
spinlock is locked (LockQueueNonPagedPoolLock). Else, a custom queued
spinlock is created.
The third and last table is shared by processors for size superior of 4080
bytes. MmNonPagedPoolFreeListHead is also used when others tables lack
memory. It composed by 4 LIST_ENTRY each one representing a page number,
except for the last one which holds all superiors pages kept by the system.
Access to this table is guarded by general non paged queued spinlock
also called LockQueueNonPagedPoolLock. During the free procedure of a
smaller block, ExFreePoolWithTag merges it with previous and next free
blocks. It can create a block superior or equal to 1 page. In this case,
the new block is added in the MmNonPagedPoolFreeListHead table.
-----[ 3.1.3 - Allocation and free algorithms
Kernel allocation does not change that much between OS versions but its
algorithm is as hard as the userland heap one. In this part, we want to
illustrate basic behavior between tables during allocation or free
procedures. A lot of details have been thrown away such as synchronization
mechanisms. Those algorithms will help you for the technique explanation
but also understanding the basic elements of kernel allocation. Despite
kernel exploitation is not part of this paper, pool overflow is an
interesting topic that needs understanding of some part of this algorithm.
NonPaged pool allocation algorithm (ExAllocatePoolWithTag):
IF [ Size > 4080 bytes ]
[
- Call the MiAllocatePoolPages function
- Walk MmNonPagedPoolFreeListHead LIST_ENTRY table.
- Retrieve memory from hardware if necessary.
- Return memory page aligned (without header).
]
IF [ Size <= 256 bytes ]
[
- Pop entry from PPNPagedLookasideList table.
- If something is found return memory block.
]
IF [ ExpNumberOfNonPagedPools > 1 ]
- PoolDescriptor from ExpNumberOfNonPagedPools and used index
comes from PRCB KNODE color.
ELSE
- PoolDescriptor is PoolVector first entry, designed by symbol
as NonPagedPoolDescriptor.
FOREACH [ >= Size entry of PoolDescriptor.ListHeads ]
[
IF [ Entry is not empty ]
[
- Unlink entry and split it if needed
- Return memory block
]
]
- Call the MiAllocatePoolPages function
- Walk MmNonPagedPoolFreeListHead LIST_ENTRY table..
- Split it correctly to the right size
- Return new memory block
NonPaged pool free algorithm (ExFreePoolWithTag) :
IF [ MemoryBlock is page aligned ]
[
- Call the MiFreePoolPages function
- Determine block type (Paged or NonPaged)
- Depending on how many blocks are kept in
MmNonPagedPoolFreeListHead, we release it to the hardware.
]
ELSE
[
- Merge previous and next block if possible
IF [ NewMemoryBlock size <= 256 bytes ]
[
- Look at PPNPagedLookasideList entry depth and see if we
should keep it.
- We return if memory block is pushed into lookaside list
]
IF [ NewMemoryBlock size <= 4080 bytes ]
[
- Use POOL_HEADER PoolIndex variable to determine which
PoolDescriptor must be used.
- Insert it in the proper LIST_ENTRY array entry
- If anything goes well, return
]
- Depending on how many blocks are kept in
MmNonPagedPoolFreeListHead, we release it to the hardware.
]
Paged pool algorithm is very different especially for page aligned blocks.
Smaller size management should be not that far from NonPaged but in
assembly code we definitely saw that NonPaged and Paged pool are totally
separated. Once you know a little more about how NonPaged allocation works,
we can now talk about exploitation part.
---[ 3.2 - Getting code execution abusing allocation code
Our main goal is getting code execution on every allocation attempts for
NonPaged pool only. This result must be done only by changing data used by
targeted code. Our purpose is proving that kernel code can serve our
interest only by changing typical data environment. Our work is based
on a new rootkit developed to gain control over NonPaged allocation.
We start with getting code execution for allocation superior or equal
to 1 page. As we saw on previous part, it concerns the third and last
table.
-----[ 3.2.1 - Data corruption of MmNonPagedPoolFreeListHead
MmNonPagedPoolFreeListHead conserves page aligned memory blocks to speed up
memory allocation. It links held memory block using a LIST_ENTRY structure.
This structure is common and use in Windows heap library for example.
kd> dt nt!_LIST_ENTRY
+0x000 Flink : Ptr32 _LIST_ENTRY
+0x004 Blink : Ptr32 _LIST_ENTRY
MmNonPagedPoolFreeListHead access is protected by general NonPaged queued
spinlock LockQueueNonPagedPoolLock. It assures that only one thread and
processor can look and modify this structure.
So we need a way to get control over allocation and unlinking procedure
seems perfect. We can poison this linked list with a fake entry, with the
highest size possible, which unlinking will modify current executed code.
At kernel level, you can modify code as data without any protection issues.
Unlinking was used when heap exploitation started [20] but modifying code
was not possible from userland. As spinlock assures us exclusivity, there
is no risk on some race condition. The created "hook" would be dynamic and
code restored directly. Page guard protection reverse [18] shows that code
is only checked every 5 minutes. Whether a modification is found, real code
is just replaced.
This method has plenty assets but also a lot of obstacles. Let start by
enumerating all those obstacles :
- On a basic implementation of unlinking, list become unwalkable.
It breaks most utilization of the table.
- Pass through page cleaning methods and always be the first block on the
list otherwise we could miss some call.
- We break code path and sooner or later we must return as if our
hijacking has never been there and everything goes fine.
- Processor prefetch make self code modification dangerous.
Unlinking gives us 4 bytes overwriting to build an opcode and create a
redirection. In our case, we influenced current context and a register
should point to the unlinked entry. We said should point without choosing a
single register because kernel changes between versions or service packs.
As soon as we discuss context, we will stay talking about general
situations. We choose to make a jmp [reg+XX] which is FF60XX in hex.
This technique effectiveness lies on keeping the MmNonPagedPoolFreeListHead
walkable. A double linked list, as LIST_ENTRY, is walkable if Flink is
correct. Therefore we can choose an address for Flink as 0xXXXX60FF and
Blink will point to the code address. The Intel x86 architecture using
little endian our address is quite easy to found, we must check opcode
offset and discard too close possibilities. Next figure illustrates a
poisoned entry.
MmNonPagedPoolFreeListHead[i]
/------> +--------------------+
| | Flink | ---\
| |--------------------| |
| <---- | Blink | |
| +--------------------+ |
| | ... | |
| +--------------------+ |
| /-------------------------------/
| |
| | Poisoned entry
| | +--------------------+
| | | PreviousSize : - |
| | +--------------------+
| | | PoolIndex : - |
| | +--------------------+
| | | PoolType: NonPaged |
| | +--------------------+
| | | BlockSize : i |
| | +--------------------+
| | | PoolTag : - |
| \---> +--------------------+
| | Flink : 0xYYXX60FF | <--\
| |--------------------| |
| X--- | Blink : 0x80YYYYYY | |
| +--------------------+ |
| |
| /-------------------------------/
| | Fake entry (0xYYXX60FF)
| | +--------------------+
| | | PreviousSize : - |
| | +--------------------+
| | | PoolIndex : - |
| | +--------------------+
| | | PoolType: NonPaged |
| | +--------------------+
| | | BlockSize : < i |
| | +--------------------+
| | | PoolTag : - |
| |---> +--------------------+
| | | Flink : 0x80..... | ---\
| | |--------------------| |
| \---- | Blink : Poisoned | |
| +--------------------+ |
\--------------- [...] ------------/
Unlinking instruction : mov [0x80YYYYYY], 0xYYXX60FF
New Opcode after unlinking : jmp [reg+XX] (FF 60 XX)
[ Figure 3 - Poisoned double linked list ]
This figure shows a MmNonPagedPoolFreeListHead entry layout that assures
predicted unlinking and then code execution. We must maintain this layout
or we will lose our position. NonPaged blocks come from two different
virtual memory ranges. The second memory region start is stored in
MmNonPagedPoolExpansionStart. A cleaning function is called sometime to
free blocks from the expansion NonPaged pool. To avoid this cleaning, we
can use a Paged pool block locked. You can lock a memory block with the
MmProbeAndLockPages function. This lock makes described memory region as
resident. Another more discreet way is to remap a NonPaged block with the
function MmMapLockedPagesSpecifyCache. It is more discrete because this
mapping would be just before expansion NonPaged pool memory range. Using
a locked Paged pool block creates an address totally differently. A quick
look at those addresses between NonPaged ones show a clear difference.
As virtual memory is very large, it does not take too much time to find
an address like 0xYYXX60FF. We will not unlock those pages until our
technique is running.
To defeat code path issues we differentiate two different states. The first
state is when our block is selected. The second state is when our block is
unlinked. If we were able to return to the first step with our next fake
entry selected, we could continue walkin
g code as normal. We achieve that
by using a generic approach. At IRQL equal to DISPATCH_LEVEL, we corrupt a
MmNonPagedPoolFreeListHead entry with some invalid pointers. With a hook on
the page fault handler we are capable to see first and second stages,
restore the right context each time and save context difference between
those states.
Assembly dump from MiAllocatePoolPages :
lea eax, [esi+8] ; Stage #1 esi is selected block and esi+8 its size
cmp [eax], ebx ; Check with needed size
mov ecx, esi
jnb loc_47014B
[...]
loc_47014B:
sub [esi+8], ebx
mov eax, [esi+8]
shl eax, 0Ch
add eax, esi
cmp _MmProtectFreedNonPagedPool, 0 ; Protected mode, don't care
mov [ebp+arg_4], eax
jnz short loc_47016E
mov eax, [esi] ; \ Stage #2
mov ecx, [esi+4] ; | Unlinking
mov [ecx], eax ; | procedure
mov [eax+4], ecx ; /
jmp short loc_470174
Now let's see how it works during our test technique with interrupt fault
handler (int 0xE) hooked :
lea eax, [esi+8]
; Stage #1 - Check with needed size
cmp [eax], ebx ; ----> PAGE FAULT esi = 0xAAAAAAAA | eax = esi + 8
; - We keep EIP and all registers
; - Scan all registers for 0xAAAAAAAA +/- 8
; and correct the current context. Continue.
mov ecx, esi
jnb loc_47014B
[...]
loc_47014B:
sub [esi+8], ebx
mov eax, [esi+8]
shl eax, 0Ch
add eax, esi
cmp _MmProtectFreedNonPagedPool, 0 ; Protected mode, don't care
mov [ebp+arg_4], eax
jnz short loc_47016E
mov eax, [esi] ; \ Stage #2 - Unlinking procedure
mov ecx, [esi+4] ; |
mov [ecx], eax ; | ------> PAGE FAULT ecx = 0xBBBBBBBB
; | eax = 0xCCCCCCCC
; | - Keep EIP and sub this context from
; | Stage #1 saved context
; | - Change fault registers and
; | structure pointers. Continue.
mov [eax+4], ecx ; /
jmp short loc_470174
Fault addresses 0xAAAAAAA, 0xBBBBBBBB and 0xCCCCCCCC must point on invalid
addresses to force a caught page fault. This test is made only once and
when we still have exclusivity on all processors. The int 0xE (page fault)
handler is restored just after.
This generic technique permits us to restore a valid context just before
selected block size is checked. Once we get code execution, we apply
context difference, change the current block register and then return at
first stage address. It works well because our two stages are very close,
once a selected block size is checked, unlinking is directly made.
Given examples were based on a single LIST_ENTRY of the
MmNonPagedPoolFreeListHead table but you must poison all entries. If a
given entry is empty (except for our fake blocks), the algorithm tries
next the entry. It means we will be called more than one time per
allocation. We created a mechanism to manage multiple call on a single
allocation. If the first entry is empty, the second entry is used and so
on. Then we will be called twice or more. By checking current table, we
can predict a future code execution on the same allocation and avoid
executing payload more than one time per allocation request.
Prefetch is a processor feature that retrieves more than a single
instruction from memory before it executes them. Some processor use a
complex branch prediction algorithm to fetch as much instruction as
possible. After some tests, we saw that processors invalidate code cache
when a modification occurs in cached memory addresses. Our driver supports
a case where code modification could be right after current instruction.
To achieve that we created a routine which calculates prefetch cache size
and consider it in next parts of our technique. We could also search
specifics instructions which clean prefetch cache like a far jump but it
can only be used as an option.
This technique gives us code execution for NonPaged allocation superior or
equal to 1 page. It achieves that with a stealth hook, created by kernel
code and cleaned by our routine directly after. It's far from being
perfect as those allocations are not used that much. Next part describes
how this technique can be extended to gain control over all NonPaged pool
allocations.
-----[ 3.2.2 - Expend it for every size
Others lists can not be hijacked the same way because synchronization
mechanisms are not exclusive. Changing some assembly code becomes tricky if
it can be executed by more than one thread at a time. Our method is
assuring our previous technique execution on any allocation. Once we have
control, we can find a way to retore ExAllocatePoolWithTag context with a
correct return value. We must do that without recoding a single line of
memory allocator. It is possible to create our own allocator but Windows
one is great and it will perfectly do the job for us.
During allocation, the lookaside list is checked first. It will pop an
entry and if this entry is not NULL, use it. This entry comes from
GENERAL_LOOKASIDE ListHeader field. This field structure is SLIST_HEADER.
kd> dt nt!_SLIST_HEADER .
+0x000 Alignment : Uint8B
+0x000 Next :
+0x000 Next : Ptr32 _SINGLE_LIST_ENTRY
+0x004 Depth : Uint2B
+0x006 Sequence : Uint2B
The ExInterlockedPopEntrySList function pops an entry from a SLIST_HEADER
structure. The Next field is a pointer to the next SLIST node (single
linked list). The Depth field represents how many entries are kept in the
list. ExFreePoolWithTag compare GENERAL_LOOKASIDE optimal depth with
current SLIST_HEADER depth. ExAllocatePoolWithTag does not check this
field and just looks if some entry can be popped out Next field. To stunt
allocation and free procedure on NonPaged lookaside table, we set Next
field to NULL and Depth field to 0xFFFF. This state will be preserved and
this table will not be used anymore.
Our technique expansion relies entirely on subverting how the
ExpNonPagedPoolDescriptor table is used. In the previous part, we explained
global variable ExpNumberOfNonPagedPools involvement in this process. It
is possible to expand number of NonPaged pools and then play with current
KNODE color. During allocation, the KNODE color defines which pool
descriptor is used. Then during free procedure, PoolIndex field of
POOL_HEADER keep pool descriptor color.
So we can use this nice feature to our advantage. Default KNODE color on
every processors would point on an empty pool descriptors. It will lead to
code execution using our base technique. If the function
MiAllocatePoolPages return address is not the one use for classical page
rounded allocation, we know that a smaller allocation occur. All we have
to do is switch PRCB KNODE pointer to a copy with custom color and recall
ExAllocatePoolWithTag. Everything related to allocation and block
management will be implemented as it needs to be even if it differs
between operating system versions. Returned blocks PoolIndex will point to
our own pool descriptor and free procedure, which will perfectly work. Lets
see how it will look on a single processor.
ExpNonPagedPoolDescriptor
+-------------------+
| PREVIOUS POOLDESC | <--- Kept for compatibility (0)
| EMPTY POOLDESC | <--- Default KNODE->color (1)
| -- |
| -- |
| -- |
| -- |
| -- |
| -- |
| -- |
| -- |
| -- |
| -- |
| -- |
| -- |
| -- |
| CUSTOM POOLDESC | <--- Used for our allocations (16)
+-------------------+
[ Figure 4 - Corrupted ExpNonPagedPoolDescriptor ]
[ on single processor ]
This setup is just an example and you can manage the arrangement as you
want. We could transfer previous blocks from older pool descriptors in our
own and then receive free blocks. It is also possible to use multiple pool
descriptors and so on. Beware of system pool descriptor recycling as it can
leads to strange behavior specially on multi-processor architecture.
Once we have our fresh allocated block, we must return at
ExAllocatePoolWithTag return address. MiAllocatePoolPages has been called
to retrieve a new page and fill the current pool descriptor with it. It's
obvious that we can't return normally and let page allocation occurs. On
Intel x86 architecture the stack is used to store local variables,
arguments and saved registers. The Windows compiler starts by reserving
local variable and then pushes each register before its modification.
The next figure shows our stack configuration once we have code execution.
top
+--------------------+
| Our stack elements | Restore assembly example
+--------------------+ <------ /---------------\
| | | pop ecx |
| Saved registers | | pop ebx |
| | | pop esi |
+--------------------+ | leave |
| | | retn 0Ch |
| | \---------------/
| | |
| | |
| Stack variables | |
| | |
| | |
| | |
+--------------------+ [new stack level]
| Saved EBP | |
+--------------------+ |
| Return Address | |
+--------------------+ |
| | |
| Function arguments | |
| | |
+--------------------+ <--------------/
bottom
[ Figure 5 - Stack context after code execution ]
[ ~ small blocks case ~ ]
The restore assembly part shows correct assembly in current function which
perfectly restores the context. It does not correspond of the first series
of pop instruction before return. There is an important risk that some
register has not been pushed yet. It is possible to deduce the pushed
register number by looking at function prologue when stack variables are
reserved. In the Windows compiler, it's quite simple and we can easily
calculate the pushed register number. A simple disassembly analysis on
needed pop register number does the job. It must be done for
MiAllocatePoolPages and ExAllocatePoolWithTag. We change the return
address stored in the stack and go to the deduced MiAllocatePoolPages
address. Last step is setting eax register for the return value. Both
functions return a value and preserve eax value. Our analyzer is dynamic
and registers each pop and its register. That why we can restore the
proper context even if it changes between versions.
The Windows compiler is really easy to predict and does not create too
strange assembly organization. This technique is theoretically possible
on every assembly code that follow stdcall specification. The approach
could differ on others compilers.
---[ 3.3 Exploit our position
This article present a way of subverting the Windows kernel by modifying
only data. No function pointers, no static hooking or others classical
technique. It could exempt us of any other explanation. But it would not
be complete without some concrete examples. I personally believe that the
only limitation here is imagination.
-----[ 3.3.1 Generic stack redirection
Allocation occurs in so many places that you must rely on known context
and functions. Once everything is setup and before releasing exclusivity,
some stack redirection database can be created.
The first way to do this is calling a handler if stack backtracing
reveals a specific function. Stack backtracing shows only return addresses
and not which function call it. Debuggers resolve those functions by deep
analysis or symbol checking. Implementing those features would take too
much time. So it's better to target a specific return address on
ExAllocatePoolWithTag stack frame. It will definitely improve check speed.
To do that, we indicates to our stack redirection API that we target a
specific function. Then launch a normal call or procedure that will lead to
our function. Every allocation during this time will show important
backtrace stacks.
Let say, we target an IRP and we know which function handles it by looking
at IRP dispatch table. We also know by reversing that it will allocate a
NonPaged block. Launching an I/O request, our API could register some
NonPaged call and recognize later.
In the wild, it will call the appropriate handler with sub context
information. Sometimes getting a context is not enough. The second way
stays on same principles but modifies the stack to assure our handler is
called once the function end. Efficiency depends on what is your target
and how you modifying it.
-----[ 3.3.2 Userland process code injection
This technique can be also used to inject code in userland to subvert
trusted applications. NonPaged allocation occurs a lot in kernel mode and
it happens in every process. Some kernel drivers like win32k.sys call
userland many times. This call is achieve by the function
KeUserModeCallback [35]. It modifies userland stack to switch temporarily
for a call in userland. Available functions are limited by a table.
Userland injection from kernel should not be resident and only concern
known trusted application as browsers. Injection can be done on
explorer.exe as well to launch an hidden instance of a trusted program.
KeUserModeCallback algorithm can be easily remade or copied then
relocated.Redirection table could be subverted to redirect the call. We
can also think about exploiting userland calls. It does not make any sense
to add checks on those available functions.
--[ 4 - Detection
This article does not try to convince you that subverting IDT or
allocation mechanism using advanced technique is the future. Most detection
tools only indicate if a rookit may or may not be in this computer. It has
pains identifying which module is responsible. It detects antivirus or
firewall as rootkits. A protection layout could detect itself as a rootkit
because it does everything a rootkit does and so does not ask it to block
or uninstall a rootkit. Rootkit papers demonstrate so many great ways to
easily bypass those protections. But we don't see much those techniques in
the wild, simply because rootkits don't need them for the moment.
Detect software behavior modification could be part of a Verifiable
Operating System [36]. It will involve basic checks on known memory
structures. Checks integrity of LIST_ENTRY structures and correct them if
needed. We can blame rootkit protections as much as we want but detecting
rootkits on a closed operating system is almost impossible. Gives more
information for kernel components will certainly leads to more
sofisticates attacks. In the other hand, it could reduce attack surface.
It is specially true on a defence oriented operating system. Next
protection improvements should come from the operating system itself.
Now that there are hardware improvements for virtualisation, such as
hypervisors, there will be extensions to hardware to detect and protect
against rootkits. It offers a real control on operating system behavior
without advanced research on kernel layout. Some protections techniques
that were impossible to implement in Windows environment like PAX, could
rely on those hardware features. Our techniques could be detected by
registering and monitoring some specific events on the processor. It is
possible today to do that but performance issues are important.
Our attacks could be blocked using targeted protection such as signatures.
An attack is defined as how many times it takes to create a generic
protection. In this area, Patchguard is an important improvement.
--[ 5 - Conclusion
This papers techniques were made to show that elegant software hijacking
can still evades most protections and avoid any performance issues or
unstable behaviors. Even though, these techniques are hardly reliable and
should be considered only as a technical proof of concept. New protections
are not efficient enough or present. They do not represent a threat for
a rootkit which targets millions of computers. Reversing is an important
tool in improving software rootkits techniques. Detecting that a rootkit
is present should not be enough. A protection which cannot uninstall a
rootkit or prevent infection is useless. Drivers signatures was a good
idea as it was designed to stop current infections entries. But infection
prevention includes local kernel exploitation. Generic detection of those
attacks would need an important improvement in anti-rootkits protections
and operating system design.
--[ 6 - References
[1] Holy Father, Invisibility on NT boxes, How to become unseen on Windows
NT (Version: 1.2)
http://vx.netlux.org/lib/vhf00.html
[2] Holy Father, Hacker Defender
https://www.rootkit.com/vault/hf/hxdef100r.zip
[3] 29A
http://vx.netlux.org/29a
[4] Greg Hoglund, NT Rootkit
https://www.rootkit.com/vault/hoglund/rk_044.zip
[5] fuzen_op, FU
http://www.rootkit.com/project.php?id=12
[6] Peter Silberman, C.H.A.O.S, FUto
http://uninformed.org/?v=3&a=7
[7] Eeye, Bootroot
http://research.eeye.com/html/tools/RT20060801-7.html
[8] Eeye, Pixie
http://research.eeye.com/html/papers/download/
eEyeDigitalSecurity_Pixie%20Presentation.pdf
[9] Joanna Rutkowska and Alexander Tereshkin, Blue Pill project
http://bluepillproject.org/
[10] Frank Boldewin, A Journey to the Center of the Rustock.B Rootkit
http://www.reconstructer.org/papers/
A%20Journey%20to%20the%20Center%20of%20the%20Rustock.B%20Rootkit.zip
[11] Frank Boldewin, Peacomm.C - Cracking the nutshell
http://www.reconstructer.org/papers/
Peacomm.C%20-%20Cracking%20the%20nutshell.zip
[12] Stealth MBR rootkit
http://www2.gmer.net/mbr/
[13] EP_X0FF and MP_ART, Unreal.A, bypassing modern Antirootkits
http://www.rootkit.com/newsread.php?newsid=647
[14] AK922 : Bypassing Disk Low Level Scanning to Hide File
http://rootkit.com/newsread.php?newsid=783
[15] CardMagic and wowocock, DarkSpy
http://www.fyyre.net/~cardmagic/index_en.html
[16] pjf, IceSword
http://pjf.blogone.net
[17] Gmer
http://www.gmer.net/index.php
[18] Pageguard papers (Uniformed) :
- Bypassing PatchGuard on Windows x64 by skape & Skywing
http://www.uninformed.org/?v=all&a=14&t=sumry
- Subverting PatchGuard Version 2 by Skywing
http://www.uninformed.org/?v=all&a=28&t=sumry
- PatchGuard Reloaded: A Brief Analysis of PatchGuard Version 3 by Skywing
http://www.uninformed.org/?v=all&a=38&t=sumry
[19] Greg Hoglund, Kernel Object Hooking Rootkits (KOH Rootkits)
http://www.rootkit.com/newsread.php?newsid=501
[20] Windows Heap Overflows - David Litchfield
http://www.blackhat.com/presentations/win-usa-04/bh-win-04-litchfield/
bh-win-04-litchfield.ppt
[21] Bypassing Klister 0.4 With No Hooks or Running a Controlled
Thread Scheduler by 90210 - 29A
http://vx.netlux.org/29a/magazines/29a-8.rar
[22] Microsoft, Debugging Tools for Windows
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
[23] Kad, Phrack 59, Handling Interrupt Descriptor Table for fun and profit
http://phrack.org/issues.html?issue=59&id=4#article
[24] Wikipedia, Southbridge
http://en.wikipedia.org/wiki/Southbridge_(computing)
[25] Wikipedia, Northbridge
http://en.wikipedia.org/wiki/Northbridge_%28computing%29
[26] The NT Insider, Stop Interrupting Me -- Of PICs and APICs
http://www.osronline.com/article.cfm?article=211 (login required)
[27] Russinovich, Solomon, Microsoft Windows Internals, Fourth Edition
Chapter 3. System Mechanisms -> Trap Dispatching
[28] MSDN, KeyboardClassServiceCallback
http://msdn2.microsoft.com/en-us/library/ms793303.aspx
[29] Clandestiny, Klog
http://www.rootkit.com/vault/Clandestiny/Klog%201.0.zip
[30] Alexander Tereshkin, Rootkits: Attacking Personal Firewalls
www.blackhat.com/presentations/bh-usa-06/BH-US-06-Tereshkin.pdf
[31] MSDN, NdisMIndicateReceivePacket
http://msdn2.microsoft.com/en-us/library/aa448038.aspx
[32] Subverting VistaTM Kernel For Fun And Profit by Joanna Rutkowska
http://invisiblethings.org/papers/
joanna%20rutkowska%20-%20subverting%20vista%20kernel.ppt
[33] Vista RC2 vs. pagefile attack by Joanna Rutkowska
http://theinvisiblethings.blogspot.com/2006/10/
vista-rc2-vs-pagefile-attack-and-some.html
[34] Russinovich, Solomon, Microsoft Windows Internals, Fourth Edition
Chapter 7. Memory Management -> System Memory Pools
[35] KeUserModCallback ref - "Ring0 under WinNT/2k/XP" by Ratter - 29A
http://www.illmob.org/files/text/29a7/Articles/29A-7.003
[36] Joanna Rutkowska - Towards Verifiable Operating Systems
http://theinvisiblethings.blogspot.com/2007/01/
towards-verifiable-operating-systems.htm
