Introduction
It is well agreed that security is an important issue and that it should be treated seriously. The need for Security measures grew, in the last years, especially due to the extensive use of the Internet and as a precaution measure to the malicious activities of crackers and hackers. After saying that, let's face it, security, is a nightmare for software developers, and merging security in our projects and working with secured framework demands enormous amount of time, mainly due to configuration issues.
The article deals with IIS (Internet Information Server), and specifically with Web Services. Among other stuff, the IIS is Microsoft's implementation for an HTTP Server; it is heavily used, in the industry, for Web sites and for Web Services. These characteristics position the IIS in the front line of malicious attacks, therefore the IIS is loaded with security layers. The purpose of this article is to help readers with information regarding IIS security configuration.
The IIS Security mechanism is an enormous topic, suitable for a small book, therefore I choose to focus on a certain case study of how to configure the IIS in order to enable the use of Named Kernel Objects in a Web Service. Following are the main two reasons for using this case study:
- Named Kernel Objects require Security configuration, otherwise they do not work.
- Named Kernel Objects is a cool feature which is not well documented in the Web or in the MSDN.
Disclaimer
As in my previous articles, I am only sharing information with the development community. The article is not a comprehensive paper about IIS security but only a short guide for annoying hurdles that I have faced with during my work.
Who should read this article?
If you are dealing with the IIS or plan to, if you need to port a Web site or web service to IIS version 6 and to Windows 2003, then this article will be of help to you. Also, the case study in the article deals with Named Kernel Objects, a subject that is not documented well enough (in my humble opinion). The reader would also find useful information about Kernel Objects in the Microsoft operating systems. I expect the reader to have a basic knowledge about Web Services, IIS, and C#.
The case study challenge
Due to security issues, IIS 5.x and 6.x do not work correctly with named kernel objects. For instance, in IIS 5.x, the call to the CreateEvent API returns with an invalid handle and the GetLastError method returns error 5 (access is denied). In IIS 6.x, the method returns with a valid handle (and the GetLastError with 0 - success); it seems to work okay, but be careful, it does not do what you think it does. The handle will not be shared. The full scale of the problem is revealed by the fact that you don't really know what went wrong. It is in the Kernel Objects data structure's nature that they are accessible only in kernel mode; therefore it is impossible to detect them in the memory.
The case study environment
The case study was tested on the following environment:
- Windows XP Professional SP2 and Windows 2003 Server SP 1
- IIS 5.1 and IIS 5
- .NET framework 1.1x SP
Kernel Object (KO)
Before drilling down into the case study characteristics, it is important to pave the way by describing what a Kernel Object is. If you are not familiar with this topic, I recommend jumping to Appendix A first.
The case study cause
The Named Kernel Object feature does not work in Web Services due to default security attributes. In Windows XP SP 2, the cause is the lack of user rights in the ProcessModel attribute, and in Windows 2003 Server, the cause is the lack of user rights due to the IIS_WPG group and the need to use the \Global prefix in the name of the Named Kernel Object.
The case study solution
IIS 5 Windows XP Professional and Named Kernel Object
In order to successfully use Named Kernel Objects in Win XP Pro SP 2 with IIS 5.x, you need to change the userName attribute of the ProcessModel XML node in the Machine.Config file (<Windows folder>\Microsoft.NET\Framework\< Framework version>\CONFIG):
<processModel enable="true" timeout="Infinite" idleTimeout="Infinite"
shutdownTimeout="0:00:05" requestLimit="Infinite"
requestQueueLimit="5000" restartQueueLimit="10"
memoryLimit="60" webGarden="false" cpuMask="0xffffffff"
userName="System" password="AutoGenerate"
logLevel="Errors" clientConnectedCheck="0:00:05"
comAuthenticationLevel="Connect"
comImpersonationLevel="Impersonate"
responseDeadlockInterval="00:03:00" maxWorkerThreads="20"
maxIoThreads="20"/>
Reset IIS: from the command line, type iisreset.
IIS 6 Windows 2003 Server and Named Kernel Objects
Unfortunately, the above does not work for IIS 6. This is due to the more sophisticated security mechanisms in Windows 2003 Server. For some reasons, the fox in Redmond (Microsoft) didn�t find it common or important to write about the ways to pass through this problem. The Named Kernel Object API documentation in the MSDN stresses the following:
�Terminal Services: The name can have a "Global\" or "Local\" prefix to explicitly create the object in the global or session name space. The remainder of the name can contain any character except the backslash character (\).�
Although, the \Global prefix is part of the solution, it has noting to do with Terminal Services. The problem occurs from the Console and when you directly login to a Windows 2003 Server machine. The Widows 2003 Server uses session namespace, and therefore always returns a handle in the session context (even for Named Kernel Objects). In order to successfully use Named Kernel Objects in the Windows 2003 Server, you need to add the Global\ prefix. This will tell the OS that the Named Kernel Object should be created in the Global session namespace. I would like to mention that in Window 2003 Server, the problem is even more annoying because the API returns a valid handle and the GetLastError returns success. The API call succeeds, it only does not do what we expect it to do.
We pass this hurdle. Hurry! Don�t relax just yet, we are not finished. The above solution will work for processes that use Named Kernel Objects with the Global\ prefix and run under the same user. If you use Named Kernel Objects in a Web Service it will not work. Why? In IIS 6, you define an Object Pool or use the default. The Object Pool runs under a certain Identity (IWAM or Network System, by default). If the Web Service and the Windows Forms process, for example, run under a different user, they will not share a session namespace even if you use the Global\ prefix. In order to pass through this hurdle, you should add the user which runs the Windows Forms application to the IIS_WPG group. If it is still not working, make sure the IIS_WPG group has Bypass Traverse Checking rights.
The screenshot below displays the Groups in a Windows 2003 Server. You need to associate the user with this group.
The screenshot below displays the association of the user above with an Application Pool (NamedKOTest):
The screenshot below displays the association of the Web Service with the Application Pool:
The Implementation
Using the source code
As you will see, the source code is not fancy. It only demonstrates the problem and the solution. You will find two projects: a painfully simple Web Service, and an �amazing� Windows Forms application with a few lines. For simplicity, put the Web Service under the IIS root (c:\inetput\wwwroot), and create a virtual directory for it. Run the Windows Forms application and start the Wait method. Browse for the WebService1.asmx and activate the SetEvent method. I am sorry for making the instruction for deploying the Web Service short, it is simply not in the article scope and these are simple steps which can be found in many pages on the web.
Conclusions
The case study of Named Kernel Object use in Web Services has a simple solution. The journey to find this solution, though, was not so simple. The reason for that is the lack of documentation both on the Web and in the MSDN. This is also the reason for writing this article in the first place. The article demonstrates the use of IIS security configuration in a very narrow case study. I hope my journey to solve the talk about this issue will pay off for the development community.
Good to know
For some reason, the \Global prefix is not required in Windows 2003 Server when using two Windows Forms applications. Nevertheless, I think that it is a good practice to use this prefix because you can not know where your code might be running in the future.
Tips
- Be aware of assigning obvious names to Kernel Objects. �MyEvent� is a very poor name and it is error prone.
- Named Kernel Objects are not supported by the .NET Framework wrapper classes. You need to use P/Invoke in order to enjoy this feature.
- Make a copy of the machine.config before changing it.
- Sometimes the only cure for IIS maladies, in regards to ASP.NET, is to return to defaults. This can easily done by uninstalling ASP.NET using aspregis �ua and then installing it again using aspregis �a. The utility can be found in <sys disk>:\windows\Microsoft.net\Framework\< Framework version>.
- Since we talked about Named Kernel Objects (which are reached only via P/Invoke), it is important to mention the imperative need to close the Kernel Object handles.
- For any configuration changes to the IIS, it is a good practice to restart the IIS service.
Links
Acknowledgment
I would like to thank my friend Mr. Arye Shapiro MD. for his help regarding English grammar and for his technical advices.
Appendix A
Kernel Object (KO)
If you are not familiar with the term Kernel Objects, do not worry, you have probably worked with them without knowing its name. The following is a short description about a Kernel Object: A Kernel Object is data structure. Microsoft uses it a lot in Windows to encapsulate objects like: Event, Mutex, Semaphore, Thread, Process, File Mapping, and many more. Kernel Objects are created by calling the Win32 API. In general, a Kernel Object is specific for a process. The handles returned from the API invocation are properties of the creating process. An exception to that is the Named Kernel Object.
A Named Kernel Object can be shared between processes. The API for Named Kernel Object handles a string parameter for name. Opening or creating Named Kernel Objects return a handle which is linked to a shared Kernel Object which is handled by the OS. When a process (a process is also a Kernel Object) is initialized, the OS allocates a kernel object handle table. The following diagram displays the process after initialization:
The following diagram contains two processes A and B. Each process creates an unnamed event.
- Process A calls the
CreateEvent API passing a NULL name.
- The System creates the Kernel Object in the Kernel memory.
- The System returns the address to the process. The API returns with a valid handle: 0.
- Process B calls the
CreateEvent API passing a name.
- The System creates the Kernel Object in the Kernel memory.
- The System returns the address to the process. The API returns with a valid handle: 0.
As you can see, there are two event kernel objects for each process, hence there is no sharing. Both operations return with a handle indexed with 0 simply because both processes have just initialized.
Why Use a Named Kernel Object?
First of all, it is an important and useful feature. Other than that, it is the simplest way to create a single instance process (e.g. when you try to run an ICQ process for the second time, the first instance is displayed). This is done by creating a named Mutex in the Main method and checking the return code of the GetLastError API. ERROR_ALREADY_EXISTS indicates that the process is already running. Another implementation is the use of shared memory between processes by the File Mapping objects, and for signaling events between processes.
The following diagram contains a process. It creates a named event.
- Process A calls the
CreateEvent API passing a unique name.
- The System checks if an Event Kernel Object with that name exists. For the example sake, let's say it doesn't. The System creates the Kernel Object in the memory (managed by the Kernel) and adds it to its own Kernel Object table for a named Kernel Object.
- The System returns the index to the process. The API returns with a valid handle: 1.
Note: The example shows that the System returns the index 14 as the address. I am not sure about that. The System might just as well return the 0xAEdad4 address. I am making this assumption because this subject is undocumented and because it does not interfere with the discussion.
The following diagram contains two processes (A and B). Both create a named event. Process A does it first as we saw in the previous diagram.
- Process B calls the
CreateEvent API passing a NULL name.
- The System checks if an Event Kernel Object with that name already exists and finds out that it does. The System does not create or add it to its own Kernel Object table.
- The System returns the address to the index. The API returns with a valid handle: 2.
As you can see, the index returned by the API is 2. I deliberately added another Kernel Object to index 1 (let's say Process B created a thread). I did it to stress that the index number is not relevant to the Named Kernel Object feature.
