Conhost.exe, CSRSS and Session 0

Under Windows 2008 and Windows 7 a new process has appeared in task manager which did not exist before. This process is the Console Windows Host, %SystemRoot%\system32\conhost.exe.

The aim of this new process is to separate end user activity from system activity and limit exposure of the highly privileged CSRSS.EXE process. It is, to make it short, a brand new Microsoft security feature which you can definitively trust.

Some history first.

In previous versions of Windows (i.e. Windows 2003, Windows XP), during Windows startup, the first process to be run is SMSS.EXE, which is charge of session management and is the parent process for:

• winlogon.exe, which is the Windows logon manager
• CSRSS, which provides the user mode side of the Win32 subsystem.
  

CSRSS.EXE, as you may know, runs with the Local System account. This Local System account is the account in which all core Windows user-mode operating system components run, not only the Windows subsystem process (CSRSS.EXE), but also the Session Manager (%SystemRoot%\System32\SMSS.EXE), the Local Security Authority process (%SystemRoot%\System32\LSASS.EXE) and the Logon process (%SystemRoot%\System32\WINLOGON.EXE).

On top of the CSRSS process runs all the GUI activity on behalf of non-GUI applications such as NSLOOKUP and TELNET. These child non-GUI applications run with the privileges of the current user account.

So, to resume, in Windows 2003 and in Windows XP the process hierarchy looks something like this:

• SMSS.EXE
• Winlogon.exe
• CSRSS.exe (runs under Local System)
• Nslookup (runs with current user account privilege)
• Telnet (runs with current user account privilege)
  

In August 2002 a paper was published under the title "Exploiting design flaws in the Win32 API for privilege escalation". This paper detailed a flaw in the Windows messaging system which could allow the execution of code with an elevated privilege by passing pieces of code from the low privileged application to the CSRSS process (or any other process running with a Local System account). This exploit was based on the LPC communication between end user processes and system processes and on the fact that CSRSS listens on LPC ports for Win32 API calls and handles them wherever they came from.

Today Microsoft has solved this problem in new version of Windows by making a new process run between end-user-non-GUI programs and CSRSS: Conhost.exe.

ConHost.exe runs in the very same security context as its associated console application. Instead of issuing an LPC request to CSRSS for message-handling, the request goes to ConHost.exe. As a result, any attempts to exploit the message-handing code of the application will not result in an automatic escalation of privileges.

Furthermore, starting with Windows Vista and Windows 2008, Microsoft has adopted a new isolation mechanism which consists in moving user sessions away from Session 0, separating this way the message loop of a logged-in user's session from high-privilege system services, which are loaded into Session 0.

So, while in Windows 2003 and XP we have non-GUI programs only...

... in Windows 2008 (and Windows 7 – same kernel…) we have one Conhost process for each non-GUI application:

And, concerning session management, under Windows XP, users are normally logged on Session 0 (first to come, first available session taken mechanism)...

... while under Windows 2008 R2, user console sessions start from Session 1 and Session 0, which is non interactive, is reserved for services :

I hope you found this article useful.