msie.zone.confusion.txt

1999-08-17T00:00:00
ID PACKETSTORM:12144
Type packetstorm
Reporter Packet Storm
Modified 1999-08-17T00:00:00

Description

                                        
                                            `Date: Fri, 5 Mar 1999 21:53:18 -0500  
From: Jim Paris <jim@JTAN.COM>  
To: BUGTRAQ@netspace.org  
Subject: More Internet Explorer zone confusion  
  
Even after the patch described in Microsoft Security Bulletin MS98-016  
(http://www.microsoft.com/security/bulletins/ms98-016.asp), IE4 still  
has big problems with distinguishing between sites that belong in the  
"Internet Zone" and sites that belong in the "Local Intranet Zone".  
  
MS98-016 dealt with addresses such as http://031713501415/, which  
resolve to Internet hosts but are categorized as being in the "Local  
Intranet Zone".  
  
I've found two cases where the problem still exists. The first is when  
the user has the "Domain Suffix Search Order" in the TCP/IP DNS settings  
set to include domains such as "com". In that case, the address  
http://microsoft/  
will retrieve the page at  
http://microsoft.com/  
but it will be considered to be in the "Local Intranet Zone".  
  
The second case occurs when a host has an assigned alias in the hosts  
table (C:\WINDOWS\HOSTS). A host table entry such as:  
207.46.131.13 hello  
will cause the URL  
http://hello/  
to retrieve the page at http://207.45.131.13/, but (yep, you guess it)  
Internet Explorer still considers it to be in the "Local Intranet Zone".  
  
This has security implications, since settings for the Local Intranet  
Zone may be (and, by default, ARE) less secure than those for the  
Internet Zone.  
  
  
And the funny part? Microsoft's response when I told them this:  
  
--8<---cut here-----------------------------------------  
  
Hi Jim -  
  
Had a talk with one of the IE developers, and this behavior is correct.  
Here's why: it's impossible to tell from an IP address whether it's internal  
or external. 100.100.100.100, or any other address, could be either  
internal or external, depending on whether you're behind a firewall or not.  
That means that IE has to rely on the URL. By convention, an URL that does  
not end with a "dot-something" (.com, .edu, .gov, etc) is assumed to be an  
internal site. I'm told that this is how all web browsers make the  
distinction. You have to make specific reconfigurations to allow the  
dotless URLs to resolve externally. Thanks,  
  
Secure@Microsoft.Com  
  
--8<---cut here-----------------------------------------  
  
  
"This behavior is correct"?!?!?! Give me a break. They obviously  
didn't think so when they released the MS98-016 bulletin.  
  
  
Jim Paris  
jim@jtan.com  
  
--------------------------------------------------------------------------------  
  
Date: Mon, 8 Mar 1999 03:56:27 -0500  
From: Jeremy Nimmer <bugtraq.user@parity.mit.edu>  
To: BUGTRAQ@netspace.org  
Subject: Re: More Internet Explorer zone confusion  
  
  
>MS98-016 dealt with addresses such as http://031713501415/  
>...  
>user has the "Domain Suffix Search Order" in the TCP/IP DNS settings  
>...  
>The second case occurs when a host has an assigned alias in the hosts  
>...  
>"This behavior is correct"?!?!?! Give me a break. They obviously  
>didn't think so when they released the MS98-016 bulletin.  
>  
>Jim Paris  
>jim@jtan.com  
  
The difference between MS98-016 and your examples is simple. The bulletin  
addressed an issue where an external site could, without your control, fool  
your browser into thinking a remote site was "local intranet". In your  
examples, the user must choose specific settings to allow the problem to  
occur. If you are concerned about the problem, simply remove .com, etc.  
>from your DNS suffix search, and don't put nasty hosts in your hosts file.  
  
The zone settings are not meant to be rock-solid security protection. If  
they pose a risk to you, set all zones to the maximum security. This was  
all already talked about when the above-mentioned bulletin came out.  
  
In the end, this is not a "bug" in the browser - it's a configuration  
problem. While worthy of mention, it does not deserve flamage.  
  
Thanks,  
-= remmiN ymereJ | Jeremy Nimmer =-  
  
--------------------------------------------------------------------------------  
  
Date: Mon, 8 Mar 1999 23:37:28 +1300  
From: Oliver Lineham <oliver@LINEHAM.CO.NZ>  
To: BUGTRAQ@netspace.org  
Subject: Re: More Internet Explorer zone confusion  
  
At 21:53 5/03/99 -0500, you wrote:  
  
Yech.  
  
>That means that IE has to rely on the URL. By convention, an URL that does  
>not end with a "dot-something" (.com, .edu, .gov, etc) is assumed to be an  
>internal site. I'm told that this is how all web browsers make the  
>distinction. You have to make specific reconfigurations to allow the  
>dotless URLs to resolve externally. Thanks,  
  
This is insane - and most probably not how it distinguishes domains at all.  
  
Such a system implies that the "dot-something"s are hard-coded into the  
browser! This would be a similar flaw to the original cookie  
specification's one about domains that I announced last year. Consider:  
  
- Country domains. They're not dot-somethings, but under this regime  
anything from somewhere like New Zealand (.nz) would be a "Local Intranet  
Site".  
  
- New TLDs. Internic goes and adds a .web or .store or something that  
didn't exist when the browser was released. I'm sure all the e-commerce  
sites on .store would love their servers being considered "Local Intranet  
Sites"!  
  
If this is how the zones are implemented, then its insane. If not, then  
IE's claim of being able to distinguish intranet sites from internet ones  
is an outright lie and the "feature" should be removed.  
  
Oliver  
  
---------------------------------------------------  
Internet Services / Webdesign / Strategic Planning  
PO Box 30-481, Lower Hutt, NZ oliver@lineham.co.nz  
Phone +64 4 566-0627 Facsimile +64 4 570-1900  
  
--------------------------------------------------------------------------------  
  
Date: Mon, 8 Mar 1999 09:06:23 +0000  
From: David E. Smith <dave@TECHNOPAGAN.ORG>  
To: BUGTRAQ@netspace.org  
Subject: Re: More Internet Explorer zone confusion  
  
On Fri, 5 Mar 1999, Jim Paris wrote about the Local Intranet Zone.  
  
All the comments made are, technically, correct, but Microsoft could have  
at least tried. None of these are foolproof, but they're a start.  
  
* Be paranoid about entries in the hosts file. Arguably, hosts files are  
obsolete, thanks to DNS. (No, I won't make the argument.)  
* Warning dialog boxes for the above, and maybe for anything where the TLD  
is guessed at. (The http://microsoft/ example. Just warn the user that the  
requested site was guessed, give some sane options like `Go there, treat  
it as Internet', `Go there, treat it as local', `Don't go there', and so  
on.)  
* Anything that doesn't resolve to a designated local zone (10.*.*.*, and  
the other reserved addresses) gets the same warning.  
  
Or, just change the default behaviour on all those to treat the site as  
Internet rather than intranet. Probably easier that way, though a bit more  
troublesome for the user, especially when we guess wrong.  
  
Care to take bets on whether anything even remotely like this is ever  
done?  
  
...dave  
  
--------------------------------------------------------------------------------  
  
Date: Mon, 8 Mar 1999 00:18:10 -0800  
From: Walt Armour <walt@BLARG.NET>  
To: BUGTRAQ@netspace.org  
Subject: Re: More Internet Explorer zone confusion  
  
I would agree that these are still issues but there is a difference  
between them and the original problem.  
  
With the original problem any site could redirect you to a site and make  
it look like Local Intranet simply by using the 'http://031713501415/'  
format.  
  
With these two new issues someone must have direct knowledge about your  
machine's configuration or have direct access to your machine in order to  
make a not-quite-too-common configuration change. If either of these  
situations occurs then the safety level of my browser will quickly become  
the least of my worries. :)  
  
IMO Microsoft is right in saying that the problems are (marginally)  
different. Whether or not their method for determining "local intranet"  
is right is a completely different subject.  
  
walt  
  
--------------------------------------------------------------------------------  
  
Date: Mon, 8 Mar 1999 11:07:19 -0600  
From: iversen <signal11@MEDIAONE.NET>  
To: BUGTRAQ@netspace.org  
Subject: Re: More Internet Explorer zone confusion  
  
Oliver Lineham wrote:  
> - New TLDs. Internic goes and adds a .web or .store or something that  
> didn't exist when the browser was released. I'm sure all the e-commerce  
> sites on .store would love their servers being considered "Local Intranet  
> Sites"!  
>  
> If this is how the zones are implemented, then its insane. If not, then  
> IE's claim of being able to distinguish intranet sites from internet ones  
> is an outright lie and the "feature" should be removed.  
  
  
This seems to be trivial to resolve - put everything in the internet zone  
unless it matches a list containing the local intranets. Then do  
reverse-dns  
of everything that's allegedly inside the intranet and make sure everything  
matches up. It isn't a perfect solution, but it would make it substantially  
harder to fake a remote site as local. You also get the added benefit of  
not needing to worry about how IE resolves domains/ip addresses.  
  
  
  
--  
signal11@mediaone.net | BOFH, Malign networks  
I'll give you the TCO of Linux as soon as my  
calculator stops saying "divide by zero error."  
  
--------------------------------------------------------------------------------  
  
Date: Mon, 8 Mar 1999 14:17:43 -0500  
From: Jim Paris <jim@JTAN.COM>  
To: BUGTRAQ@netspace.org  
Subject: Re: More Internet Explorer zone confusion  
  
> The difference between MS98-016 and your examples is simple. The bulletin  
> addressed an issue where an external site could, without your control, fool  
> your browser into thinking a remote site was "local intranet".  
  
And this can occur with my examples as well. I didn't control it at  
all.  
  
> In your  
> examples, the user must choose specific settings to allow the problem to  
> occur. If you are concerned about the problem, simply remove .com, etc.  
> from your DNS suffix search, and don't put nasty hosts in your hosts file.  
  
Just because I added a DNS suffix search order and put hosts into my  
hosts file does not (or, at least, SHOULD not) mean that I am choosing  
"specific settings to allow the problem to occur". How was I supposed  
to know that simplifying my life by adding a search suffix of ".com" was  
opening me up to a vulnerability?  
  
> In the end, this is not a "bug" in the browser - it's a configuration  
> problem. While worthy of mention, it does not deserve flamage.  
  
No, this is a bug in the browser. Changing something over at point A  
shouldn't affect my security at point B.  
  
-jim  
  
--------------------------------------------------------------------------------  
  
Date: Mon, 8 Mar 1999 11:58:55 -0800  
From: Paul Leach <paulle@MICROSOFT.COM>  
To: BUGTRAQ@netspace.org  
Subject: Re: More Internet Explorer zone confusion  
  
> -----Original Message-----  
> From: Oliver Lineham [mailto:oliver@LINEHAM.CO.NZ]  
> Sent: Monday, March 08, 1999 2:37 AM  
> To: BUGTRAQ@NETSPACE.ORG  
> Subject: Re: More Internet Explorer zone confusion  
>  
>  
> At 21:53 5/03/99 -0500, you wrote:  
>  
> Yech.  
>  
> >That means that IE has to rely on the URL. By convention,  
> an URL that does  
> >not end with a "dot-something" (.com, .edu, .gov, etc) is  
> assumed to be an  
> >internal site. I'm told that this is how all web browsers make the  
> >distinction. You have to make specific reconfigurations to allow the  
> >dotless URLs to resolve externally. Thanks,  
>  
> This is insane - and most probably not how it distinguishes  
> domains at all.  
  
That's correct.  
I believe that the rule for Intranet zone is simple -- if the name has no  
"." and is less than 15 characters long, then it's Intranet zone. This  
algorithm works with the default configuration of Windows. If you configure  
your machine so that the above assumption is violated, then you'll get a  
mis-classification.  
  
When designing better ways of doing this, keep in mind that the primary tool  
that the browser has to work with is "gethostbyname" -- which, IMO, doesn't  
return enough information about how the name was resolved to be helpful for  
security purposes (even though it garnered some in the process of  
resolution). For example, it doesn't say whether /etc/hosts or LMHOSTS was  
used to resolve the name, or which DNS search suffix was used.  
  
Paul  
  
--------------------------------------------------------------------------------  
  
Date: Mon, 8 Mar 1999 19:49:32 -0600  
From: Jeremie <jer@JEREMIE.COM>  
To: BUGTRAQ@netspace.org  
Subject: Re: More Internet Explorer zone confusion (new issue)  
  
> The assumptions may indeed be flawed, but I don't understand how your  
> observations below demonstrate that.  
  
The assumption:  
[if the name has no "." and is less than 15 characters long, then it's  
Intranet zone]  
  
Simply:  
The name "ls" has no "." and is less than 15 characters, and yet it is a  
valid *Internet* host and should *not* be qualified as "Intranet Zone".  
  
Jeremie  
jer@jeremie.com  
  
--------------------------------------------------------------------------------  
  
Date: Tue, 9 Mar 1999 01:59:08 -0500  
From: Christopher Masto <chris@NETMONGER.NET>  
To: BUGTRAQ@netspace.org  
Subject: Re: More Internet Explorer zone confusion  
  
Is this intranet zone thing _really_ of any value? Why is there a  
built-in default assumption that something from a "local" server is  
more trustworthy? Consider the following situations:  
  
1. A customer of your ISP, netmonger.net, is evil. They have a page  
that links or redirects to http://www/~evil/evil.html, taking  
advantage of the fact that your machine is configured with your  
ISP's domain in the search list.  
  
2. You go to school at RPI. You have a dorm ethernet connection.  
Your machine is naive.dorm.rpi.edu, and you have dorm.rpi.edu  
in your domain search list. An evil person gets evil.dorm.rpi.edu,  
and you know the rest.  
  
3. You work at Giganticorp and have access to high-level trade secrets.  
Giganticorp has an intranet where employees can put up their own  
web pages. An evil employee takes advantage of the default security  
settings to gain access to your secrets, which he sells to the  
competition.  
  
Numbers 1 and 2 ask the question, "Why are we assuming that a  
non-qualified host name implies intranet implies trust?" Number 3  
asks the question, "Why are we assuming that intranet implies trust?"  
Another question is "How many people who use IE have no intranet?"  
Considering that there are a quantity of tools available to deploy  
IE at your company with preconfigured settings, why not default to  
not having this intranet zone. If Giganticorp needs to turn down  
the security, they can do so at the same time they're customizing  
the rest of the settings.  
  
I don't personally use Microsoft products, and I am not quite familiar  
with the specific security precautions that are disabled for the  
intranet zone, but if they're enough to cause concern on the Internet,  
the same problems can occur even when the browser isn't malfunctioning  
at all.  
--  
Christopher Masto Director of Operations NetMonger Communications  
chris@netmonger.net info@netmonger.net http://www.netmonger.net  
  
Free yourself, free your machine, free the daemon -- http://www.freebsd.org/  
  
--------------------------------------------------------------------------------  
  
Date: Tue, 9 Mar 1999 08:58:43 +0100  
From: Tilman Schmidt <Tilman.Schmidt@SEMA.DE>  
To: BUGTRAQ@netspace.org  
Subject: Re: More Internet Explorer zone confusion  
  
At 11:07 08.03.99 -0600, iversen wrote:  
>Oliver Lineham wrote:  
>> If this is how the zones are implemented, then its insane. If not, then  
>> IE's claim of being able to distinguish intranet sites from internet ones  
>> is an outright lie and the "feature" should be removed.  
>  
>This seems to be trivial to resolve - put everything in the internet zone  
>unless it matches a list containing the local intranets. Then do  
>reverse-dns  
>of everything that's allegedly inside the intranet and make sure everything  
>matches up.  
  
This is of course the correct way to implement an "intranet zone".  
It has, however, one serious drawback: you have to configure it.  
Consumer product manufacturers like Microsoft want their product  
to work as much "out of the box" as possible.  
  
However, IMHO there is no way to implement the concept of "intranet  
zone" reliably without actually telling the browser the exact extent  
of your intranet one way or other. Heuristics like "if there is no  
dot in the hostname then let's assume it is in the intranet" just  
aren't reliable enough to base a security mechanism on.  
  
At Mon, 8 Mar 1999 11:58:55 -0800, Paul Leach wrote:  
>I believe that the rule for Intranet zone is simple -- if the name has no  
>"." and is less than 15 characters long, then it's Intranet zone. This  
>algorithm works with the default configuration of Windows. If you configure  
>your machine so that the above assumption is violated, then you'll get a  
>mis-classification.  
  
It doesn't even work with the default configuration of Windows,  
because the basic assumption that every host with an FQDN in the  
same DNS domain as the client is also in the intranet zone is  
flawed. There are perfectly legitimate configurations where this  
is not the case.  
  
>When designing better ways of doing this, keep in mind that the primary tool  
>that the browser has to work with is "gethostbyname" -- which, IMO, doesn't  
>return enough information about how the name was resolved to be helpful for  
>security purposes (even though it garnered some in the process of  
>resolution). For example, it doesn't say whether /etc/hosts or LMHOSTS was  
>used to resolve the name, or which DNS search suffix was used.  
  
It is irrelevant how the name was resolved. You need a mechanism  
to specify the intended scope of your intranet unambiguously,  
instead of relying on some unspoken assumption like "for our  
purposes, 'intranet zone' will be taken to mean all hosts which  
happen to have at least one FQDN in the same domain as the  
client".  
  
--  
Tilman Schmidt E-Mail: Tilman.Schmidt@sema.de (office)  
Sema Group Koeln, Germany tilman@schmidt.bn.uunet.de (private)  
"newfs leaves the filesystem in a well known state (empty)."  
- Henrik Nordstrom  
  
--------------------------------------------------------------------------------  
  
Date: Tue, 9 Mar 1999 17:15:07 -0500  
From: Jim Frost <jimf@FROSTBYTES.COM>  
To: BUGTRAQ@netspace.org  
Subject: Re: More Internet Explorer zone confusion  
  
  
|This is of course the correct way to implement an "intranet zone".  
|It has, however, one serious drawback: you have to configure it.  
|Consumer product manufacturers like Microsoft want their product  
|to work as much "out of the box" as possible.  
  
Since there is no intranet for most consumers this seems like largely a  
non-issue. Those with intranets in their home probably know enough to  
configure it properly. And businesses should have IT departments whose job it  
is to manage it.  
  
So what's the problem?  
  
|It doesn't even work with the default configuration of Windows,  
|because the basic assumption that every host with an FQDN in the  
|same DNS domain as the client is also in the intranet zone is  
|flawed. There are perfectly legitimate configurations where this  
|is not the case.  
  
Not only legitimate, but increasingly common. Cable modem customers, for  
instance, tend to have their entire region in the same "intranet": eg  
customer.ne.mediaone.net. I assure you that you don't want to treat the entire  
northeast region of MediaOne customers as trusted in any way, shape, or form.  
  
jim  
`