IIS 6 prefixing paths with \?

One of the most fundamental security changes in IIS6 appends \\?\ to all filesystem access by IIS. This is supposed to be fairly transparent, but...

Question:

Dear comrades:

I have a cgi executable program that has worked just fine under W2000 Server. It also works fine when tested with Windows XP Pro.

Under W2003, the cgi executable works except when the cgi attempts to read a file from disk, please see the message reported below:

Cannot open file \\?\C:\Web\\Templates\DefaultTemplate.htm

Previously, the file path was not prefixed with \\?\ and everything worked as expected. The cgi found the path and loaded the template above. Can someone please shed some light as to what is now different under IIS 6?

Thank you,

Answer:

This looks like a bug in the CGI executable program exposed by IIS6.

\\?\ is a documented and existing syntax accepted by File IO API calls on Windows. Look up CreateFile and fopen on MSDN for more details.

For security reasons, IIS 6.0 uses \\?\ on all file system accesses (this includes serving of static files and loading of ISAPI DLLs and CreateProcess of CGI EXEs). \\?\ disables namespace canonicalization by the file system, which prevents a whole class of security issues related to canonicalization.

Since \\?\ is accepted by all File IO API calls on Windows, this change should transparently work downstream for any ISAPI DLL and CGI EXE.

A common failure pattern that I have seen happens when the custom ISAPI DLL or CGI EXE tries to interpret a filename and does so incorrectly ( for example, code that assumes that leading \\ means UNC share - this code will think that the UNC share server name is "?", which causes problems). This failure is basically a bug in the custom binary.

Now, please realize that this change in IIS 6 to append  \\?\ is by-design and cannot be changed/turned-off. The reason IIS 6 insists on this change is because of security. We knew that there will be a hit to application compatibility (i.e. exposing bugs in existing code, even if righteous, is not good compatibility), but the security gained from eliminating this canonicalization risk is worth the change.

See this other post for related possibilities.

//David