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" <mm******@spamfromyou.com> wrote in message
news:Oq*************@TK2MSFTNGP15.phx.gbl...

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

[Mark J. McGinty]

"Bernard Cheah [MVP]" <qb******@hotmail.com.discuss> wrote in message
news:ug**************@tk2msftngp13.phx.gbl...

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
Regards,
Bernard Cheah
http://www.microsoft.com/iis/
http://www.iiswebcastseries.com/
http://www.msmvps.com/bernard/
"Mark J. McGinty" <mm******@spamfromyou.com> wrote in message
news:Oq*************@TK2MSFTNGP15.phx.gbl...

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

[Tom Kaminski [MVP]]

"Mark J. McGinty" <mm******@spamfromyou.com> wrote in message
news:OO****************@TK2MSFTNGP14.phx.gbl...

"Bernard Cheah [MVP]" <qb******@hotmail.com.discuss> wrote in message
news:ug**************@tk2msftngp13.phx.gbl...

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.)

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.

--
Tom Kaminski IIS MVP
http://www.microsoft.com/windowsserv...y/centers/iis/
http://mvp.support.microsoft.com/
http://www.iistoolshed.com/ - tools, scripts, and utilities for running IIS

[Mark J. McGinty]

"Tom Kaminski [MVP]" <tomk (A@T) mvps (D.O.T) org> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

"Mark J. McGinty" <mm******@spamfromyou.com> wrote in message
news:OO****************@TK2MSFTNGP14.phx.gbl...

"Bernard Cheah [MVP]" <qb******@hotmail.com.discuss> wrote in message
news:ug**************@tk2msftngp13.phx.gbl...

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.)

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
--
Tom Kaminski IIS MVP
http://www.microsoft.com/windowsserv...y/centers/iis/
http://mvp.support.microsoft.com/
http://www.iistoolshed.com/ - tools, scripts, and utilities for running
IIS

[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" <mm******@spamfromyou.com> wrote in message
news:jO2te.3510$iG5.3454@fed1read05...

"Tom Kaminski [MVP]" <tomk (A@T) mvps (D.O.T) org> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

"Mark J. McGinty" <mm******@spamfromyou.com> wrote in message
news:OO****************@TK2MSFTNGP14.phx.gbl...

"Bernard Cheah [MVP]" <qb******@hotmail.com.discuss> wrote in message
news:ug**************@tk2msftngp13.phx.gbl...
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.)

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

--
Tom Kaminski IIS MVP
http://www.microsoft.com/windowsserv...y/centers/iis/
http://mvp.support.microsoft.com/
http://www.iistoolshed.com/ - tools, scripts, and utilities for running
IIS

[Dave Anderson]

Mark J. McGinty wrote:

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?

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...9dfcfd053c.asp

ASP Response.BinaryWrite method
http://msdn.microsoft.com/library/en...4b95130b4a.asp

ADO Stream Object
http://msdn.microsoft.com/library/en...dobjstream.asp

--
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 J. McGinty]

"Dave Anderson" <GT**********@spammotel.com> wrote in message
news:11*************@corp.supernews.com...

Mark J. McGinty wrote:

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?

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...9dfcfd053c.asp

ASP Response.BinaryWrite method
http://msdn.microsoft.com/library/en...4b95130b4a.asp

ADO Stream Object
http://msdn.microsoft.com/library/en...dobjstream.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

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.

[Dave Anderson]

Mark J. McGinty wrote:

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.

Perhaps the classic example is .inc files. The IIS 4/5 default was to serve
'em up as text. Unless the web server had been configured to parse .inc with
asp.dll, the use of .inc opened a vulnerability. Anyone who could guess your
filenames could read your server-side includes.

So the threat isn't *necessarily* to the web server, but potentially to
something far more important, like your database.

--
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.

[Dave Anderson]

I wrote:

Perhaps the classic example is .inc files. The IIS 4/5 default was to
serve 'em up as text. Unless the web server had been configured to
parse .inc with asp.dll, the use of .inc opened a vulnerability.
Anyone who could guess your filenames could read your server-side
includes.
So the threat isn't *necessarily* to the web server, but potentially
to something far more important, like your database.

Here's a better example: ASP Calendar from Active Server Corner. This was a
freeware calendaring app that uses an Access DB. A 2-minute search on Yahoo!
found this:

http://tctouch.com/calendar/
The default filename? calendar.asp. Give it a try:
http://tctouch.com/calendar/calendar.mdb
Bingo. Now you can look into the DB and grab the admin credentials. Then log
in**:
http://tctouch.com/calendar/admin.asp
Are you starting to see why allowing .mdb might not have been a great idea?

**Please do not mess with this guy's calendar. I have no idea who this
belongs to. It was merely on the first page of results when I searched for
an example.

--
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.

[Dave Anderson]

I wrote:

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.
--
--Mark Schupp