2

I have an ASP.NET Core web application running on Windows Server 2012 R2 and IIS 8.5. IIS uses a pair of web.config configuration variables to start up the application. This is the relevant web.config line:

<aspNetCore processPath="dotnet" arguments=".\MyWebsite.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false" />

The processPath variable is the command to run, and the arguments variable specifies the arguments to pass. dotnet.exe is installed when adding the ASP.NET Core runtime to the server. It is located in directory C:\Program Files\dotnet. This path is in the server's system PATH variable and the user context executing the command (the IIS application pool user) has read/execute permission for that path.

When I run my application I get an IIS 502.5 error. The Windows logs report the following:

Application 'MACHINE/WEBROOT/APPHOST/MYWEBSITE' with physical root 'C:\Sites\MyWebsite\' failed to start process with commandline 'dotnet .\MyWebsite.dll', ErrorCode = '0x80004005 : 80008083.

However, if I change the web.config to specify the full path to the executable (i.e. C:\Program Files\dotnet\dotnet.exe rather than dotnet) then the application runs fine.

So my assumption is that for some reason IIS cannot access the system environment variable PATH. Can anyone suggest a resolution? I've restarted the server since installing the ASP.NET Core runtime.

Tom Troughton
  • 143
  • 5

1 Answers1

4

When an application loads a dynamic link library or executeable without specifying a fully qualified path, Windows tries to locate the binary by searching a well-defined set of directories. This includes the local path, active path and the PATH variable (speaking of applications respecting that, like CMD).

If an attacker gains control of one of the directories, like on a website path in IIS, they can force the application to load a malicious copy of the file instead of that it was expecting. These attacks are known as "preloading attacks" and are common to all operating systems that support dynamically loading and/or shared libraries and binaries.

The effect of such attacks could be that an attacker can execute code in the context of the user (process) who is running the application. When the application pool is being run as Administrator, this could lead to a local elevation of privilege.

This is why a lot of system processes do not use or no longer use the PATH contents to search for their binaries.

More on this: Secure loading of libraries to prevent preloading attacks

bjoster
  • 4,805
  • 5
  • 25
  • 33
  • 1
    Thank you. It's great to have this insight. So I'll ensure the full path is used for the deployed application and remove web.config from my deployments, which I guess is Microsoft's intention. – Tom Troughton Oct 24 '17 at 14:31