|
Mistake #2—Running IIS in Process
IIS5 offers the ability to run Web applications out of process from the inetinfo process. IIS4 offered it too, but no one used it. ISAPI applications that run out of process with IIS execute in an application called dllhost.exe, which runs as the IWAM_machinename identity. Those that run in process, run as the same identity that the inetinfo process does, LocalSystem—the most dangerous account in Windows. Those that run in process are set to run in low isolation, while those that run out of process use the medium- and high-isolation settings.
When IIS accepts any request from a user, it always impersonates the user first. Even in the case of the anonymous account, IIS logs the IUSR_ account on and then impersonates it. So what's wrong with that? Imagine you have an ISAPI application that has a buffer overrun and an attacker injects code into that ISAPI. What do you think will be the first function call the attacker makes? You guessed it, ReverToSelf(). Now, if the ISAPI is running out of process, all the attacker gets is the IWAM_ account, essentially a slightly glorified guest. However, if the ISAPI is running in process, RevertToSelf() takes you back to the inetinfo identity—the LocalSystem account. The attacker now owns the box and can do anything he wishes. This is why the IPP and Index Server buffer overruns are so dangerous; when run in process with IIS, their bugs can lead to a complete system compromise.
The moral of the story is don't run your ISAPI application in process with IIS. You have very little to gain by doing so and possibly your entire system to lose.
| In this Article |
Introduction |
Mistake #2—Running IIS in Process |
|
Introduction
"