Date: Fri, 5 Mar 1999 21:53:18 -0500 From: Jim Paris 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 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 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 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 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 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 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 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 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 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 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 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