[9859] in bugtraq
Re: More Internet Explorer zone confusion
daemon@ATHENA.MIT.EDU (Tilman Schmidt)
Tue Mar 9 16:32:59 1999
Date: Tue, 9 Mar 1999 08:58:43 +0100
Reply-To: Tilman Schmidt <Tilman.Schmidt@SEMA.DE>
From: Tilman Schmidt <Tilman.Schmidt@SEMA.DE>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <36E403C7.C752CC0C@mediaone.net>
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
