exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

msie.zone.confusion.txt

msie.zone.confusion.txt
Posted Aug 17, 1999

Microsoft Internet Explorer still does not properly distinguish between sites that belong in the "Internet Zone" and sites that belong in the "Local Intranet Zone".

tags | exploit, local
SHA-256 | 2072e3d20db4085ab597a2fd0a98b7c13527d74a46c242a6dea8e1468d92ef02

msie.zone.confusion.txt

Change Mirror Download
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
Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    42 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close