New features of Win 7: Console Host (ConHost.exe)

Today, I will introduce to you the new feature of Windows 7 / Windows Server 2008 R2 - console host (ConHost.exe).

In fact, whether as ordinary users or enterprise administrators, we will use console applications more or less in our daily Windows applications and operation and maintenance processes. The console application has no user interface. We need to perform input and output operations on it through the command prompt (CMD, this is not DOS, many people are confused).

So let’s think about it, what console applications does Windows come with?

In fact, the most typical ones include cmd.exe, nslookup.exe and telnet.exe.

In earlier versions of Windows, all applications that represented non-GUI activities (i.e., console applications) were coordinated through the system process Csrss.exe when they wanted to run on the desktop. When a console application needs to receive characters, it calls a small "console APIs" in Kernel32.dll to let Kernel32 generate LPC to call CSRSS. At this time, CSRSS will check and verify the input queue of the console window, and return the character mode results to the console application through Kernel32 for association. The message processing mechanism of console applications in early Windows versions is shown in the figure below:

This processing mechanism has created a problem: even if a console application is executed in the context of a normal user, Csrss.exe always runs under the permissions of the local system account. Therefore, in some cases, malware developed by "bad guys" may gain more privileges through Csrss.exe executed with local system account permissions. This attack mode is called Shatter Attack.

In the era of Win7 and Windows Server 2008 R2, all console applications are placed in a new context process ConHost.exe for execution, and ConHost (console host) and console programs run in the same security level context. Among them, instead of issuing an LPC message request to CSRSS for processing, it instead requests ConHost. Therefore, any application attempt to exploit a message request to cause automatic elevation of privilege will not succeed. The following figure is a schematic diagram of the new mechanism used in Windows 7 and Windows Server 2008 R2:

ConHost replaces a permanent change in the way I/O is handled by console applications. Users cannot force Windows to revert to "legacy mode" console behavior via the registry or Group Policy. Therefore, users need to thoroughly test applications before upgrading to Windows 7 or Windows Server 2008 R2. Please don't forget that although most functions of some applications are implemented through the GUI, data are still processed in batches through the console or other functional interfaces in the background. Therefore, it is very necessary to conduct comprehensive application functional testing before migration or leveling.

When an application cannot be used normally in Windows 7, we should first test and execute it again with administrator rights to see if the problem occurs. In fact, we can then use Process Monitor to monitor whether the application's access rights to files or the registry are normal. If the application still cannot run normally after troubleshooting the above problems, you need to consider contacting the ISV or its developer.

If an application crashes, the corresponding crash dump file is most helpful for developers and ISVs to find the crux of the problem. If the application stops responding, you can try using ADPlus to grab it and its associated ConHost.exe process dump. Console applications can share many subprocesses of the Windows console. For example, when the user starts Telnet from the CMD window, Telnet.exe will become a subprocess of Cmd.exe. In this case, the ConHost.exe host processes message instances of both the parent process and the child process. By using Process Explorer we can confirm which processes ConHost.exe is handling:

You can also use the "Analyze Waiting Chain" function in Windows 7 Resource Monitor to view the application process of the ConHost.exe process:

Finally, don’t forget to fully test the application before migration!