IIS 6 won't serve .REG files?

[Mark J. McGinty]

Greets,

One site I've written allows the user to install an IE extension menu (not
malware at all) by downloading/merging a short .REG file. Worked like a
peach on Win2K Server, now that I upgraded to Server 2003, it returns a 404
file not found error. I'm positive the file is there/spelled right. I
changed it to .txt and it displays the text in the user's browser.

So there's little question that this is some "security" addition, to help
keep us safe from the functionality we're used to. I could see browser-end
warnings/protection, as long as it can be adjusted for trusted zones, but
server-side content filters that block serving certain extensions? WTF?

So, after the obligatory scan of msdn, I looked for mappings to 404.dll,
mime types and other seemingly quasi-relevant configs... found nothing that
referenced .REG.

Does anyone know how to disable this "protection"? Are there any other
dastardly extensions it will "save" me from? (Gosh I just don't know when
I've ever felt so cozy and safe.)

tia,
Mark

 

[Bernard Cheah [MVP]]

Just add in the .reg mime type
IIS 6.0 Does Not Serve Unknown MIME Types
http://support.microsoft.com/?id=326965

--
Regards,
Bernard Cheah
http://www.microsoft.com/iis/
http://www.iiswebcastseries.com/
http://www.msmvps.com/bernard/

 

[Mark J. McGinty]

Just add in the .reg mime type
IIS 6.0 Does Not Serve Unknown MIME Types
http://support.microsoft.com/?id=326965

Thanks! Any idea why they did such a thing? I don't see how it enhances
server security at all. (And inside of a web server seems like a ridiculous
place to try to enhance client security.)


-Mark

 

[Tom Kaminski [MVP]]

Thanks! Any idea why they did such a thing? I don't see how it enhances
server security at all. (And inside of a web server seems like a
ridiculous place to try to enhance client security.)

The "security enhancement" was to lock down the server better - only
allowing it to serve file/mime-types that have been approved by the admin.

 

[Mark J. McGinty]

The "security enhancement" was to lock down the server better - only
allowing it to serve file/mime-types that have been approved by the admin.

Implying that admin has no control over which files are placed in web
directories? Implying that files of registered MIME types can't be
dangerous? But the main point being, how could any file being served as a
mere download (not a script, CGI or anything else executed in the context of
the server) be dangerous to that server?

As I think of it, the way it's implemented seems inappropriate, it should
return a security-oriented error, indicating the file is there but
inaccessible, not a 404, indicating it is missing. That at least would be
an accurate representation of the scenario, and would be easier to
grasp/mitigate for the untold thousands of web programmers that will find
this "enhancement" in their critical path, as 2K3 becomes more widely
deployed.


-Mark

 

[Bernard Cheah [MVP]]

All the info are well documented with IIS 6.0. As for reporting 404 to the
client is another security measurement, at least it will not expose system
information to the user or potential hacker.

For mime type error, you will get 404.3 in the IIS log file, for dymanic
content blocking you will get 404.2 error instead. For starter, open IIS
MMC, F1 - go to the IIS help - troubleshooting section.

--
Regards,
Bernard Cheah
http://www.microsoft.com/iis/
http://www.iiswebcastseries.com/
http://www.msmvps.com/bernard/

 

[Mark J. McGinty]

That aside, you can certainly get around the problem if you use a script
to send the requested file. This approach avoids the broader security
problems posed by allowing IIS to send any MIME type/extension from
anywhere on your web site.

Things you may find useful in this endeavor:

ASP Response.ContentType property
http://msdn.microsoft.com/library/en-us/iissdk/html/7dfd936a-b985-4e15-a774-269dfcfd053c.asp

ASP Response.BinaryWrite method
http://msdn.microsoft.com/library/en-us/iissdk/html/04d5f44f-cc63-4465-b45f-634b95130b4a.asp

ADO Stream Object
http://msdn.microsoft.com/library/en-us/ado270/htm/mdobjstream.asp

Dave,

I've used all of those constructs many times. Interesting that ASP can
return any MIME type without restriction, while the web server is limited to
only registered types.

I guess the thing I'm hanging up on is that I'm not sure why the *server*
cares about the MIME type at all? Is it just so the server can implicitly
generate a ContentType header? The client system isn't equally capable of
inferring MIME type from extension?

What I don't get is, how is it any more or less safe for a server to serve
one content type versus another. It seems to me that all it needs to do is
stream the content to the client, and let the client render it however it's
going to render it. I don't get how the contents of that stream threaten a
server, and I really don't get how the server's having knowledge of a given
content type (in the form of a registration) makes it safer for the *server*
to serve that content, compared to serving content of an unregistered type.

I'm having difficulty perceiving the threat to the server. As such the
benefit of contriving a mechanism to load from file and send content via
script (when the same thing could be accomplished by passing a URL to the
server) escapes me.


-Mark

 

[Dave Anderson]

The default filename? calendar.asp. Give it a try:
http://tctouch.com/calendar/calendar.mdb

Obviously, I meant Calendar.mdb



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Mark Schupp]

I guess the thing I'm hanging up on is that I'm not sure why the *server*

cares about the MIME type at all? Is it just so the server can implicitly
generate a ContentType header? The client system isn't equally capable
of inferring MIME type from extension?

Here is an short explanation from a non-iis web-server
http://www.keyfocus.net/kfws/ see "hacker protection"

I haven't found an actual security recommendation regarding the restriction
of web-server mime types but I expect that there is one out there somewhere.