I have recently came across (well, not entirely by myself... cheers Nahuel!) a fairly (un)common problem related to performing ring0-to-ring3 transitions, after a successful kernel vulnerability exploitation. As I have managed to come up with a bunch of possible solutions, and even write exemplary code for some of these, today I would like to present my thoughts, together with some brief explanation.

Introduction

Before trying to find a reliable solution to the problem, it should be clearly stated first. And so, we are considering a 32-bit Windows NT-family version (one of the supported ones), suffering from a stack-based buffer overflow inside one of the system call handler functions. The attacker is able to overwrite memory placed after a fixed-size buffer, including the stack frame, return address, syscall arguments and anything else reachable from this point. As opposed to the reality, we assume that there is no stack protection (i.e. a cookie) implemented, so the security flaw can lead straight into malicious code execution and system compromise. Furthermore, the overflow is triggered right inside the syscall handler, not a nested function of any kind.

The following ascii picture, presenting the stack layout at the time of the overflow, should give you a better insight of the described scenario:

+-----------------------+
|                       |
|  local variables (1)  |
|                       |
+-----------------------+
|      CHAR buf[32]     | -+
+-----------------------+  |
|                       |  |
|  local variables (2)  |  | overflow
|                       |  | direction
+-----------------------+  |
|     stack frame       |  |
+-----------------------+  v
|    return address     |
+-----------------------+
|                       |
|   syscall parameters  |
|                       |
+-----------------------+
|                       |
| KiFastCallEntry stack |
|                       |
|         (...)         |

So, here we are; able to control roughly any value, which could lead us into code execution... a perfect dream for every vulnerability researcher. There is one more requirement, however - we must, by any means, return to user-mode, in order to exit the exploit process in a legitimate way (such as using ExitProcess). So, how do we achieve it, assuming that the original values of the return address, and possibly some of the syscall arguments are lost (due to being overwritten by attacker-supplied data)? Let's find out, what the options are.

KiFastCallEntry and KiServiceExit

Under normal system execution (i.e. when its stability and security don't collapse), each system call handler - such as NtOpenFile - returns to its original caller, the KiFastCallEntry function. This routine, in turn, is a dispatcher most often used upon the sysenter instruction being utilized by ring-3 code (however, it is also used by kernel modules, when taking advantage of system services). After calling an adequate handler from KeServiceDescriptorTable, the dispatcher is supposed to lower the processor privilege level, by returning to where the syscall instruction was triggered.

The latter part of the job is implemented by the KiServiceExit routine, responsible for coming back to the service caller, whatever it is. Interestingly enough, KiFastCallEntry doesn't need to call the exit function, thanks to a specific assembly code layout, designed by the system developers:

+-----------------------+
| nt!KiFastCallEntry    |
|                       | --+
|      /* code */       |   |
|       CALL EBX        | <-|-- EBX = syscall handler address
|                       |   |
|-----------------------|   |
| nt!KiServiceExit      |   |
|                       |   | code execution direction
|      /* code */       |   v
|       SYSEXIT         |
|                       |

As the KiServiceExit implementation directly follows the "end" of KiFastCallEntry, the code execution automatically moves from one routine, into another. This way, no actual call instruction is required, as the smart layout causes KiServiceExit to always execute after returning from the syscall handler. Due to the fact, that by exchanging the original return address with the one pointing at our shellcode, we do not land inside KiServiceExit automatically, anymore. What makes the situation even worse, is the fact that the exit routine is an internal symbol, not publicly exported to other, ring-0 modules.

Considering the above conditions, finding a reliable way of returning into user-mode might appear to be somewhat problematic. The next couple of sections aim to show the bright and dark sides of some possible solutions, which I have been able to think of - if there is something I have apparently missed, please let me know - I will be glad to extend the article with additional material

Obtaining internal kernel symbols

The first, and probably most straight-forward solution one could think of, requires the attacker to recognize the precise version of the kernel image being used, and take advantage of symbols' packages, publicly available on Microsoft servers. An adequate package could be either downloaded at run-time (provided that the attacked machine is connected to internet at the time of the exploitation), or distributed together with the malicious application. A lighter version of the latter option could rely on hard-coding the KiServiceExit function addresses, for every single kernel image version possible.

Advantages: If the exploit was taking advantage of legitimate, Microsoft-supplied symbols or using a static table of supported Windows editions together with the desired kernel addresses, it could achieve a decent level of reliability. If one knows the KiServiceExit memory placement, there isn't much left to be done - just aligning the stack as it would be upon a normal syscall return, and jumping to the routine after the payload completes.

Disadvantages: In case the attacker decided to download a complete ntosknrl.exe symbol file from the web, he could probably put the entire operation at risk, as the the .pdb file being retrieved can be as large as 5MB (or more). The exploit could obviously employ various DKOM-style techniques, in order to hide the connection; this would only work for the local machine, though - how about other computers in the network, and/or devices along the way to the global net? The attacker could be either caught in the first place, or leave significant amounts of proof for the forensics researchers.
If, in turn, the attacker went towards using hardcoded-values, he would be forced to keep his exploit up-to-date, in the context of new system patches being released along the way.

Problems of the above nature are, obviously, not an issue, if the attacker has a relatively small number of targets, and is able to figure out the computers' kernel versions by other means (i.e. having a local account on a given machine would usually help a lot).

Signature scan

Another, well-known way of retrieving the address-of-whatever relies on performing a quick & dirty signature scan of the memory. In this particular case, one would have to scan the entire ntoskrnl.exe image memory area, in search of a previously-extracted signature, unique for the KiServiceExit routine. The signature could (or probably: should) be constructed so that it would work for every operating system out there, or be kept inside a hard-coded table of supported kernel versions (as mentioned in the previous section).

Advantages: The exploit doesn't have to establish any outgoing connections. In fact, it doesn't make use of the internet, at all. Depending on the length and quality of the signature, as well as the numbers of kernel modifications applied by Microsoft, this technique could turn out to be either reliable, or the very opposite. According to the author, it is usually best to consider signature-scanning unreliable, regardless of the conditions. If, however, the attacker proved that the KiServiceExit address can be easily obtained, using a signature valid for all existing systems and is unlikely to change - I would claim such solution to be a relatively good one.

Disadvantages: As far as my experience goes, using constant signatures is rarely a good idea, especially if there are other options to pick. The exploit developer can be never certain that Microsoft doesn't unexpectedly change the kernel code, stack layout, or anything affecting the function assembly being relied on. What is worse, the problem is not only about changing the KiServiceExit contents itself - it is enough that a new byte sequence, matching the existing pattern appears anywhere in the kernel image; and the exploit is fooled. Concluding - not a recommended technique, when it comes to my opinion.

Own KiServiceExit implementation

The next solution to be considered, would require the exploit developer to create his own implementation of the exit routine, rather than keep trying to (non-deterministically) find it's virtual address in memory. This is possible because of the fact that we're executing with the same rights as the kernel itself, and are able to use any privileged instruction it uses. The only problem here could be potentially caused by the complexity of the function - fortunately, it is not the case for KiServiceExit.

Advantages: The major upside of this method, resides in the fact that we are not dependent on virtual addresses of any kind (apart from the actual payload, which might require these). In other words, it is possible to implement one payload epilogue, and use it across numerous system versions, as long as the stack layout (most importantly - the trap frame) doesn't change. According to my observations, the KiServiceExit routine either doesn't change at all, or is changed in minor parts (i.e. single instructions). Even though there might be a few differences between Windows 2000 and Windows Vista; such low-level parts of the system aren't modified in one day. And so, carefully preparing one, separate implementation of the function for each Windows NT-family release (2000, XP, Vista, 7) should be sufficient to keep the reliability on a very high level.

Disadvantages: One actual drawback, which could be pointed out is that the solution is still not as elegant, as it could possibly be. That's due to the fact that the kernel-to-user transition is being performed, using highly undocumented (except for the \ntos\ke\i386\trap.asm file, present inside the Windows Research Kernel package) system behavior and internal offsets. As a consequence, even though it is very likely that someone's implementation of the exit routine will work on any build of a specific Windows version, there is no certainty about it - especially in the context of future Windows versions.

The KeUserModeCallback technique

Last, but not least - the technique that was my first thought, when I started reflecting on the problem. Since the mechanism taken advantage of, in this method, has been already described numerous times (such as the "KeUserModeCallback utilization" section of mxatone's article, or Nynaeve's post), I will only give a brief explanation of its concept.

Under normal conditions, ring-3 code can only interact with the kernel modules via system calls (regular interrupts are mostly deprecated, while call-gates are not used, at all). This basic scheme relies on the fact, that user applications send specific requests, asking the kernel either to perform operations, which require higher processor privileges, or to be supplied with necessary information. A request is made (via the INT 2E or sysenter instruction), kernel dispatches the requests and possibly returns some information - then comes back to user mode (via either iretd or sysexit). Following the above scheme, one could consider system calls to be a specific type of callback functions - whenever an application wants to interact with the system, it calls back an adequate function from the kernel.

As it turns out, the kernel might want to call back into user-mode, as well! More precisely, the standard graphical driver (win32k.sys), needs to use ring-3 routines in numerous situations; in order to send notifications about graphical events going on, or to request some information. In order to meet the requirements, a special interface called user-mode callbacks was developed inside the NT kernel. The interface actually consists of one public, and a few internal kernel routines:

NTSTATUS KeUserModeCallback (
    IN ULONG ApiNumber,
    IN PVOID InputBuffer,
    IN ULONG InputLength,
    OUT PVOID *OutputBuffer,
    IN PULONG OutputLength
    );

By using the above function, exported by ntoskrnl.exe, the graphical module is able to perform a legitimate ring-0 into ring-3 transition. What happens next, is that some basic information regarding the execution state is stored on the kernel stack, and the execution is passed to the user-mode ntdll.KiUserCallbackDispatcher function, of the following prototype:

VOID KiUserCallbackDispatcher(
    IN ULONG ApiNumber,
    IN PVOID InputBuffer,
    IN ULONG InputLength
    );

The dispatcher is then responsible for forwarding the execution into one of the callback routines (the EDX register contains the ApiNumber parameter):

mov eax, large fs:18h
mov eax, [eax+30h]
mov eax, [eax+2Ch]
call dword ptr [eax+edx*4]

Seemingly, the user-side dispatch table is pointed to by one of the PEB (Process Environment Block) fields. After the given callback completes its task, it resumes the win32k.sys execution by either using a dedicated interrupt (INT 2D, internally called KiCallbackReturn), or triggering the NtCallbackReturn system call. The question is - how does the above information help us achieve the desired exploitation effect?

Thanks to the fact that KeUserModeCallback is a public symbol, any active module running in kernel-mode can call the function in a fully reliable manner. What is more, we can also hook the KiUserCallbackDispatcher function, or better yet - redirect the dispatch table pointer, residing inside PEB. If we perform the above steps, we become able to trigger our own, fully controlled, kernel-to-user transitions. Thanks to the clever NT kernel, we don't really have to care about what is left on the kernel stack, as it will be gracefully cleaned up, upon the process termination. Below, you can find exemplary code snippets, responsible for accomplishing each stage of the safe kernel-to-user transition:

1. Loading the graphical library - before we decide to touch any of the win32-related PEB fields, we should make sure that the user32.dll library has been previously loaded. This way, we are guaranteed, that both the user- and kernel- parts of the system graphics are correctly initialized for our process.
   
   

   LoadLibraryA("user32.dll");

   
   

2. Replace the original dispatch table pointer, with the one controlled by us.
   
   

   LPVOID GetFSBase(void)
   {
     LDT_ENTRY ldt;
     GetThreadSelectorEntry(GetCurrentThread(), GetFS(), &ldt);
     return (LPVOID)(ldt.BaseLow | (ldt.HighWord.Bytes.BaseMid << 16) | (ldt.HighWord.Bytes.BaseHi << 24));
   }
   
   (...)
   
    for( i=0;i<DISPATCH_TABLE_SIZE;i++ )
      DispatchTable[i] = CallbackHandler;
   
    BYTE* Teb = GetFSBase();
    Teb = *(DWORD*)(Teb+0x18);
    Teb = *(DWORD*)(Teb+0x30);
    *(DWORD*)(Teb+0x2C) = DispatchTable;
   

   
   

3. Retrieve the nt!KeUserModeCallback address. This step can be achieved, by taking advantage of the PSAPI interface (to retrieve the ImageBase of the kernel image; EnumDeviceDrivers and GetDeviceDriverBaseNameA are of much use), loading the very same image in the context of our application, and performing some simple maths. I have made use of my personal GetKernelProcAddress function this time - implementing this one is left as an exercise to the reader
   
   

   KeUserModeCallback = (typeof(KeUserModeCallback))GetKernelProcAddress("ntoskrnl.exe","KeUserModeCallback");

   
   

4. Trigger the buffer overflow, leading to the Payload() function being executed. Shellcode represents the actual code for elevating user privileges, starting up a reverse shell, or whatever else you can think of.
   
   

   VOID Payload()
   {
     ((VOID(*)())Shellcode)();
     KeUserModeCallback(0,0,0,0,0);
   }
   

   
   

5. Catch the user-mode callback inside CallbackHandler(), and gracefully terminate the process.
   
   

   DWORD CallbackHandler()
   {
     if(b0f_triggered) ExitProcess();
   
     NtCallbackReturn(0,0,ERROR_SUCCESS);
     return ERROR_SUCCESS;
   }
   

   
   

6. That's it, we're done!

What should be eventually noted, is that the KeUserModeCallback leads to the KiServiceExit function in the end, as the following call chain shows:

| nt!KeUserModeCallback
| nt!KiCallUserMode
v nt!KiServiceExit

Let's take a closer look at the actual pros and cons of the presented technique.

Advantages: The entire solution basically relies on two steps: calling a public nt!KeUserModeCallback routine after successful exploitation, and "catching" the execution flow at the public ntdll!KiUserCallbackDispatcher function, or at one of the callback handlers, pointed to by the PEB. Seemingly, both steps can be accomplished in a fully reliable way, as long as Microsoft decides to either completely remove one of the utilized functions, or make it an internal symbol. Since such a scenario is highly unlikely, we can safely assume that the technique is, and will be perfect for returning into user-code from difficult situations (such as a seriously damaged stack).

Disadvantages: One, possible disadvantage that comes into my mind, is that replacing the PEB pointer, containing the dispatch table might not be as easy as one might suppose. Due to the fact that high PEB offsets are likely to change between different Windows versions, the attacker should take this fact into consideration when planning a world-wide, cross-version attack. This downside doesn't change anything though, as it is possible to disrupt the execution yet inside the exported KiUserCallbackDispatcher, as mentioned before. If you know about any other drawbacks I am not aware of, please let me know.

Why so serious (about ring-3)?

Looking at the above text, one might wonder, why the problem is stated so that the kernel-to-user transition must take place, when it doesn't have to under normal circumstances. The answer is - because. When it comes to kernel-mode, there are bunches of bunches of possible scenarios, machine states, and other factors which sometimes can be predicted, and sometimes not; returning to user-mode might be the best choice, at times. One should keep in mind, however, that there are ways to terminate the current process from within ring-0 (such as nt!ZwTerminateProcess). Or better yet - once code execution is achieved, the process could simply load a regular rootkit driver (hiding the existence of the process), and remain in the idle state until machine reboot, by infinitely calling nt!ZwYieldExecution.

Conclusion

In this post, I aimed at presenting yet another, interesting scenario related to the kernel exploitation field, with a couple of possible solutions. Even thought situations of the described nature don't tend to happen very often, they do. Besides that, all four techniques are directed towards universality, so they can be used not only when a stack-based buffer overflow takes place, but whatever kind of situation when it is hard, or impossible to resume the original track of kernel code execution. So, that's it... comments are welcome, as always!

Have fun.

Additionally, the video and mp3 recordings from the presentation performed by me and Gynvael on the CONFidence 2010 conference, are now publicly available on the official website: link (Case study of recent Windows vulnerabilities).

Foreword

A majority of the LPC /supposedly an acronym for Local Inter-Process Communication rather than Local Procedure Calls, as stated in WRK/ basics have been described in the first post of Inter-process Communication chapter, together with the corresponding, undocumented native functions related to LPC Ports. As you already have the knowledge required to understand higher abstraction levels, today I would like to shed some light on the internal Csr~ interface provided by NTDLL and extensively utilized by the Win32 API DLLs (kernel32 and user32).

Introduction

As explained previously, LPC is an (officially) undocumented, packet-based IPC mechanism. It basically relies on two things - a Port Object and internal LPC structures, such as _PORT_HEADER - both unexposed to the Windows API layer. Due to the fact that CSRSS implements his own protocol on top of LPC, it would become highly inconvenient (and impractical) for the win32 libraries to take care of both LPC and CSRSS internals, at the same time. And so, an additional layer between the port-related functions and high-level API was created - let's call it Native Csr Interface.

The medium level of the call chain provides a set of helper functions, specifically designed to hide the internals of the communication channel from high-level API implementation. Therefore, it should be theoretically possible to re-implement the Csr-Interface using a different communication mechanism with similar properties, without any alterations being applied on the API level. This has been partially accomplished by replacing the deprecated LPC with an improved version of the mechanism - Advanced / Asynchronous LPC on modern NT-family systems (Vista, 7).

In this post, the precise meaning, functionalities and definitions of the crucial Csr~ routines will be focused on. After reading the article, one should be able to recognize and understand specific CSR API calls found inside numerous, documented functions related to console management, process / thread creation and others.

Connection Initialization

What has already been mentioned is the fact that every application belonging to the win32-subsystem is connected to the Windows Subsystem process (CSRSS) at its startup, by default. Although it is technically possible to disconnect from the port before the program is properly terminated, such behavior is beyond the scope of this post entry. However, some details regarding a security flaw related to CSRSS-port disconnection in the context of a live process, can be found here and here (discovered by me and Gynvael).

From this point on, it will be assumed that when the process is given execution (i.e. Entry Point, imported module's DllMain or TLS callback is called), the CSRSS connection is already established. And so, the question is - how, and where the connection is set up during the process initialization. This section provides answers for both of these questions.

Opening named LPC port

During a process creation, numerous parts of the system come into play and perform their part of the job. It all starts with the parent application calling an API function (CreateProcess) - the execution then goes through the kernel, a local win32 subsystem, and finally - ring-3 process self-initialization (performed by the system libraries). A step-by-step explanation of the Windows process creation can be found in the Windows Internals 5 book, Chapter "Processes, Threads and Jobs".

As the CSRSS connection is not technically crucial for the process to exist (and execute), it can be performed later than other parts of the process initialization. And so, the story of establishing a connection with the subsystem begins in the context of a newly-created program - more precisely, inside the kernel32 entry point (kernel32!BaseDllInitialize). At this point, the CSRSS-related part of the routine performs the following call:

BOOL WINAPI _BaseDllInitialize(HINSTANCE, DWORD, LPVID)
{
(...)
CsrClientConnectToServer(L"\\Windows",BASESRV_INDEX,...);
(...)
}

thus forwarding the execution to the ntdll.dll module, where a majority of the subsystem-related activities are performed. Before we dive into the next routine, two important things should be noted here:

1. The Base Dll (kernel32) has complete control over the Port Object directory and makes the final decision regarding the referenced port's name prefix. As it turns out, it is also possible for a different Object Directory to be used - let's take a look at the following pseudo-code listing:

   if(SessionId)
     swprintf(ObjectDirectory,L"%ws\\%ld%ws",L"\\Sessions",SessionId,L"\\Windows");
   else
     wcscpy(ObjectDirectory,L"\\Windows");
   

   The "SessionId" symbols represents a global DWORD variable, initialized inside the BaseDllInitialize function, as well:

    mov     eax, large fs:18h
    mov     eax, [eax+30h]
    mov     eax,  [eax+1D4h]
    mov     _SessionId, eax
   

   ... translated to the following high-level pseudo-code:

   SessionId = NtCurrentTeb()->SessionId;
   

   If one takes a look into the PEB structure definition, he will certainly find the variable:

   kd> dt _PEB
    nt!_PEB
    (...)
      +0x154 TlsExpansionBitmapBits : [32] Uint4B
      +0x1d4 SessionId        : Uint4B
      +0x1d8 AppCompatFlags   : _ULARGE_INTEGER
    (...)
   

2. If one decides to connect to the win32 subsystem, he must specify a particular ServerDll to connect to (csrsrv, basesrv, winsrv); the identification number is be passed as the second argument of CsrClientConnectToServer. As can be seen, kernel32 specifies the BASESRV_INDEX constant, as it desires to connect to a certain module - being basesrv in this case. Basesrv.dll is the kernel32 equivalent on the subsystem side - a Csr connection between these two modules is required for some of the basic win32 API calls to work properly.

   On the other hand, all of the console-management functionality is implemented by winsrv (to be exact - the consrv part of the module). And so - in order to take advantage of functions, such as AllocConsole, FreeConsole, SetConsoleTitle or WriteConsole - a valid connection with winsrv is also required. Fortunately - kernel32 remembers about it and issues a call to another internal function - ConDllInitialize() - after the LPC Port connection is successfully established. The routine's obvious purpose is to set up the console-related structures inside the Base dll image, and use the CsrClientConnectToServer function with the second argument set to CONSRV_INDEX.

When we make a step into CsrClientConnectToServer and analyze further, a great amount of CSRSS-related initialization code surrounds us. Don't worry - a huge part of the routine deals with user-mode structures and other irrevelant stuff - our interest begins, where the following call is made:

if(!CsrPortHandle)
{
ReturnCode = CsrpConnectToServer(ObjectDirectory); // ObjectDirectory is kernel32-controlled
if(!NT_SUCCESS(ReturnCode))
return (ReturnCode);
}

As the above indicates, the global CsrPortHandle variable is compared with zero - if this turns out to be true, CsrpConnectToServer is called, taking the object directory string as its only argument. So - let's face another routine ;>

The proc starts with the following code:

 CsrPortName.Length    = 0;
CsrPortName.MaxLength = 2*wcslen(ObjectDirectory)+18;
CsrPortName.Buffer    = RtlAllocateHeap(CsrHeap,NtdllBaseTag,CrsPortName.MaxLength);

RtlAppendUnicodeToString(&CsrPortName,ObjectDirectory);
RtlAppendUnicodeToString(&CsrPortName,L"\\");
RtlAppendUnicodeToString(&CsrPortName,L"ApiPort");

Apparently, the final Port Object name is formed here, and stored inside a local "UNICODE_STRING CsrPortName" structure. Next then, a special section is created, using an adequate native call:

 LARGE_INTEGER SectionSize = 0x10000;
NtStatus = NtCreateSection(&SectionHandle, SECTION_ALL_ACCESS, NULL, &SectionSize, PAGE_READWRITE, SEC_RESERVE, NULL);

if(!NT_SUCCESS(NtStatus))
return NtStatus;

This section is essential to the process<->subsystem communication, as this memory area is mapped in both the client and win32 server, and then used for exchanging large portions of data between these two parties. And so, when the section is successfully created, the routine eventually tries to connect to the named port!

 /* SID Initialization */
NtStatus = RtlAllocateAndInitializeSid(...,&SystemSid);
if(!NT_SUCCESS(NtStatus))
return NtStatus;

NtStatus = NtSecureConnectPort(&CsrPortHandle,&CsrPortName,...);
RtlFreeSid(SystemSid);
NtClose(&SectionHandle);

For the sake of simplicity and reading convenience, I've stripped the remaining arguments from the listing; they describe some advanced connection characteristics, and are beyond the scope of this post. When everything is fine up to this point, we have an established connection (yay, CSRSS accepted our request) and an open handle to the port. Therefore, we can start sending first packets, in order to let CSRSS (and its modules - ServerDlls) know about ourselves.

So - after returning back to ntdll!CsrClientConnectToServer:

 NtStatus = CsrpConnectToServer(ObjectName);
if(!NT_SUCCESS(NtStatus))
return NtStatus;

the following steps are taken:

 if(ConnectionInformation)
{
CaptureBuffer = CsrAllocateCaptureBuffer(1,InformationLength);
CsrAllocateMessagePointer(CaptureBuffer,InformationLength,&conn.ConnectionInformation);
RtlMoveMemory(conn.ConnectionInformation,ConnectionInformation,InformationLength);
}
CsrClientCallServer(&Message, CaptureBuffer, CSR_API(CsrpClientConnect), sizeof(ConnStructure));

First of all, the ConnectionInformation pointer is checked - in case it's non-zero, the CsrAllocateCaptureBuffer, CsrAllocateMessagePointer and RtlMoveMemory functions are called, respectively. The purpose of these operations is to move the data into a shared heap in such a way, that both our application and CSRSS can easily read its contents. After the "if" statement, a first, real message is sent to the subsystem using CsrClientCallServer, of the following prototype:

NTSTATUS CsrClientCallServer(PCSR_API_MSG m, PCSR_CAPTURE_HEADER CaptureHeader, CSR_API_NUMBER ApiNumber, ULONG ArgLength);

For a complete, cross-version compatible table and/or list of Csr APIs, check the following references: CsrApi List and CsrApi Table. And so, in the above snippet, the "CsrpClientConnect" API is used, providing additional information about the connecting process. This message is handled by an internal csrsrv.CsrSrvClientConnect routine, which redirects the message to an adequate callback function, specified by the ServerDll being connected to (in this case - basesrv!BaseClientConnectRoutine).

After sending the above message, the connection between the client- and server-side DLLs (i.e. kernel32 and basesrv) can be considered fully functional.

As it turns out, parts of the execution path presented above can be also true for CSRSS itself! Because of the fact that ntdll!CsrClientConnectToServer can be reached from inside the subsytem process, the CsrClientConnectToServer routine must handle such case properly. And so - before any actions are actually taken by the function, the current process instance is checked, first:

NtHeaders = RtlImageHeader(NtCurrentPeb()->ImageBaseAddress);
CsrServerProcess = (NtHeaders->OptionalHeader.Subsystem == IMAGE_SUBSYSTEM_NATIVE);

if(CsrServerProcess)
{
// Take normal steps
}
else
{
// Do nothing, except for the _CsrServerApiRoutine pointer initialization
_CsrServerApiRoutine = GetProcAddress(GetModuleHandle("csrsrv"),"CsrCallServerFromServer");
}

Apparently, every process connecting to the LPC Port that has the SUBSYSTEM_NATIVE header value set, is assumed to be an instance of CSRSS. This, in turn, implies that CSRSS is the only native, system-critical process which makes use of the Csr API calls.

Data tranmission

Having the connection up and running, a natural order of things is to exchange actual data. In order to achieve this, one native call is exported by ntdll - the CsrClientCallServer function, already mentioned in the text. Because of the fact that each Csr API requires a different amount of input/output data (while some don't need these, at all) from the requestor, as well as due to the LPC packet-length limitations, the messages can be sent in a few, different ways.

In general, all of the CSR-supported packets can be divided into three, main groups: empty, short, and long packets. Based on the group a given packet belongs to, it is sent using an adequate mechanism. This section provides a general overview of the data transmission-related techniques, as well as exemplary (practical) use of each type.

Empty packets

• Description

  "Empty packets" is a relatively small group of purely-informational messages, which are intended to make CSRSS perform a specific action. These packets don't supply any input data - their API ID is the only information needed by the win32 subsystem. A truely-empty packets don't generate any output data, either.

• Sending

  Due to the fact that "empty packets" don't supply any additional information, the only data being transferred is the internal _PORT_HEADER structure. The address of a correctly initialized PortHeader should be then passed as the first CsrClientCallServer parameter. The shared section doesn't take part while sending and handling these packets. What is more, no serious input validation is required by the API handler, because there is no input in the first place. The routine is most often supposed to perform one, certain action and then return. Unsupported APIs, statically returning the STATUS_UNSUCCESSFUL or STATUS_NOT_SUPPORTED error codes, can also be considered "empty packets", as they always behave the same way, regardless of the input information.

• Examples

  One, great example of an empty-packet is winsrv!SrvCancelShutdown. As the name implies, the APIs purpose is pretty straight-forward - cancelling the shutdown. Seemingly, no input / output arguments are necessary:

  ; __stdcall SrvCancelShutdown(x, x)
  _SrvCancelShutdown@8 proc near
    call    _CancelExitWindows@0 ; CancelExitWindows()
    neg     eax
    sbb     eax, eax
    and     eax, 3FFFFFFFh
    add     eax, 0C0000001h
    retn    8
  _SrvCancelShutdown@8 endp
  

  As shown above, the handler issues a call to the CancelExitWindows() function, and doesn't make use of any of the two parameters. Another CsrApi function of this kind is basesrv!BaseSrvNlsUpdateCacheCount, always performing the same task:

  ; __stdcall BaseSrvNlsUpdateCacheCount(x, x)
  _BaseSrvNlsUpdateCacheCount@8 proc near
    cmp     _pNlsRegUserInfo, 0
    jz      short loc_75B28AFC
    push    esi
    mov     esi, offset _NlsCacheCriticalSection
    push    esi
    call    ds:__imp__RtlEnterCriticalSection@4 ; RtlEnterCriticalSection(x)
    mov     eax, _pNlsRegUserInfo
    inc     dword ptr [eax+186Ch]
    push    esi
    call    ds:__imp__RtlLeaveCriticalSection@4 ; RtlLeaveCriticalSection(x)
    pop     esi
  loc_75B28AFC:
    xor     eax, eax
    retn    8
  _BaseSrvNlsUpdateCacheCount@8 endp
  

  A few more examples can be found - looking for these is left as an exercise for the reader.

Short packets

• Description

  The "short packets" group describes a great part of the Csr messages. Every request, passing actual data to / from CSRSS but fitting in the LPC-packet length restriction belongs to this family. And so - most fixed-size (i.e. these, that don't contain volatile text strings or other, possibly long chunks of data) structures are indeed smaller than the 304-byte limitation.

• Sending

  As this particular type requires additional data to be appended at the end of the _PORT_MESSAGE structure, a set of API-specific structs has been created. All of these types begin with the standard LPC PortMessage header, and then specify the actual variables to send, e.g.:

  struct CSR_MY_STRUCTURE
  {
    struct _PORT_HEADER PortHeader;
    BOOL  Boolean;
    ULONG Data[0x10];
    DWORD Flags;
  };
  

  Such amount of data can be still sent in a single LPC packets. And so, a custom structure, beginning with the _PORT_HEADER field must be used as a first CsrClientCallServer argument. The Capture Buffer technique remains unused, thus the second parameter should be set to NULL.

• Examples

  As for the examples, it is really easy to list a couple:

  1. winsrv!SrvGetConsoleAliasExesLength
  2. winsrv!SrvSetConsoleCursorMode
  3. winsrv!SrvGetConsoleCharType
  4. basesrv!BaseSrvExitProcess
  5. basesrv!BaseSrvBatNotification

  The above handlers take a constant number of bytes as the input, and optionally return some data (of static length, as well).

Long packets

• Description

  From the researcher's point of view, the "long packets" group is doubtlessly the most interesting one. Due to the fact that they are used to send/receive large amounts of data (beyond the maximum size of a LPC message), a special mechanism called a Shared Section is used for transferring these messages. Let's take a look at the details.

• Initialization

  Do you remember the ntdll!CsrpConnecToServer function? At some point, between forming the port name and establishing the connection, we could see a weird NtCreateSection(0x10000) call. As it turns out, this section is a special memory area, mapped in both the client and server processes. After creating the section, its handle is passed to CSRSS through the NtSecureConnectPort native call. Once the win32 subsystem receives a connection request and accepts it, the section is mapped into the server's virtual address space. Next then, CSRSS provides its client with some basic memory mapping information - such as the server-side base address and view size. Based on the supplied info, a few global variables are initialized (CsrProcessId, CsrObjectDirectory), with CsrPortMemoryRemoteDelta being the most important one for us:

  CsrPortMemoryRemoteDelta = (CSRSS.BaseAddress - LOCAL.BaseAddress);
  

  Basically, the above variable is filled with the distance between the server- and user- mappings of the shared memory. This information is going to appear to be crucial to exchange information, soon. Furthermore, a commonly known structure called "heap" is created on top of the allocation:

  CsrPortHeap = RtlCreateHeap(0x8000u, LOCAL.BaseAddress, LOCAL.ViewSize, PageSize, 0, 0);
  

  From this point on, the shared heap is going to be used thorough the whole communication session, for passing data of various size and content. The functions taking advantage of the heap are:

  1. CsrAllocateCaptureBuffer
  2. CsrFreeCaptureBuffer
  3. CsrAllocateMessagePointer (indirect)
  4. CsrCaptureMessageBuffer (indirect)
  5. CsrCaptureMessageString (indirect)

  All of the above routines are apparently related to the "Capture Buffer" mechanism, described in the following section.

  • Capture Buffers

    In order to fully understand the idea behind Capture Buffers, one should see it as a special box, a container designed to hold data in such a way, that it can be easily accessed by both sides of the communication (i.e. be offset-based rather than VA-based etc). Such structure is determined by the following characteristics:

    1. Number of memory blocks: one Capture Buffer is able to hold mulitple data blocks - e.g. a couple of strings, describing a specific object (like a console window).

    2. Total size: the total size of the container, including its header, pointer table, and the data blocks themselves.

    So - these "data boxes" are used to transfer data between the two parties. In order to illustrate this complex the mechanism, suppose we've got the following structure:

    struct CSR_MESSAGE
    {
      _PORT_HEADER PortHeader;
      LPVOID FirstPointer;
      LPVOID SecondPointer;
      LPVOID ThirdPointer;
      LPVOID ForthPointer;
      LPVOID FifthPointer;
    } m;
    

    The above packet is going to be sent to CSRSS after the initialization takes place. Having the above declared, we can take a closer look at each of the CA-related functions:

    1. CsrAllocateCaptureBuffer(ULONG PointerCount, ULONG Size)

       Allocates an adequate number of bytes from CsrHeap:

       (Size + sizeof(CAPTURE_HEADER) + PointerCount*sizeof(LPVOID))

       ... and returns the resulting pointer to the user. Right after the allocation, the CaptureBuffer structure contents look like this:

       CaptureBuffer = AllocateCaptureBuffer(5,20);

       

       Due to the fact that no messages have been allocated from the CaptureBuffer yet, Capture.Memory is a single memory block, while the Capture.Pointers[] array remains empty.

    2. CsrFreeCaptureBuffer(LPVOID CaptureBuffer)

       Frees a given CaptureBuffer memory area, by issuing a simple call:

       RtlFreeHeap(CsrHeap,0,CaptureBuffer);
       

    3. CsrAllocateMessagePointer(LPVOID CaptureBuffer, ULONG Length, PVOID* Pointer)

       The routine allocates "Length" bytes from the CaptureBuffer's general memory block. The address of the newly allocated block is stored inside *Pointer, while Pointer is put into one of the Capture.Pointers[] items.

       Example:

       CsrAllocateMessagePointer(CaptureBuffer,3,&m.FirstPointer);
       

       

    4. Having three (out of twenty) bytes allocated, one can copy some data:

       RtlCopyMemory(m.FirstPointer,"\xcc\xcc\xcc",3);
       

       After all of the five allocations are made, the CaptureBuffer structure layout can look like this:

       

       It is important to keep in mind that the pointers into CaptureBuffer.Memory[] must reside in the actual LPC message being sent to the server - the reason of this requirement will be disclosed, soon

    5. CsrCaptureMessageBuffer(LPVOID CaptureBuffer, PVOID Buffer, ULONG Length, PVOID *OutputBuffer)

       The routine is intended to simplify things for the developer, by performing the CaptureBuffer-allocation and copying the user specified data at the same time.

       Pseudocode:

        CsrAllocateMessagePointer(CaptureBuffer,Length,OutputBuffer);
        RtlCopyMemory(*OutputBuffer,Buffer,Length);
       

    6. CsrCaptureMessageString(LPVOID CaptureBuffer, PCSTR String, ULONG Length, ULONG MaximumLength, PSTRING OutputString)

       Similar to the previous routine - allocates the requested memory space, and optionally copies a specific string into the new allocation.

    After the Capture Buffer is allocated and initialized (all N memory blocks are in use), it's time to send the message, already! This time, we fill in the second parameter of the CsrClientCallServer routine with our CaptureBuffer pointer. When the following call is issued:

    CsrClientCallServer(&m,CaptureBuffer,API_NUMBER,sizeof(m)-sizeof(_PORT_HEADER));
    

    ... and the 2nd argument is non-zero, a couple of interesting conversions are taking place in the above routine. This is the time when the CsrPortMemoryRemoteDelta value comes into play. First of all, the data-pointers residing in the CSR_MESSAGE structure (&m) are translated to a server-compatible virtual address, by adding the RemoteDelta. From now on, the m.FirstPointer, m.SecondPointer, ..., m.FifthPointer are invalid in the context of the local process, but are correct in terms of server-side memory mapping.

    for( UINT i=0;iPointerCount;i++ )
      *CaptureBuffer.Pointers[i] += CsrPortMemoryRemoteDelta;
    

    Furthermore, the CaptureBuffer.Pointers[] array is altered, using the following pseudo-code:

    for( UINT i=0;iPointerCount;i++ )
       CaptureBuffer.Pointers[i] -= &m;
    

  So, to sum everything up - after the address/offset translation is performed, we've got the following connection between the LPC message and shared buffer:

  • m.CaptureBuffer points to the server's virtual address of the CaptureBuffer base,
  • CaptureBuffer->Pointers[] contain the relative offsets of the data pointers, i.e. (&m+CaptureBuffer->Pointers[0]) is the pointer to the first capture buffer,
  • (&m+CaptureBuffer->Pointers[n]) points to the server's virtual address of the n-th capture buffer.

  Or, the same connection chain illustrated graphically looks like this:

  

  When both the local CSR_MESSAGE and shared CaptureBuffer structures are properly modified, ntdll!CsrClientCallServer calls the standard NtRequestWaitReplyPort LPC function, and waits for an optional output. When the native calls returns, all of the modified struct fields are restored to their original values, so that the user (or, more likely - win32 APIs) can easily read the error code and optional subsytem's output.

  Due to the fact that the VA- and offset-related conversions are non-trivial to be explained in words, I strongly advice you to check the information presented in this post by yourself. This should give you even better insight at how the cross-process data exchange reliability is actually achieved.

• Sending

  What's been already described - if one wants to make use of large data transfers, he must allocate a CaptureBuffer, specifying the number of memory blocks and the total byte count, fill it with the desired data (using CsrCaptureMessageBuffer or CsrCaptureMessageString), and call the CsrClientCallServer, supplying an LPC structure, (containing the data-pointers into CaptureBuffer) as the first parameter, and the CaptureBuffer itself - as the second one. The rest of the job is up to ntdll. Please keep in mind that one CaptureBuffer can be technically utilized only once - and therefore, it should be freed after its first (and last) usage, using CsrFreeCaptureBuffer.

• Examples

  In this particular case, every CsrApi handler using the CsrValidateMessageBuffer import makes a good example, let it be:

  • winsrv!SrvAllocConsole
  • winsrv!SrvSetConsoleTitle
  • winsrv!SrvAddConsoleAlias

  ... and numerous other functions, which are pretty easy to find by oneself.

Conclusion

This post entry aimed to briefly present the "Native Csr Interface" - both in terms of the functions, structures and mechanisms playing some role in the Inter-Process Communication. As you must have noted, only client-side perspective has been described here, as the precise way of CSRSS receiving, handling and responding to the request is a subject for another, long article (or two). And so - if you feel like some important Csr~ routines should have been described or mentioned here - let me know. On the other hand, I am going to cover the remaining, smaller functions (such as CsrGetProcessId) in one, separate post called CSRSS Tips & Tricks.

Watch out for (part 3/3) and don't hesitate to leave constructive comments!
Cheers!

As you must have already noticed (unless using a RSS reader), the monolithic, light blue (otherwise known as cyan) background color has been replaced with a  stylish, purple image sized 1680 x 1260. Due to the fact that I've been encountering some major compatibility problems (scroll-lagging, incompatibility with certain browsers), the picture does not cover the entire area in case a higher resolution is used. Should you experience any problems (e.g. wrong rendering) with the current appearance, please let me know ASAP (specifying the browser name/version by the way). Comments with opinions regarding the current style are also welcome! Furthermore, I decided to make use of the "display summary" setting, so that the latest post entries are printed in a shortened form, instead of flooding the screen with entire contents. The behavior applies to other functionalities, such as the search engine, as well. Hopefully, this will improve the general blog readability

As for the second part of the post - a few days ago, I have recalled of a small, experimental research performed by the HSPL team roughly a year ago. Having the The Art of Software Testing (by Glenford J. Myers) book read, we decided to try one of the presented code auditing approaches in practice, on real software. As it was closely related to the vulnerability-hunting subject, a popular, yet open-source project was about to be focused on. After a few minutes of live discussion, it became clear that the target would be none other than PHP! (or more precisely, one of its default extensions, such as php_exif).

The general idea behind the auditing technique is fairly simple - once the adequate number of copies of the target source code is printed on a piece of paper (i.e. one for each person taking part), one of the participants starts reading the source code aloud, line by line, starting from the attacker's entry point (like an exported routine, available to the .php script). In the meantime, the rest of the team exchanges their thoughts and tries to think of every possible inconsistency in the current code row - when one is found, the general analysis is suspended for the time of testing a potential vulnerability. If a function call is encountered, the execution position is written down on some paper, and the analysis is continued from the beginning of the new routine. What's more, the technique could be employed with a monitor together with a text-editor fired up (making some of the activities much easier), as well; the choice is up to your crew.

The actual efficiency is obviously different for various projects - keep in mind that every open-source application follows its own set of coding / security rules and possibly imposes certain types of security flaws. Besides, I highly recommend every bug-hunter to make an effort and test this approach on himself - it is a very informative experience, in my opinion. When it comes to our results,  we ended up with three different ways of crashing the latest (at the time of the research) version of PHP on every software platform, plus another three minor memory disclosure flaws. All of these were related to image format parsing (TIFF and JPEG) functionalities. After sending the explanatory advisories to the PHP devs, the bugs were eventually fixed - however, no real credit has been given to our work. Shit happens.

If you are highly interested in the PHP engine/extension code quality, feel free to take a look at the provided advisory documents.

A complete package, containing a bunch of short, technical papers (there are six in total) can be found here (ZIP, 11kB).
Sorry for not providing the PoCs - these are way too dirty to see the public light

So... that's it! Have fun reading the docs, necessarily leave a comment on the blog appearance and... see you in a next post!

Local Procedure Calls

Before starting to analyze the mystery API interface implemented by CSRSS (otherwise known as CsrApi), one must first get some basic knowledge regarding the internal mechanism, used to establish a stable inter-process connection and actually exchange information.

The basics

LPC is a packet-based, inter-process communication mechanism implemented in the NT kernel (supported since the very first Windows NT versions - most likely 3.51). The mechanism was originally designed so that it was possible to communicate between modules running in different processor privilege levels - i.e. process - process, process - driver and driver - driver connections are equally well supported. This is possible thanks to the fact that the required API functions are exposed to both user-mode (via ntdll.dll) and kernel-mode (via ntoskrnl.exe). Even though we are mostly concerned by the first scenario (where numerous ring-3 processes communicate with csrss.exe), practical examples of the remaining two also exist - let it be the Kernel Mode Security Support Provider Interface (KSecDD.sys) communicating with LSASS.exe, for instance. Apart from being used by certain system processes talking to each other (e.g. Lsass verifying user credentials on behalaf of Winlogon), LPC is also a part of the RPC (Remote Procedure Call) implementation.

What should be also noted is that the LPC mechanism is directed towards synchronous communication, and therefore enforces a blocking scheme, where the client must wait until its request is dispatched and handled, instead of continuing its execution. As mentioned in the Introduction section, Windows Vista has brought some major changes in this matter - one of these changes was the implementation of a brand new mechanism called ALPC (standing for Advanced or Asynchronous LPC - which one?), deprecating the old LPC mechanism. Since then, all the client - server requests are performed in an asynchronous manner, so that the client is not forced to wait for the response, for ages.

Underlying port objects

As it turns out, a great part of the Windows system functionalities internally rely on special, dedicated objects (implemented by the Object Manager) - let it be File System operations, Windows Registry management, thread suspension or whatever you can think of - the LPC mechanism isn't any different. In this particular case, we have to deal with a port object, otherwise known as LpcPortObjectType. The OBJECT_TYPE structure, describing the object in consideration, is defined as follows:

kd> dt _OBJECT_TYPE 81feca90 /r
ntdll!_OBJECT_TYPE
   +0x000 Mutex            : _ERESOURCE
   +0x038 TypeList         : _LIST_ENTRY [ 0x81fecac8 - 0x81fecac8 ]
   +0x040 Name             : _UNICODE_STRING "Port"
     +0x000 Length           : 8
     +0x002 MaximumLength    : 0xa
     +0x004 Buffer           : 0xe1007110  "Port"
   +0x048 DefaultObject    : 0x80560960 Void
   +0x04c Index            : 0x15
   +0x050 TotalNumberOfObjects : 0xdb
   +0x054 TotalNumberOfHandles : 0xd9
   +0x058 HighWaterNumberOfObjects : 0xdb
   +0x05c HighWaterNumberOfHandles : 0xd9
   +0x060 TypeInfo         : _OBJECT_TYPE_INITIALIZER
      +0x000 Length           : 0x4c
      +0x002 UseDefaultObject : 0x1 ''
      +0x003 CaseInsensitive  : 0 ''
      +0x004 InvalidAttributes : 0x7b2
      +0x008 GenericMapping   : _GENERIC_MAPPING
      +0x018 ValidAccessMask  : 0x1f0001
      +0x01c SecurityRequired : 0 ''
      +0x01d MaintainHandleCount : 0 ''
      +0x01e MaintainTypeList : 0 ''
      +0x020 PoolType         : 1 ( PagedPool )
      +0x024 DefaultPagedPoolCharge : 0xc4
      +0x028 DefaultNonPagedPoolCharge : 0x18
      +0x02c DumpProcedure    : (null)
      +0x030 OpenProcedure    : (null)
      +0x034 CloseProcedure   : 0x805904f3        void  nt!ObReferenceObjectByName+0
      +0x038 DeleteProcedure  : 0x805902e1        void  nt!ObReferenceObjectByName+0
      +0x03c ParseProcedure   : (null)
      +0x040 SecurityProcedure : 0x8056b84f        long  nt!CcUnpinDataForThread+0
      +0x044 QueryNameProcedure : (null)
      +0x048 OkayToCloseProcedure : (null)
 +0x0ac Key              : 0x74726f50
 +0x0b0 ObjectLocks      : [4] _ERESOURCE

This object can be considered a specific gateway between two modules - it is being used by both sides of the communication channel, while not seeing each other directly at the same time. More precisely, the subject of our considerations are named ports, only; this is caused by the fact that the object must be easily accessible for every possible process.

After the server correctly initializes a named port object - later utilized by the clients - it waits for an incoming connection. When a client eventually decides to connect, the server can verify whether further communication should or shouldn't be allowed (usually based on the client's CLIENT_ID structure). If the request is accepted, the connection is considered established - the client is able to send input messages and optionally wait for a response (depending on the packet type).

Every single packet exchanged between the client and server (including the initial connection requests) begins with a PORT_MESSAGE structure, of the following definition:

 //
 // LPC Port Message
 //
 typedef struct _PORT_MESSAGE
 {
   union
   {
     struct
     {
       CSHORT DataLength;
       CSHORT TotalLength;
     } s1;
     ULONG Length;
   } u1;

   union
   {
     struct
     {
       CSHORT Type;
       CSHORT DataInfoOffset;
     } s2;
     ULONG ZeroInit;
   } u2;

   union
   {
     LPC_CLIENT_ID ClientId;
     double DoNotUseThisField;
   };

   ULONG MessageId;

   union
   {
     LPC_SIZE_T ClientViewSize;
     ULONG CallbackId;
   };
 } PORT_MESSAGE, *PPORT_MESSAGE;

The above header consist of the most essential information concerning the message, such as:

• DataLength
  Determines the size of the buffer, following the header structure (in bytes)
• TotalLength
  Determines the entire size of the packet, must be equal sizeof(PORT_MESSAGE) + DataLength
• Type
  Specifies the packet type, can be one of the following:

   //
   // LPC Message Types
   //
   typedef enum _LPC_TYPE
   {
     LPC_NEW_MESSAGE,
     LPC_REQUEST,
     LPC_REPLY,
     LPC_DATAGRAM,
     LPC_LOST_REPLY,
     LPC_PORT_CLOSED,
     LPC_CLIENT_DIED,
     LPC_EXCEPTION,
     LPC_DEBUG_EVENT,
     LPC_ERROR_EVENT,
     LPC_CONNECTION_REQUEST,
     LPC_CONNECTION_REFUSED,
     LPC_MAXIMUM
   }  LPC_TYPE;
  

• ClientId
  Identifies the packet sender by Process ID and Thread ID
• MessageId
  A unique value, identifying a specific LPC message

Due to the fact that LPCs can be used to send both small and large amounts of data - two, distinct mechanisms of passing memory between the client and server were developed. In case 304 or less bytes are requested to be sent, a special LPC buffer is used and sent together with the header (described by Length and DataLength), while greater messages are passed using shared memory sections, mapped in both parties taking part in the data exchange.

LPC Api

Due to the fact that LPC is an internal, undocumented mechanism (mostly employed by the system executables), one cannot make use of it based on the win32 API alone. However, a set of LPC-management native routines is exported by the ntdll module; using these functions, one is able to build his own LPC-based protocol and use it on his own favor (e.g. as a fast and convenient IPC technique). A complete list of the Native Calls follows:

1. NtCreatePort
2. NtConnectPort
3. NtListenPort
4. NtAcceptConnectPort
5. NtCompleteConnectPort
6. NtRequestPort
7. NtRequestWaitReplyPort
8. NtReplyPort
9. NtReplyWaitReplyPort
10. NtReplyWaitReceivePort
11. NtImpersonateClientOfPort
12. NtSecureConnectPort

The above list is somewhat correspondent to the cross-ref table for _LpcPortObjectType (excluding NtQueryInformationPort, NtRegisterThreadTerminatePort and a couple of other routines).. All of the functions are more or less documented by independent researchers, Tomasz Nowak and Bo Branten - a brief description of each export is available on the net, though most of the symbols speak by themselves anyway. Having the function names, let's take a look at how the functions can be actually taken advantage of!

Server - Setting up a port

In order to make the server reachable for client modules, it must create Named Port by calling NtCreatePort (specyfing the object's name and an optional security descriptor):

NTSTATUS NTAPI
NtCreatePort
 (OUT PHANDLE PortHandle,
  IN POBJECT_ATTRIBUTES ObjectAttributes,
  IN ULONG MaxConnectInfoLength,
  IN ULONG MaxDataLength,
  IN OUT PULONG Reserved OPTIONAL );

When the LPC port is successfully created, it becomes visible to other, external modules - potential clients.

Server - Port Listening

In order to accept an inbound connection, the server starts listening on the newly created port, awaiting for the clients. This is achieved using a NtListenPort routine of the following definition:

NTSTATUS
NTAPI
NtListenPort
(IN HANDLE PortHandle,
 OUT PLPC_MESSAGE ConnectionRequest);

Being dedicated to the synchronous approach, the function blocks the thread and waits until someone tries to make use of the port. And so, while the server is waiting, some client eventually tries to connect...

Client - Connecting to a Port

Knowing that the port has already been created and is currently waiting (residing inside NtListenPort), our client process is able to connect, specifying the port name used during the creation proces. The following function will take care of the rest:

NTSTATUS
NTAPI
NtConnectPort
(OUT PHANDLE ClientPortHandle,
 IN PUNICODE_STRING ServerPortName,
 IN PSECURITY_QUALITY_OF_SERVICE SecurityQos,
 IN OUT PLPC_SECTION_OWNER_MEMORY ClientSharedMemory OPTIONAL,
 OUT PLPC_SECTION_MEMORY ServerSharedMemory OPTIONAL,
 OUT PULONG MaximumMessageLength OPTIONAL,
 IN ConnectionInfo OPTIONAL,
 IN PULONG ConnectionInfoLength OPTIONAL );

Server - Accepting (or not) the connection

When a client tries to connect at one side of the port, the server's execution track returns from NtListenPort, having the PORT_MESSAGE header filled with information. In particular, the server can access a CLIENT_ID structure, identifying the source process/thread. Based on that data, the server can make the final decision whether to allow or refuse the connection. Whatever option is chosen, the server calls a NtAcceptConnectPort function:

NTSTATUS
NTAPI
NtAcceptConnectPort
 (OUT PHANDLE ServerPortHandle,
  IN HANDLE AlternativeReceivePortHandle OPTIONAL,
  IN PLPC_MESSAGE ConnectionReply,
  IN BOOLEAN AcceptConnection,
  IN OUT PLPC_SECTION_OWNER_MEMORY ServerSharedMemory OPTIONAL,
  OUT PLPC_SECTION_MEMORY ClientSharedMemory OPTIONAL );

In case of a rejection, the execution ends here. The client returns from the NtConnectPort call with an adequate error code (most likely STATUS_PORT_CONNECTION_REFUSED), and the server ends up calling NtListenPort again. If, however, the server decides to proceed with the connection, another routine must be called:

 NTSTATUS
 NTAPI
 NtCompleteConnectPort
 (IN HANDLE PortHandle);

After the above function is triggered, our connection is confirmed and read to go!

Server - Waiting for a message

After opening up a communication channel, the server must begin listening for incoming packets (or client-related events). Because of the specific nature of LPC, the server is unable to send messages by itself - rather than that, it must wait for the client to send a request, and then possibly respond with a piece of data. And so, in order to (as always - synchronously) await a message, the server should call the following function:

 NTSTATUS
 NTAPI
 NtReplyWaitReceivePort
 (IN HANDLE PortHandle,
  OUT PHANDLE ReceivePortHandle OPTIONAL,
  IN PLPC_MESSAGE Reply OPTIONAL,
  OUT PLPC_MESSAGE IncomingRequest);

Client - Sending a message

Having the connection established, our client is now able to send regular messages, at the time of its choice. Moreover, the application can choose between one-side packets and interactive requests. By sending the first type of message, the client does not expect the server to reply - most likely, it is a short, informational packet. On the other hand, interactive messages require the server to fill in a return buffer of a given size. These two packet types can be sent using different native calls:

NTSTATUS
NTAPI
NtRequestPort
(IN HANDLE PortHandle,
 IN PLPC_MESSAGE Request);

or

NTSTATUS
NTAPI
NtRequestWaitReplyPort
(IN HANDLE PortHandle,
 IN PLPC_MESSAGE Request,
 OUT PLPC_MESSAGE IncomingReply);

Apparently, the difference between these two definitions are pretty much obvious

Server - Replying to incoming packets

In case the client requests data from the server, the latter is obligated to respond providing some output data. In order to do so, the following function should be used:

NTSTATUS
NTAPI
NtReplyPort
(IN HANDLE PortHandle,
 IN PLPC_MESSAGE Reply);

Client - Closing the connection

When, eventually, the client either terminates or decides to close the LPC connection, it can clean up the connection by simply dereferencing the port object - the NtClose (or better, documented CloseHandle) native call can be used:

NTSTATUS
 NTAPI
 NtClose(IN HANDLE ObjectHandle);

The entire IPC process has already been presented in a visual form - some very illustrative flow charts can be found here (LPC Communication) and here (LPC Part 1: Architecture).

All of the described functions are actually used while maintaining the CSRSS connection - you can check it by yourself! What should be noted though, is that the above summary covers the LPC communication (which can be already used to create an IPC framework), but tells nothing about what data, in particular, is being sent over the named port. Obviously, the Windows Subsystem manages its own, internal communication protocol implemented by both client-side (ntdll.dll) and server-side (csrsrv.dll, winsrv.dll, basesrv.dll) system libraries.

In order to make it more convenient for kernel32.dll to make use of the CSR packets, a special subset of routines dedicated to CSRSS-communication exists in ntdll.dll. The list of these functions includes, but is not limited to:

1. CsrClientCallServer
2. CsrClientConnectToServer
3. CsrGetProcessId
4. CsrpConnectToServer

Thanks to the above symbols, it is possible for kernel32.dll (and most importantly - us) to send custom messages on behalf of the current process, without a thorough knowledge of the protocol structure. Furthermore, ntdll.dll contains all the necessary, technical information required while talking to CSRSS, such as the port name to connect to. The next post is going to talk over both client- and user- sides of the LPC initialization and usage, as it is practically performed - watch out

Conclusion

All in all, a great number of internal Windows mechanisms make use of LPC - both low-level ones, such as the Windows debugging facility or parts of exception handling implementation, as well as high-level capabilities, including user credentials verification performed by LSASS. One can list all of the named (A)LPC port object present in the system using the WinObj tool by Windows Sysinternals. It is also highly recommended to create one's own implementation of a LPC-based inter-process communication protocol - a very learning experience. An exemplary source code can be found in the following package: link.

Have fun, leave comments and stay tuned for respective entries ;D

References

1. LPC Communication
2. Local Procedure Calls (LPCs)
3. LPC Part 1: Architecture
4. Sysinternals WinObj
5. Windows Privilege Escalation through LPC
6. Ntdebugging on LPC interface

Environment subsystems in Windows

The general idea behind the environment subsystems is to expose a strictly-defined subset of native functions to the user application. Because of the fact that Windows OS was designed to support both native Windows and POSIX (Portable Operating System Interface for Unix) executables, the developers had to separate API for both types of applications. Each of the supported subsystems consists of two, major parts:

• The subsystem process - a regular ring-3 application, responsible for handling some of the subsystem-specific functions.
• The subsystem DLLs - a special set of system libraries dedicated to a certain subsystem; they provide an additional layer between user programs and the native system calls.

As it turns out, the Windows Subsystem - otherwise known as CSRSS (Client/Server Runtime Subsystem) is an obligatory part of the system execution environment; in other words, Windows is unable to work correctly without CSRSS.exe running in the background. Because of the duties bound to CSRSS, the subsystem is required on every Windows, including the server editions (which doesn't deal with interactive user sessions). On the other hand, POSIX (psxss.exe) belongs to the optional subsystems group - therefore, the process is started on demand, only.

Some specific configuration data, related to all of the supported subsystems can be found in the following registry key:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems

By default, the subsystem configuration looks similar to the following:

• Name:  Debug
  Type:  REG_EXPAND_SZ
  Value:

• Name:  Kmode
  Type:  REG_EXPAND_SZ
  Value: \SystemRoot\System32\win32k.sys

• Name:  Optional
  Type:  REG_MULTI_SZ
  Value: Posix

• Name:  Posix
  Type:  REG_EXPAND_SZ
  Value: %SystemRoot%\system32\psxss.exe

• Name:  Required
  Type:  REG_MULTI_SZ
  Value: Debug Windows

• Name:  Windows
  Type:  REG_EXPAND_SZ
  Value: %SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,20480,768 Windows=On ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ServerDll=sxssrv,4 ProfileC

Most of us already know the subsystem DLLs, supporting the Windows API - these are basically kernel32.dll, user32.dll, gdi32.dll, advapi32.dll, and many more - a majority of these libraries are used by numerous Windows software developers by their daily routine. When it comes to POSIX, only one module is apparently enough to implement the desired Unix API - that's psxdll.dll.

Furthermore, each process is associated with one, certain subsystem; this property is being set by the linker (during the compilation process), and resides in the following PE structure field:

WORD IMAGE_PE_HEADERS.IMAGE_OPTIONAL_HEADER.Subsystem

while the available constant values are listed below:

#define IMAGE_SUBSYSTEM_UNKNOWN    0
#define IMAGE_SUBSYSTEM_NATIVE    1
#define IMAGE_SUBSYSTEM_WINDOWS_GUI    2
#define IMAGE_SUBSYSTEM_WINDOWS_CUI    3
#define IMAGE_SUBSYSTEM_OS2_CUI        5
#define IMAGE_SUBSYSTEM_POSIX_CUI    7
#define IMAGE_SUBSYSTEM_NATIVE_WINDOWS    8
#define IMAGE_SUBSYSTEM_WINDOWS_CE_GUI    9
#define IMAGE_SUBSYSTEM_EFI_APPLICATION    10
#define IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER    11
#define IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER    12
#define IMAGE_SUBSYSTEM_EFI_ROM    13
#define IMAGE_SUBSYSTEM_XBOX    14

As can be seen, the Portable Executable format is pretty vast, and can be used to build executables for different processor (Intel x86, Intel x86-64, ARM) and system (Microsoft Windows, WIndows CE, EFI, XBOX) architecture.

API division based on the kernel and subsystem involvement

As it turns out, the subsystem process (such as csrss.exe) doesn't necessarily have to take part in every API call being issued by an user application. Due to the fact that the actual API implementation resides in the Enviroment DLLs, they can decide whether to communicate with the NT Kernel and/or subsystem process or not. In particular, one can distinguish three separate types of API routines:

• The function is entirely implemented by the Subsystem DLL, hence no signal is being sent to either the kernel or subsystem process. This is the case for a majority of simple helper functions, such as GetCurrentProcess or GetCurrentThread (both of these routines return a constant pseudo-handle), functions which implement ring-3 mechanisms, e.g. SwitchToFiber, or functions implementing a specific processor feature, like InterlockedIncrement oraz InterlockedExchange (read more about Interlocked Variable Access),

• The function must issue one or more calls into the NT Kernel in order to complete correctly. The functionalities provided by these routines require ring-0 privileges (e.g. in order to switch the process context), thus cannot be entirely implemented by the DLL. On the other hand, these functions perform subsystem-unrelated operations, and thus don't have to communicate with the subsystem process. Examples of such functions include ReadProcessMemory and WriteProcessMemory, both responsible for operating on memory address space belonging to an external process.

• The function takes advantage of mechanisms implemented by the subsystem process, and must therefore send one or more requests e.g. to csrss.exe. In this case, the client application issues a special packet via some Inter-Process communication mechanism [in this case - (Advanced) Local Procedure Calls], using an internal, undocumented protocol. A great example of this API type can be CreateProcess or CreateRemoteThread, as both of them must inform CSRSS about creating a new process/thread; otherwise, the entire function would fail (a win32 process/thread cannot be successfully spawned without letting the subsystem know about this being done).

CSRSS then

Surprisingly, on Windows versions prior to NT4, the Windows Subsystem was responsible for performing much more work than it is now. More precisely, both the Window Manager and Graphic Services were a part of that user-mode application! Due to the fact that a special, separate process was used, dedicated to dealing with the window / graphics management, enormous efficiency problems began arising. That's because every time a normal graphics-oriented application sent a request to CSRSS, a bunch of time had to be taken in order to switch the process / thread context between the client and server. Even though the developers were doing their best to optimize the communication process, it was still worse than it could be, having the window management implemented in kernel-mode. In particular, the problem was most noticeable in the context of graphics intense programs - and so, in Windows NT4, a majority of the graphics-related code was moved into a special system driver called win32k.sys, which is available to user-mode applications through the standard system-call mechanism (just like the core NT functions are).

The question is - what has actually remained after replacing CSRSS's main functionality with a ring-0 module?

CSRSS now

Nowadays, the Client/Server Runtime subsystem is responsible for performing a few minor tasks, related to:

• Console Window management (prior to Windows 7),
• Process and Thread list management,
• Supporting the 16-bit virtual DOS machine emulation (VDM),
• Other, miscellaneous functions, such as GetTempFile, DefineDosDevice, ExitWindows and more.

All of the above functionalities are generally implemented by three DLLs (otherwise known as ServerDlls), imported by the csrss.exe image:

1. BASESRV.DLL (process and thread lists, VDM support)

2. WINSRV.DLL (console management, user services)

3. CSRSRV.DLL (misc)

A complete list of the functions supported on different Windows OS versions can be found here (sorted by the dispatch table) and here (by OS version).

Windows CSRSS instances

If we already know that CSRSS is a standard, user-mode application - the question is, when is it spawned, how many instances of the process should be concurrently running in the system, and what security token csrss.exe executes with. Let's answer these questions respectively.

The actual time and number of csrss.exe processes being spawned is different on Windows XP and Windows Vista together with Seven. In the first case, CSRSS is created at boot time, by the Session Manager (smss.exe) process, right after loading the win32k.sys module into kernel memory. The process inherits his parent's security token, and therefore runs with the highest possible - SYSTEM - privileges. After spawning csrss.exe, regular win32 applications (such as explorer.exe, or even winlogon.exe) can be successfully launched. This Windows Subsystem process is only started once, and remains running until the system is shut-down. If, however, csrss.exe is unexpectedly terminated during normal system execution (e.g. due to an unhandled exception crash or manual user termination), the NT kernel detects this issue and manually crash the system by issuing a call to KeBugCheckEx routine with the CRITICAL_OBJECT_TERMINATION error code. Furthermore, there is only one instance of CSRSS running on a Windows XP box - this process is responsible for handling the requests coming from all active processes, no matter what user they're running under.

When it comes to Windows Vista and later, a quite different approach was adopted. One CSRSS instance is started by the Session Manager, for handling the requests coming from session-0 modules. This process also stays alive until the very end of system execution. Furthermore, whenever an interactive user logs on, another separate csrss.exe is started by a dedicated smss.exe - the new Windows Subsystem instance is again designed to deal with signals sent by applications running under the new user's session. When, in turn, the user decides to log out, CSRSS is politely terminated (though no BSoD is triggered by the kernel this time). All of the active CSRSS instances run with the same, highest user rights, as all of them are launched by the smss.exe process, highly tight up with the NT kernel itself.

Conclucions

In this short post, I have tried to give you a basic insight into the precise way of where csrss.exe is from and how it works internally. As it turns out, it is possible to make use of the Windows Subsystem in the context of various, interesting hacks - but this remains yet to be described. More detailed information can be found in the Windows Internals 5 book (section Environment Subsystems and Subsystem DLLs), and numerous articles and advisories, listed in the following section. Comments - as always - welcome!

References

1. Wikipedia, Portable Operating System Interface [for Unix]
2. Wikipedia, Client/Server Runtime Subsystem
3. Wikipedia, Windows NT Startup Process
4. Secunia, Microsoft Windows CSRSS MsgBox Memory Corruption Vulnerability
5. SecurityFocus, Microsoft Windows CSRSS HardError Messages Denial of Service Vulnerability
6. Ivanlef0u, Win7 and CreateRemoteThread
7. Cesar Cerrudo, Story of a dumb patch
8. Mark Russinovich, Inside the Windows Vista kernel: Part 1, Part 2, Part 3

Introduction

Nowadays, all of the classic Virtual Machine products (Microsoft Virtual PC, VMWare Workstation, Oracle VirtualBox) are widely-spread and commonly used for a variety of purposes. That's because of the fact that they provide a reliable and convenient environment for multiple, virtual operating systems, which can be employed by Software Developers, Web Developers, Reverse-Engineers or even people not related to the IT industry, at all. As for one of the most significant advantages of using VMs, is that they are supposed to run in complete separation from the host system. Numerous security professionals take advantage of this assumption by setting up malware-dedicated guest systems, where the samples can be observed and safely debugged at run-time.

As it turns out, however, it might be possible to escape from a live guest OS right into the Host, under certain circumstances. WinDbg - the most commonly used debugger (working in both local and remote mode) developed by Microsoft, is confirmed to be vulnerable to multiple flaws, and/or makes use of vulnerable libraries. These security flaws could potentially lead to information disclosure (in case WinDbg leaks memory chunks to the guest), or even code execution in the context of the remote debugger process (running on the host OS). What should be noted, is that the attack vector is debugger-specific and can only be triggered in very specific conditions (hence being useless without a debugger being attached, in the first place).

Background

These days, the debugging software seems to be the integral part of any development environment - whenever new software of any kind is being developed, various kinds of errors tend to appear on both logical and implementation levels of the new code. These issues must often have to be dealt with using run-time analysis, which includes stepping through the code, examining and altering parts of the processor context (register, flags) and program state (in-memory variables etc). There's not much of a problem when it comes to user-mode, as Windows kernel provides debugger support (both in kernel- and user-mode parts of the system), and a decent number of ring-3 debuggers is freely available. Things are more interesting in the context of kernel-mode, which also has to be analyzed in many different situations (malware analysts, driver developers, bug-hunters and others). In order to begin the Kernel Debugging process, two (logical) live machines are required - the target (guest) and host computers, most likely connected via the serial port (though USB and IEEE1394 are also supported on the latest Windows versions). When the physical connection is correctly set-up, the Kernel Debugger (also referred to as "KD" later in this post) built-in part of the target system core begins exchanging data with WinDbg (or potentially any software supporting the undocumented communication protocol).

When the guest system is running, the remote debugger resides in the idle state, waiting for one of the following events to happen:

• A certain event occurs inside the guest, which requires the debugger to be informed about it,
• A special (native) request is received from the guest (such as a DbgPrint request, resulting in printing a user-defined message on the debugger console),
• The user decides to intercept the OS execution in the middle of its work (e.g. to set a breakpoint),

The first situation happens whenever an exception is raised, a breakpoint is reached or the system crashes with a Blue Screen of Death. The second and third will be described in more details later.

In case any of the above conditions is met, the control is passed to the remote debugger, consequently leading to the target OS getting temporarily frozen. When WinDbg's is in control, the user is able to perform actions such as managing (setting, removing, enabling) the breakpoints, modifying memory, examining and altering the processor context and so on. During all the time, when WinDbg is instructed to execute these operations, the guest execution is suspended - the only way for it to get back to work requires the debugger to issue a special Resume packet. What should be also noted is that most of the debugging features can only be taken advantage of when the debugger resides in the stand-by mode. An exception of this rule is the break-in action (otherwise known as CTRL-C), which can be used any time, in order to break into the debugger.

Due to the fact that a majority of kernel debugging is performed using Virtual Machines, and because most malware analysts use these techniques in their daily work, escaping from the virtual environment by any means (i.e. execute code on the host system) can pose a real threat these days. In this post, I would like to present some of the possible attack scenarios and vectors, which could be potentially used to perform in-the-wild attacks in the future.

First attack vector - the KDCOM protocol

The basics

The overall idea behind the reserach is "wherever data exchange takes place, a security flaw is likely to appear". In this case, the data in consideration is being passed between WinDbg.exe and the Virtual Machine process (whichever one we choose - it doesn't really matter at this point). Although, before lurking into some advanced communication internals, let's get a quick insight into the basics.

First of all, before trying to perform kernel debugging, one must make sure that the physical (in case of two real computers), or software - e.g. named pipes (in case of a VM) connection can be successfully established. Furthermore, the guest must be also booted up with adequate boot-settings - i.e. the /DEBUG flag set in the boot.ini configuration file for Windows XP and earlier, or using the bcedit.exe utility on Windows Vista and later.

The entire debugging session can be carried out thanks to the packet-based protocol, used by the host and guest to understand each other. As WinDbg is the only application capable of debugging a remote Windows OS, plus Microsoft doesn't intend the things to change, no official documentation has been published by the vendor, so far. On the other hand, some people have put effort in order to understand the proto and create a thorough reference, uncovering most of the technical details. Two, very appreciable articles can be found here: Kernel and remote debuggers and here: KD extension DLLs & KDCOM protocol, covering the precise way of how the target's kernel deals with the remote debugger. As can be seen, the protocol isn't very complex in general, though supports a great number of cross-system operation codes. Let's find out how the packet structure looks like.

The entire packet consists of two, main parts - the header, let's call it KD_PACKET_HEADER and the packet body, which is specific to the operation type defined in the header. Let's take a look at the header layout, in the form of a C structure:

typedef struct _KD_PACKET_HEADER
{
	DWORD Signature;
	WORD  PacketType;
	WORD  DataSize;
	DWORD PacketID;
	DWORD Checksum;
	BYTE  PacketBody[1];
} KD_PACKET_HEADER, *PKD_PACKET_HEADER;

Let's focus on each and every of the structure fields:

1. Signature
   Can be either 0x30303030 ('0000') or 0x69696969 ('iiii'). The first value represents Data Packets, while the latter one is used for marking Control Packets,
2. PacketType
   Defines the type of the request,
3. ByteCount
   Defines the length of the PacketBody array - containing necessary information - assigned to the request type,
4. PacketID
   Used to detect synchronization issues,
5. Checksum
   A straight-forward sum of all the bytes inside PacketBody (specifically zero, if ByteCount = 0),
6. PacketBody
   Type-specific data.

The PacketType field must be one of the following enum values:

enum KD_PACKET_TYPE
{
	PACKET_TYPE_UNUSED              =  0,
	PACKET_TYPE_KD_STATE_CHANGE32   =  1,
	PACKET_TYPE_KD_STATE_MANIPULATE =  2,
	PACKET_TYPE_KD_DEBUG_IO         =  3,
	PACKET_TYPE_KD_ACKNOWLEDGE      =  4,
	PACKET_TYPE_KD_RESEND           =  5,
	PACKET_TYPE_KD_RESET            =  6,
	PACKET_TYPE_KD_STATE_CHANGE64   =  7,
	PACKET_TYPE_KD_POLL_BREAKIN     =  8,
	PACKET_TYPE_KD_TRACE_IO         =  9,
	PACKET_TYPE_KD_CONTROL_REQUEST  =  10,
	PACKET_TYPE_KD_FILE_IO          =  11
};

A quick explanation for some of the above types follows:

• Acknowledgement packets - used to confirm that a specific packet has been successfully received - sent by both Windbg and the target,
• Resend packets - used, when Windbg or the target considers a specific packet invalid (e.g. the Checksum value is incorrect, given the packet data),
• Resync packets - used, when the synchronization between two machines fails.

For a more detailed (or better visualized) information on how a successful packet exchange is achieved, take a look at the aforementioned KD extension DLLs & KDCOM protocol text, section KDCOM protocol.

Furthermore, if we take a closer look at the structure definitions for each of the above types, we can easily observe a certain characteristic, which is true for most of the packets:

typedef struct _DBGKD_DEBUG_IO
{
	ULONG ApiNumber;
	USHORT ProcessorLevel;
	USHORT Processor;
	union {
		DBGKD_PRINT_STRING PrintString;
		DBGKD_GET_STRING GetString;
	} u;
} DBGKD_DEBUG_IO, *PDBGKD_DEBUG_IO;

typedef struct _DBGKD_CONTROL_REQUEST
{
	ULONG ApiNumber;
	union {
		DBGKD_REQUEST_BREAKPOINT RequestBreakpoint;
	DBGKD_RELEASE_BREAKPOINT ReleaseBreakpoint;
	} u;
} DBGKD_CONTROL_REQUEST, *PDBGKD_CONTROL_REQUEST;

Noticeably, a majority of the type-specific structures begin with an ApiNumber field, containing the sub-type of the packet. For example, if the target encounters a PACKET_TYPE_KD_STATE_CHANGE type, then the correct value of the ApiNumber field must be one of the following:

enum KD_STATE_CHANGE_API_NUMBER
{
	DbgKdExceptionStateChange     = 0x00003030L,
	DbgKdLoadSymbolsStateChange   = 0x00003031L,
	DbgKdCommandStringStateChange = 0x00003032L
};

PACKET_TYPE_KD_DEBUG_IO packet type, together with the supported APIs can be another good example:

enum KD_DEBUG_IO_API_NUMBER
{
	DbgKdPrintStringApi = 0x00003230L,
	DbgKdGetStringApi   = 0x00003231L
};

Please note that all of the constants and structure definitions can be found in the windbgkd.h file included in Windows 2000 DDK, or the ReactOS project files.

In general, the entire cross-system communication is carried out using the packet format presented above. Later in this post, I will show you how the data exchange looks in practise.

Previous research & related stuff

As mentioned before, several people have decided to analyze and describe the strictly technical details related to Kernel Debugger communication. Apart from great articles, a few KD-related projects have also been started, some of which are successfully developed until today. If you're interested in this subject, you should check out the following links:

• SYSPROGS VirtualKD - a project officially named Windows Kernel Debugger booster for Virtual Machines, which is supposed to speed up the Windows kernel debugging process, for both VMWare and VirtualBox software. The effect can be achieved by replacing the standard virtual COM port (allowing 115200 bps transfer) with a custom mechanism, reaching up to 450KB/s (VirtualBox) or 150KB/s (VMWare) transfer rate. Thanks to the author, both the binaries and source code are available, making it possible to build the executable images on one's own, or even learn how the program works under-the-hood. Download: http://sourceforge.net/projects/virtualkd/

• SecureWorks Wind Pill - a perl tool, which aims at automating the tasks involved in debugging the Windows kernel. Using this script, it becomes possible to carry out a kernel debugging session on custom host platforms. Besides, the utility makes it much easier to perform certain tasks (able to be automated) on the target system, which would be harder to achieve using the standard Windbg scripting abilities. Black Hat USA 2007 presentation: https://www.blackhat.com/presentations/bh-usa-07/Stewart/Presentation/bh-usa-07-stewart.pdf, Source Code: http://www.secureworks.com/research/tools/windpl.zip

Pipe Proxy - traffic monitor

In order to observe, how the communication between the two systems is really achieved, I have written a straight-forward tool called Windbg-PipeProxy, which works just as the name suggests - becomes a named-pipe proxy between the guest and host, and redirects every single packet sent by either of the systems. Apart from forwarding the traffic, a more or less reader-friendly log messages are emitted, giving some insight on what type of information is really passed to and from the kernel debugger. In the long haul, this can provide possible ideas of how the debugger can be actually attacked by the host system. Examples:

• Windbg tries to connect to the booting machine by sending the PACKET_TYPE_KD_RESET packet (type 6):

---==[ WinDBG ---> VirtualPC ]==---
[14:38:12] Leader:  0x69696969
 S --> C  Type:     0000000006
 S --> C  Bytes:             0
 S --> C  Checksum: 0x00000000

• Windbg sends a BREAKIN packet (single 0x62 byte):

---==[ WinDBG ---> VirtualPC ]==---
[14:38:12] Leader:  0x00000062
 S --> C  Type:     0000000000
 S --> C  Bytes:             0
 S --> C  Checksum: 0x00000000

• Windbg send a GetVersion request to the Virtual Machine...

---==[ WinDBG ---> VirtualPC ]==---
[14:38:15] Leader:  0x30303030
 S --> C  Type:     0000000002
 S --> C  Bytes:            56
 S --> C  Checksum: 0x00000610
00000000: 46 31 00 00 00 00 00 00 03 01 00 00 00 00 00 00 F1..............
00000010: b8 f8 c7 02 01 00 00 00 30 d1 52 69 00 00 00 00 ........0.Ri....
00000020: aa 00 00 00 01 00 00 00 00 00 00 00 53 61 00 00 ............Sa..
00000030: 00 00 00 00 00 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? ................

0x00003146 = DbgKdGetVersionApi

• ... and the guest system responses with a correctly filled structure:

---==[ VirtualPC ---> WinDBG ]==---
[14:38:15] Leader:  0x30303030
 C --> S  Type:     0000000002
 C --> S  Bytes:            56
 C --> S  Checksum: 0x0000149e
00000000: 46 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F1..............
00000010: 0f 00 bc 1b 06 00 03 00 4c 01 0c 03 2f 00 00 00 ........L.../...
00000020: 00 a0 83 82 ff ff ff ff 70 95 97 82 ff ff ff ff ........p.......
00000030: ec cf b9 82 ff ff ff ff ?? ?? ?? ?? ?? ?? ?? ?? ................

0x00003146 = DbgKdGetVersionApi
0xffffffff`8283a000 = NT Kernel ImageBase
0xffffffff`82979570 = PsLoadedModuleList
0xffffffff`82b9cfec = DebuggerDataList

• A user-mode application uses ntdll.DbgPrintEx to send out a simple text message to the debugger console.

---==[ VirtualPC ---> WinDBG ]==---
[15:29:16] Leader:   0x30303030
 C --> S  Type:     0000000003
 C --> S  Bytes:            29
 C --> S  Checksum: 0x000007f2
00000000: 30 32 00 00 10 00 00 00 0d 00 00 00 f9 fc b5 82 02..............
00000010: 48 65 6c 6c 6f 20 57 6f 72 6c 64 21 0a ?? ?? ?? Hello World!....

0x00003230 = DbgKdPrintStringApi
0x0000000d = Output string length
'Hello world!\n' = Output string contents

• A user-mode application uses ntdll.DbgPrompt to send a request for input data from the KD, providing prompt text...

---==[ WinDBG ---> VirtualPC ]==---
[15:20:21] Leader:   0x30303030
C --> S  Type:     0000000003
C --> S  Bytes:            31
C --> S  Checksum: 0x0000061c
00000000: 31 32 00 00 10 00 00 00 0f 00 00 00 20 00 00 00 12.......... ...
00000010: 48 65 6c 6c 6f 20 64 65 62 75 67 67 65 72 21 ?? Hello debugger!.

0x00003231 = DbgKdGetStringApi
0x0000000f = Prompt string length
0x00000020 = Output buffer size
'Hello debugger!' = Prompt string contents

• ... and Windbg responses with an input string:

---==[ WinDBG ---> VirtualPC ]==---

[15:20:26] Leader:   0x30303030
 C --> S  Type:     0000000003
 C --> S  Bytes:            30
 C --> S  Checksum: 0x00000544

00000000: 31 32 00 00 10 00 00 00 0f 00 00 00 0e 00 00 00 12..............
00000010: 48 65 6c 6c 6f 20 63 6c 69 65 6e 74 21 00 ?? ?? Hello client!...

0x00003231 = DbgKdGetStringApi
0x00000010 = unchanged
0x0000000f = unchanged
0x0000000e = the actual size of the output string (must be less or equal to the buffer size defined in the previous packet)
'Hello client!' = The text message typed by the KD user

• The debugger requests 0x18 bytes to be read from the specified virtual memory address...

 ---==[ WinDBG ---> VirtualPC ]==---
[15:14:15] Leader:   0x30303030
  C --> S  Type:     0000000002
  C --> S  Bytes:            56
  C --> S  Checksum: 0x0000078b
00000000: 30 31 00 00 00 00 00 00 02 00 00 00 00 00 00 00 01..............
00000010: e8 3b 95 82 ff ff ff ff 18 00 00 00 00 00 00 00 .;..............
00000020: 42 01 00 00 00 00 00 00 00 00 00 00 01 0f 00 00 B...............
00000030: 00 00 0f 77 01 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? ...w............

0x00003130 = DbgKdReadVirtualMemoryApi
0xffffffff`82953be8 = Memory address to read
0x00000018 = Byte count

• ... And the kernel supplies the data in consideration.

---==[ VirtualPC ---> WinDBG ]==---
[15:14:15] Leader:   0x30303030
  C --> S  Type:     0000000002
  C --> S  Bytes:            80
  C --> S  Checksum: 0x00000e08
00000000: 30 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01..............
00000010: e8 3b 95 82 ff ff ff ff 18 00 00 00 18 00 00 00 .;..............
00000020: 42 01 00 00 00 00 00 00 00 00 00 00 01 0f 00 00 B...............
00000030: 00 00 0f 77 01 00 00 00 ec 5f b9 82 ec 5f b9 82 ...w....._..._..
00000040: 00 00 00 00 00 00 00 00 4b 44 42 47 40 03 00 00 ........KDBG@...

0x00003130 = DbgKdReadVirtualMemoryApi
0xffffffff`82953be8 = Memory address to read (unchanged)
0x00000018 = Byte count (unchanged)
0x00000018 = Number of bytes read
###Data### = Requested memory contents, appended to the primary packet

• Apart from the normal, functional packets, the ACK packets are continuously sent after the KD / kernel successfully receives a message from the other side:

 ---==[ WinDBG ---> VirtualPC ]==---
[15:14:15] Leader:   0x69696969
  S --> C  Type:     0000000004
  S --> C  Bytes:             0
  S --> C  Checksum: 0x00000000

---==[ VirtualPC ---> WinDBG ]==---
[15:14:15] Leader:   0x69696969
  C --> S  Type:     0000000004
  C --> S  Bytes:             0
  C --> S  Checksum: 0x00000000

One should also note that the maximum size of the overall packet is a constant value 0f 4000 (0xFA0), and cannot be extended by any means:

#define PACKET_MAX_SIZE 4000

This, in turn, indicates that when the KD requests for more than one typical memory page (4096 bytes), the replies are sent in a chunked form, where each packet contains a separate memory area and fits in the packet size limitation. Furthermore, it is not possible to correctly send an debug message longer than ~4000 bytes, as well as send an input string to the kernel, either.

The above listings should give you some insight at how the communication is performed - please keep in mind that the number of supported APIs is more than 50, while almost every single one has its own, unique structure - definitely worth taking a closer look at. If you would like to receive more packet samples, complete dumps of a debugging session or even the source code, feel free to contact me.

Pipe Proxy - fuzzing the packets

Already being able to monitor and observe the flowing packets, the next step on the way to find some real vulnerability required modifying the packets. More precisely, the first idea was to pick random bytes and alter them before passing to to the adequate pipe - a technique otherwise known as fuzzing. Due to the fact that the first PipeProxy version was unable to recognize the packet structure, only a fully raw-data fuzzing was possible. As it later turned out, the only thing I could achieve by doing this, was hanging the entire debugging session after a couple seconds.

The reason of such behavior was pretty simple - both sides of the communication were validating the packet body against the Checksum field - if the verification failed, the message was requested to be re-sent. Apparently, more intelligent fuzzer was required to deal with this issue. And so, packet buffering was implemented, which guaranteed that each packet is entirely received before sending it to the other party. By doing so, random bytes could be chosen out of the packet body and changed - next then, the Checksum was re-calculated and sent to the dest~ pipe. After this fix, the fuzzer seemed to work well, as the debugger really started to behave unexpectedly.

Results

Unfortunately, the bad news is that during a couple fuzzing sessions, Windbg seemed to work steadily when parsing malformed protocol structures. The interesting thing is that strange things began happening when the packet's body (e.g. the memory contents read from the machine) was fuzzed together with the protocol structures. More precisely, exceptions started to be raised inside external DLL modules utilized by Windbg.exe. This phenomenom gave me the idea that the KD could possibly have problems handling the Virtual Machine's internal state, as well. More information regarding some real security flaws can be found in the "second attack vector" section

Please note, that the fact that no serious issues were found (yes, there were some minor cases) in relation to the packet format, doesn't necessarily mean that Windbg is vulnerability-free in this context. Don't hesitate to make your own experiments in this area

Source Code

On a second thought, I decided not to make the Windbg-PipeProxy available for the public audience for now. Chances are that you can get it after contacting me on a private channel, but no guarantee regarding this. I've got plans to release the tool soon though, so you can patiently wait or create one on your own

Second attack vector - executable image symbols' support

The basics

As a very advanced debugger, Windbg can obviously make use of symbols of any kind (export names, additional .pdb symbol files - both locally and remotely) if the user desires to do so. The symbol packages for each Windows version can be downloaded here, together with other debugging tools. If the Kernel Debugger can assign virtual addresses to the names exported from both user- and kernel-mode modules, it must somehow calculate the addresses, based on the current VM state (i.e. memory layout). The question is - does Windbg parses the PE and possibly PE32+ format manually? The answer is - yes and no.

As it turns out, Microsoft has developed a couple of libraries, aiming to help the developers in writing both user- and kernel- mode debugger applications. These libraries make it possible to focus on the real debugger functionality and usability, rather than implementing all the core operations from stratch; as they are really convenient, most of the modern debugging software makes use of these libs. These DLLs are:

• The Debugger Engine (DbgEng.dll)
  As MSDN states:

  • The debugger engine (DbgEng.dll), typically referred to as the engine, provides an interface for examining and manipulating debugging targets in user mode and kernel mode on Microsoft Windows.
    
    The debugger engine can acquire targets, set breakpoints, monitor events, query symbols, read and write to memory, and control threads and processes in a target.
    
    You can use the debugger engine to write both debugger extension libraries and stand-alone applications. Such applications are referred to as debugger engine applications. A debugger engine application that uses the full functionality of the debugger engine is called a debugger. For example, WinDbg, CDB, NTSD, and KD are debuggers; the debugger engine provides the core of their functionality.

• The Debug Help Library (DbgHelp.dll) - a small helper library, providing support to all symbol-related activities, as well as minidump files' management. This module is actually responsible for parsing all the internal PE/PE32+ structures of a specific image, on the debugger's demand.

Noticeably, Windbg takes advantage of both of these libraries. All in all, even if the debugger itself doesn't have problems dealing with malformed packet structure, both external DLLs are also directly operating on the information provided by the target kernel. Compromising the security of one of these modules would be as good as owning Windbg.exe itself - either way, the code's executing with the same privileges.

I have personally focused on the latter one, which has already been proven to contain critical security flaws. Let's take a look if there's anything left for us

Previous research & related stuff

One or two buffer overflow vulnerabilities were found and exploited during recent years. Some references:

1. OllyDBG v1.10 and ImpREC v1.7f export name buffer overflow vulnerability - tuts4you forums discussion
2. Old dbghelp and an old exploit... - a brief analysis of a stack-based BO by ReWolf

Even thought that's not much, these sources can reveal the actual code quality provided by DbgHelp.dll. For more details on how it really looks like, take a look at the next section

PE Image Fuzzing (environment + process)

In my opinion, running a fuzzer for a couple of nights is one of the most efficient ways of finding some anchor points, which can be further analyzed in order to work out a code-exec exploit; this case is no different. Before I start listing bugs found in the aforementioned DLL, one thing must be noted: Because of the fact that the target kernel has complete control over the data being sent to the debugger, one can simply fuzz the DbgHelp.dll library without Windbg taking part in this process - every malformed .exe loaded in the context of a local fuzzer can also be loaded by Windbg.exe, when the guest decides to.

Okie, let's take a look at a brief explanation of a some of the DbgHelp bugs:

1. Type: Out-of-bounds memory reference (READ)
   Instruction: rep movsd, [ESI]=???
   Call Stack:
    msvcrt!memcpy
    dbghelp!ReadImageData
    dbghelp!ReadHeader
    dbghelp!imgReadFromDisk
    dbghelp!modload
    dbghelp!LoadModule
    dbghelp!SymLoadModuleEx (exported)
   

   Description: this exception can be raised thanks to lack of sanity checks in numerous places, e.g. when (IMAGE_FILE_HEADER.NumberOfSections * sizeof(IMAGE_SECTION_HEADER)) is greater than the executable image size

2. Type: Invalid Memory Reference (READ)
   Instruction: movzx eax, word ptr [edx+ecx*2], EDX=controlled
   Call Stack:
    dbghelp!LoadExportSymbols
    dbghelp!idd2me
    dbghelp!modload
    dbghelp!LoadModule
    dbghelp!SymLoadModuleEx (exported)
   

   Description: the instruction is a part of a loop, which parses respective Export Table entries. The above instruction loads the ordinal of the current routine into AX - any address can be specified as the source operand, here.

3. Type: Out-of-bounds memory reference (READ)
   Instruction: mov edx, [ecx+eax*4],  LO(EAX)=controlled
   Call Stack:
    dbghelp!LoadExportSymbols
    dbghelp!idd2me
    dbghelp!modload
    dbghelp!LoadModule
    dbghelp!SymLoadModuleEx (exported)
   

   Description: the code tries to retrieve the address/name of the currently-processed function, using the export ordinal as an array index. Because of the fact that the buffer allocation size is determined by max(NumberOfFunctions,NumberOfNames), and the ordinals are not compared against the buffer size, one can reference heap data after the buffer.

4. Type: Invalid Memory Reference (READ)
   Instruction: movzx eax, byte ptr [edx+10h], EDX=controlled
   Call Stack:
    dbghelp!LoadCoffSymbols
    dbghelp!idd2me
    dbghelp!modload
    dbghelp!LoadModule
    dbghelp!SymLoadModuleEx
   

   Description: just another controlled memory reference while parsing the coff symbols.

5. A bunch of similar invalid memory references controlled by the VM. Although these bugs doesn't directly lead to any thread, a few information-disclosure attacks are confirmed to be possible (i.e. revealing Windbg.exe process memory to the guest).

6. Type: Out-of-bounds memory reference (WRITE)
   Instruction: mov word ptr [eax+edx*2], cx       LO(EDX)=controlled
                                                   CX=0x0001
   Call Stack:
    dbghelp!LoadExportSymbols
    dbghelp!idd2me
    dbghelp!modload
    dbghelp!LoadModule
    dbghelp!SymLoadModuleEx
   

   Description: The LoadExportSymbols functions allocates a special array on the heaps, let's call it IsOrdinalPresent. Its size (in items) is set to max(NumberOfFunctions,NumberOfNames), while the size of a single item is 16-bits. During the export directory parsing, the routine marks the ordinals as present by putting a TRUE value into the corresponding array index. Noticeably, the actual value of the ordinal is not validated and can exceed the size of the buffer. This flaw makes it possible for us to overwrite the memory following our buffer with (WORD)1. Considering today's Windows heap protections, it might be particurarly hard to transform this bug into a reliable code-execution; but who knows, it still might be possible (i.e. by targetting the heap allocation contents instead of headers).

7. Type: 32-bit Integer Overflow
   Instructions:
    mov edx, [ebp-864], EDX=controlled
    shl edx, 1
    push edx
    call _pMemAlloc
   
   Call Stack:
    dbghelp!LoadExportSymbols
    dbghelp!idd2me
    dbghelp!modload
    dbghelp!LoadModule
    dbghelp!SymLoadModuleEx
   

   Description: Because of the fact that the ordinals aren't validated either way when being used as a WRITE array index, the bug doesn't change anything. If, however, an appropriate check would be added in order to accept ords <= allocation size, than the integer overflow would still make it possible to perform out-of-bounds writing e.g. by setting the NumberOfFunctions field to 0x80000001 - then:

   (uint32_t)(NumberOfFunctions * 2) = 2

As can be seen, DbgHelp.dll contains numerous places where virtually any value could be used as the read instruction operand. Unfortunately for us, the library makes use of multiple exception handlers, which do their best not to have the process crashed; most of the Access Violation exceptions are correctly dealt with. However, it is still possible to cause serious damage on the Windbg.exe heap (using out-of-bounds write), which would eventually lead to Denial of Service conditions. Code execution has not been confirmed due to very hard exploitation conditions of the known flaws - I strongly believe that it is possible, though.

Conclusions

As shown in this post entry, using a remote debugger might not be as safe as one might expect. Wherever information is exchanged, a vulnerability is likely to appear - this phrase perfectly fits to the issues described here.

Please keep in mind that the results presented here are not the results of a really thorough research - Alex appeared to be faster than me This means that I could have missed some obvious vectors which should be double-checked - in this case, please just let me know. Additionally, you are free to carry out your own analysis of the Kernel Debugger security - however, if you're going to make use of some ideas / conclusions included in this post, I'd be really glad to be let known Thanks!

References

1. Debugging Tools for Windows
2. Kernel and remote debuggers
3. SysProgs VirtualKD project
4. Just Another Windows Kernel Perl Hacker @ BH 2007
5. ReactOS windbgkd.h file
6. Windows Named Pipes

I have recently had some fun playing around with driver signing on Windows x64, and so I like to share some matters that have came into my head Therefore, let me briefly describe some internal mechanisms lying behind well known Driver Signature Enforcement, a significant part of the Code Integrity feature introduced by Microsoft in Windows Vista and Windows 7. Understanding the underlying system behavior would let us think of possible attack vectors against the protection, as well as better apprehend the existing techniques, such as the ones developed by Joanna Rutkowska or Alex Ionescu. Let the fun begin!

Note: All the information included therein are based upon Windows 7 executables and are not guaranteed to be valid for previous Windows NT systems.

Introduction

According to Microsoft:

Code Integrity is a feature that improves the security of the operating  system by validating the integrity of a driver or system file each  time it is loaded into memory. Code Integrity detects whether an  unsigned driver or system file is being loaded into the kernel, or  whether a system file has been modified by malicious software that is  being run by a user account with administrative permissions. On  x64-based versions of the operating system, kernel-mode drivers must be  digitally signed.

What the above quotation really informs about, is that the only device drivers that can be actually executed within ring-0 must be digitally signed - otherwise, the nt core simply refuses to load such an image. This rule applies to every single module, which desires to run with the kernel privileges. In fact, launching a device driver is the only legitimate way, in which a system user can execute ring-0 code - and this very only way is disabled for unsigned executable images. The most interesting thing, however, is that not only restricted users are forbidden to load unsigned code (which they couldn't do before anyway, neither in x64 nor x86 mode), but the entire Administrator's group, as well. This, in turn, means that the privileges assigned to a user account don't play an important role anymore, in this context - the ability to load unsigned code was taken away from every system user!

The official purpose of introducing such restrictions was to make the OS more secure (by preventing ring-0 malware from pwning the system from inside), get rid of possible anti-DRM solutions and overall, make our computers a better place to work. As a few years have passed and we're still alive, it seems like Code Integrity is doing well. Even though this feature is obligatory, and running on most of the systems nowadays, it is still possible to temporarily turn the mechanism off (which is the only reasonable idea for device driver developers, testing their work out):

• Pressing F8 during Boot Time, and choosing the Disable Driver Signature Enforcement boot option or,
• Specifying the /DEBUG boot flag using bcdedit.exe plus attaching a Remote Kernel Debugger during, of after the system boot-up.

Both alternatives obviously require very high user privileges, as well as rely on rebooting the machine in order to take effect. As turning the machine off and on again might be somewhat inconvenient (while attaching a remote, physical debugger is even worse), as well as is relatively hard to perform programatically (unless someone decides to create a bootkit, which would choose the right boot option without the user's knowledge). Due to this situation, a brand new type of Elevation of Privileges attack arises: "Admin to Kernel transition". Some experts tend to consider security flaws belonging to this class as "bugs only", while others see them as a full-fledged vulnerabilities.

A few attacks against Code Integrity have been performed in the past, involving design and implementation flaws found in certain parts of the Windows kernel. These include:

1. Employing paged-out kernel code (i.e. executable parts of drivers, found in Pageable sections), which has been previously overwritten inside pagefile.sys (by utilizing raw disk access).
2. Exploiting security flaws existing in common, already-signed device drivers, such as graphic card drivers (e.g. ATI, nVidia vendors).
   

As we already know what we're dealing with, let's take a look at how the mechanism works internally.

Initialization

The actual heart of Code Integrity lies inside a single executable image, called CI.dll (you can find it inside your \Windows\system32 directory). If we take a look at the list of imported symbols, we will most likely see the following names:

• CiCheckSignedFile
• CiFindPageHashesInCatalog
• CiFindPageHashesInSignedFile
• CiFreePolicyInfo
• CiGetPEInformation
• CiInitialize
• CiVerifyHashInCatalog

What shouldn't be a surprise, the first function within our interest is the initialization routine, CI!CiInitialize. This routine is imported by the NT core (ntoskrnl.exe), and called during system initialization:

VOID SepInitializeCodeIntegrity()
{
  DWORD CiOptions;

  g_CiEnabled = FALSE;
  if(!InitIsWinPEMode)
    g_CiEnabled = TRUE;

  memset(g_CiCallbacks,0,3*sizeof(SIZE_T));
  CiOptions = 4|2;

  if(KeLoaderBlock)
  {
    if(*(DWORD*)(KeLoaderBlock+84))
    {
      if(SepIsOptionPresent((KeLoaderBlock+84),L"DISABLE_INTEGRITY_CHECKS"))
        CiOptions = 0;
      if(SepIsOptionPresent((KeLoaderBlock+84),L"TESTSIGNING"))
        CiOptions |= 8;
    }
    CiInitialize(CiOptions,(KeLoaderBlock+32),&g_CiCallbacks);
  }
}

The above C-like pseudocode presents the general idea of the SepInitializeCodeIntegrity routine. As can be seen, some global nt!g_CiEnabled variable is being set to FALSE / TRUE, depending on whether the machine is booting up in the WinPE mode. Furthermore, CiOptions is initialized accordingly to the system boot options, and finally passed to the CiInitialize routine, together with a pointer to KeLoaderBlock and a global g_CiCallbacks array. A complete call-stack, from the very beginning of the Phase1 thread initialization follows:

nt!SepInitializeCodeIntegrity
nt!SepInitializationPhase1+0x1a1
nt!SeInitSystem+0x29
nt!Phase1InitializationDiscard+0x7ce
nt!Phase1Initialization+0xd
nt!PspSystemThreadStartup+0x9e
nt!KiThreadStartup+0x19

If we decide to go one level deeper, inside the CI!CiInitialize function, several actions taken by the initialization routine can be observed:

• First of all, a self-integrity test is being performed, by calling the CI!CiFipsCheck function. This function is a wrapper of CI!MincrypK_SelfTest, which eventually verifies the digital signature assigned to the module. If any anomaly is encountered, the 0xc0000428 (STATUS_INVALID_IMAGE_HASH) error code is returned,
• If the self-test passes, the nt!g_CiCallbacks, passed by ntoskrnl.exe is filled in the following way:

  g_CiCallbacks[0] = CI!CiValidateImageHeader;
  g_CiCallbacks[1] = CI!CiValidateImageData;
  g_CiCallbacks[2] = CI!CiQueryInformation;

• In the very end, the CI!PESetPhase1Initialization function is called, which aims to validate the signature of every single driver present on the Boot Driver List. In case of any errors, an adequate error code is returned and the booting process is halted.

From this point now on, the Code Integrity mechanism can be considered pretty much initialized. The most important thing about CiInitialize is that it passes three function pointers back to the nt core, which can be later used to validate respective, custom drivers as they try to be loaded.

Driver Signature Verification

Having the essential pointers already initialized, let's take a look at which point the driver loading is disrupted by Code Integrity. We can safely assume that the nt!MmLoadSystemImage routine is reached before the loading process bails out - this is pretty much the first function to call if one wants to load a device driver. The function is used by nt!NtSetSystemInformation (when SystemInformationClass is equal either 28 or 38), so that it can be easily taken advantage of by a user-mode applications. When trying to load an unsigned driver, we end up with the following call-stack, until an error is encountered:

1. nt!MmLoadSystemImage

   The routine loads a specific executable image into kernel memory.

2. nt!MiObtainSectionForDriver

3. nt!MiCreateSectionForDriver

4. nt!MmCheckSystemImage

   The routine ensures that the system module to be loaded has a correct checksum, which matches the data in the image.

5. nt!NtCreateSection

6. nt!MmCreateSection

7. nt!MiValidateImageHeader

8. nt!SeValidateImageHeader

   The routine ensures that the system module has a valid digital signature appended.

9. nt!_g_CiCallbacks[0]

   e.g. CI!CiValidateImageData

As the above shows, after going through a long chain of internal calls, the execution reaches the nt!SeValidateImageHeader routine, which performs the following:

1. Checks, whether nt!g_CiEnabled is set to TRUE
   1. If so, compares the nt!g_CiCallbacks[0] pointer to NULL
      1. If not empty, calls the nt!g_CiCallbacks[0] function and quits,
      2. Otherwise, returns 0xc0000428.
   2. Otherwise:
      1. Allocates one byte on the Paged Pools,
      2. Puts the resulting address into memory pointed to by the first argument,
      3. Returns STATUS_SUCCESS (or whatever zero means here).

Surprisingly, that's the end of the signature validation (the actual code responsible for performing the verification lies inside CI.dll).

Conclusions:

The decision on whether a driver can or cannot be launched is up to one function, checking one, single variable. If one wanted to turn the mechanism off, it would be up to altering one single byte (or even better, bit!) within the ntoskrnl image. This could prove useful for a malicious, already-signed driver aiming at getting rid of Code Integrity mechanism, overall. Furthermore, potential attackers could also utilize a previously-found write-what-where vulnerability in one of the common device drivers, in order to overwrite the flag and open a gate straight into ring-0 execution - the latter option could be utile in terms of admin->kernel escalation, where disabling CI is the final goal of the exploit.

Neither nt!g_CiEnabled nor nt!g_CiCallbacks are exported symbols. Thus, it might be relatively hard to overwrite either of these values reliably, in a cross-version exploit (as long as hardcoded offsets are not provided for every single Windows version).

The two remaining item - nt!g_CiCallbacks[0] and nt!g_CiCallbacks[1] - filled inside CI!CiInitialize are used by the nt!SeValidateImageData and nt!SeCodeIntegrityQueryInformation functions, respectively.

Driver Verification Debugging Options

Even tough it is impossible to disable Code Integrity by any other way than the two described at the beginning (F8 option or attached debugger), one is able to do the opposite - enforce the mechanism to work, even if a remote debugger is attached to the machine - certainly a fair option for some of the device driver developers.

As MSDN states:

In some cases, developers may want to enforce mandatory kernel mode code signing policy even when a debugger is attached. An example of this is when a driver stack has an unsigned driver (such as a filter driver) that fails to load, which may invalidate the entire stack. Since attaching a debugger allows the unsigned driver to load, the problem appears to vanish as soon as the debugger is attached. Debugging this type of issue may be difficult. In order to facilitate debugging in this case, Code Integrity supports a registry key that can be set to enforce kernel mode signing enforcement even when a debugger is attached.

There are two flags defined in the registry that control Code Integrity behavior under the debugger. The flags are not defined by default.

Create registry value as follows:

Key:   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CI
Value:   DebugFlags      REG_DWORD

Possible values:

00000001

Results in a debug break into the debugger and unsigned driver is allowed to load with g.

00000010

CI will ignore the presence of the debugger and unsigned drivers are blocked from loading.

Any other value results in unsigned drivers loading—this is the default policy.

Conclusion

In this short post, I wanted to introduce bits of information that brought my attention during the last one or two days. Obviously, there is still a lot of interesting material to cover, related to Code Integrity subject, which I might further describe in the near future. As for now - feel encouraged to read the articles listed below... and that's it.

Have fun && Leave comments!

References & Links

1. Joanna Rutkowska, Subverting Vista Kernel for Fun and Profit
2. Joanna Rutkowska, Vista RC2 vs. pagefile attack (and some thoughts about Patch Guard)
3. ZDNET, UPDATE: ATI driver flaw exposes Vista kernel to attackers
4. MSDN, Digital Signatures for Kernel Modules on Systems Running Windows Vista
5. Microsoft, Code Integrity (ci.dll) Security Policy
6. Matthew Conover, Assessment of Windows Vista Kernel-Mode Security

CONFidence 2010 took place in Poland, on 25th and 26th of May, in the Kijów Cinema. The lectures were presented on two, independent tracks (thus everyone was able to find something for himself in any given moment), and regarded numerous, important security fields. In my opinion (and because of my specific interests), the best speeches were given by Sebastian Fernandez - "General notes about exploiting Windows x64", Mario Heidreich - "The Presence and Future of Web Attacks Multi-Layer Attacks and XSSQLI" and Alexey Tikhonow - "De-blackboxing of digital camera". I am really looking forward to see the slides being published as soon as possible. Meanwhile, you can find the complete conference schedule at http://2010.confidence.org.pl/agenda.

The ESET company (NOD32 software producent) has recently decided to organise two competitions with fun prizes - some detailed information can be found here. In short: the purpose of the first one was to create or project a security-related application of any kind. The second one was directed towards the conference attendees, as the goal was to find a correct serial key associated to a chosen user name, in a specially prepared executable file. A team consisting of Gynvael Coldwind and me managed to meet the latter objective, and therefore win the competition Due to the above, a short blog entry/article should be released soon, covering the exact way of generating a correct serial, having as little knowledge about the input data verification mechanisms, as only possible (stay tuned ). The CrackMe can be still downloaded from the CONFidence website: http://2010.confidence.org.pl/ESET/banner.html, and I encourage every one and each of you to take a look at this one.

Moreover, I had the pleasure (once more, with Gynvael's collaboration) to carry out one of the last presentations, dedicated to the Windows kernel vulnerabilities (related to CSRSS and the system registry), which I have often mentioned lately. I think this is a perfect opportunity to publish some advisory documents, containg more relevant, detailed information about the vulns, of a more technical nature. Below you can find a complete list of these:

• Windows CSRSS Local Privilege Elevation Vulnerability (CVE-2010-0023)
• Windows Kernel Null Pointer Vulnerability (CVE-2010-0234)
• Windows Kernel Symbolic Link Value Vulnerability (CVE-2010-0235)
• Windows Kernel Memory Allocation Vulnerability (CVE-2010-0236)
• Windows Kernel Symbolic link Creation Vulnerability (CVE-2010-0237)
• Windows Kernel Symbolic link Information Disclosure (CVE-2010-0237)
• Windows Kernel Registry Key Vulnerability (CVE-2010-0238)

Furthermore, a package including all the above advisories is available to be downloaded here (864 kB).

The slides presented during our lecture can be found here (1.6 MB).

I strongly encourage every conference attendee to share your opinion regarding the conference itself, as well as specifically the material talked over by us.

It seems like half a year has passed since I published the Win32k.SYS system call table list on the net. During this time (well, it didn't take so long ) I managed to gather enough information to release yet another API list - this time, concerning an user-mode application - CSRSS (Client/Server Runtime SubSystem). As a relatively common research subject, I think a table of this kind can make things easier for lots of people.

Before presenting the table itself, I would like to gently introduce the mechanism in consideration to the reader. As the name itself states, CSRSS is a part of the Windows Environment Subsystem, running in user-mode. It is a single process (having the highest possible - SYSTEM - privileges), which mostly takes advantage of three dynamic libraries - basesrv.dll, csrsrv.dll and winsrv.dll. These files provide support for certain parts of the subsystem functionality, such as:

• Updating the list of processes / threads running on the system
• Handling the Console Window (i.e. special text-mode window) events
• Implementing parts of the Virtual DOS Machine support
• Supplying miscellaneous functions, such as ExitWindowsEx

Every Windows process running on the system does (or, at least, should) have an open connection with CSRSS, through the LPC / ALPC mechanism (depending on the system version) - which in turn stands for (Advanced) Local Procedure Calls. The ntdll.dll module provides multiple functions dedicated to the data exchange between user processes and CSRSS. Some of the examplary, exported names include, but are not limited to:

• CsrClientConnectToServer
• CsrGetProcessId
• CsrClientCallServer
• CsrAllocateMessageBuffer

Out of all the Csr~ wrapper functions, CsrClientCallServer is the most commonly used. One can find it's references in kernel32.CreateProcess, kernel32.AllocConsole, kernel32.FreeConsole, user32.EndTask and tens of other documented API functions. At a closer look, it is easy to notice that each time a call is made to CsrClientCallServer, an unique number is pushed on the stack, differing from routine to routine. An exemplary code snippet follows:

.text:77E96D55           push    4
.text:77E96D57           push    20225h    <---------- HERE
.text:77E96D5C           mov     [ebp+var_7C], eax
.text:77E96D5F           push    0
.text:77E96D61           lea     eax, [ebp+var_A4]
.text:77E96D67           push    eax
.text:77E96D68           call    ds:__imp__CsrClientCallServer@16 ; CsrClientCallServer(x,x,x,x)

As it turns out, these numbers are in fact indexes into special function pointer tables defined by the aforementioned libraries used by CSRSS. More specifically, a special routine - internally called CsrApiRequestThread - running in the context of a separate csrss.exe thread, is responsible for receiving user requests (that is - the CsrApi ID value together with the input buffer), handling it through  appropriate dispatch tables, and returning the results. This scheme is slightly different on Windows 7, but the general idea remains the same.

In order to give the reader a better view of how many and what functions are supported on a specific OS version, as well as make cross-version comparisons easier, I've created two versions of the CsrAPI table:

1. A complete list of the functions present in the dispatch tables for most likely every NT-series system can be found @ http://j00ru.vexillium.org/csrss_list/api_list.html.
2. A cross-version compatibility table, for the same system version set can be found @ http://j00ru.vexillium.org/csrss_list/api_table.html.

I have done my best to make sure that the presented materials are correct and up-to-date. If, however, a mistake of any kinds is noticed, please let me know about this fact asap It is possible that I will manage to fill the red-green table with corresponding api-numbers soon - I cannot guarantee this, though.

From this point, I would like to thank all people who showed their interest and helped my with this tiny project - Thank You! Also, please drop me a line on whether you like the idea or not

Thanks to the organisers, who publish the materials right after the speeches are over, all of the slides are now available at http://conference.hitb.org/hitbsecconf2010dxb/materials/.

Our presentation, containing the details of how the aforementioned kernel / CSRSS vulns work and can be exploited, can be found here (1.27MB).

I am not going to spoil anything more here - if you were not lucky to attend the Dubai conference, I strongly recommend the polish CONFidence 2010 held in May (which I also mentioned already).

Have fun!