Bugtraq mailing list archives
NT DNS Implicit Search Order Hole
From: aleph1 () DFW NET (Aleph One)
Date: Sat, 9 Aug 1997 16:57:32 -0500
---------- Forwarded message ---------- Date: Fri, 8 Aug 1997 11:03:07 +1000 From: Geoff Halprin <geoff () SYSADMIN COM AU> To: NTBUGTRAQ () RC ON CA Subject: NT DNS Implicit Search Order Hole Morning all, Here is one to be wary of: NT 4.0 implements an implicit DNS search order. Seems like a simple, harmless statement, but actually it creates two major security holes... 1. Background Old (deprecated) DNS client behaviour was to implement an implicit search path for domain name lookups. Basically, it will implicitly escalate an unsuccessful DNS request for HOST.WG.SUB.DOMAIN.COM.AU to HOST.SUB.DOMAIN.COM.AU then HOST.DOMAIN.COM.AU then HOST.COM.AU and, maybe even, HOST.AU before returning an error. As you can see, this can lead to a name being resolved against entirely the wrong host, and one which is in another company or even country. This is deprecated behaviour, and should be disabled, or at least have a registry setting which does disable it. For more on search paths, see the O'Reilly DNS book, pp. 95 (2nd Ed). Of course, being deprecated behaviour, that means NT implements it. [Why, oh why, can't they learn from the world around them. :-( ] The problem is made more subtle (hidden) by Microsoft - a blank "search order" in the DNS config screens would imply no search order, rather than 'use an undocumented deprecated one'. 2. The Problems Problem #A: If a site is not using WINS, but incorrectly sets the "Enable DNS for Windows" option. Configuring a machine HOSTA in in a workgroup WG and a DNS domain DOMAIN.COM.AU will result in netbios attempting to exchange browser lists (or similar - I am not sure exactly what it is doing) with HOSTA.WG.DOMAIN.COM.AU and, failing that, with HOSTA.DOMAIN.COM.AU, HOSTA.COM.AU, etc. Problem #B: If a site does use WINS, but a machine is turned off (e.g. for the weekend) or crashes, then the client will escalate the query as previously described. This version of the problem is far more insideous. A site with good NT expertise, who has done everything right, is still susceptible should a box crash (or the network to it). 3. The Security Holes In both cases, the potential to exchange classified information exists, and most definitely a storm of NETBIOS traffic every 13 minutes results. I am receiving just such a storm as I write this. :-( This means that by turning a machine off (or it BSODing) my private internal company traffic is suddenly heading out over the Internet! No authorisation, no logging, silently. The only way to stop it is with a firewall (filtering router), which is also the only way to detect it. Someone less scrupulous could easily craft a fake NETBIOS server to exchange false lists and extract this information. As Jason suggested when I posted this to the SAGE-AU list, it would be interesting if someone went out and registered "workgroup.com.au" or similar. They could just sit back and collect privileged information. As a lesser hole, the amount of erroneous traffic that NT 4 machines are generating across the Internet is massive - every 13 minutes, most of it entirely undetected, and dropped because the (non NT) machine at the other end isn't listening to that port. Maybe we should sent MS our traffic bills?:-) 4. The Symptoms The problem relates to name resolution, and the effect is a whole lot of unauthorised NETBIOS traffic to your site from random sites across the world. (Actual symptom: attempts from foreign site to connect to port UDP/137 [netbios-ns] on one of your (probably not even NT) hosts.) The upshot of this is that sites all across the Internet are being blasted with NETBIOS packets every thirteen minutes because their registered domain name happens to coincide with a mis-formation of a random NT workgroup name. As the registered owner of 'sysadmin.com.au' and 'is.com.au', I get more of these because 'sysadmin' and 'is' are common host and workgroup names. I suspect that the implementation of the search path means that non-US sites (with a top level domain other than .com etc) are more likely to see this bug (the top level domain side-steps the built in limit in the implied search path). 5. The Workaround Many organisations do not use WINS, and certainly don't use WINS through DNS. So it is important to make sure that the "Enable DNS for Windows" option (very badly named) on the WINS configuration screen is disabled. This stops problem A dead. I do not know of a workaround to problem B other than the correct solution. 6. The Solution The solution is simple; either (a) remove this deprecated functionality, or (b) create a registry setting to disable it (which should default to disabled). Warm regards to all, Geoff ---------------------------------------------------------------------------- Geoff Halprin Geoff.Halprin () sysadmin com au Managing Director Phone: +61-3-9686-3233 The SysAdmin Group Pty Ltd Fax: +61-3-9686-3399 238 Richardson Street, Middle Park, VIC 3206 Pager: 03-9483-0355 PGP Fingerprint: (FE349AAD) 05 93 68 35 B2 09 8E 6F 79 8C 16 F8 8F BC 2E CB ----------------------------------------------------------------------------
Current thread:
- Vulnerability in 4.4BSD rfork() implementation, (continued)
- Vulnerability in 4.4BSD rfork() implementation Thomas H. Ptacek (Aug 02)
- Linux clone() looks safe (Re: Vulnerability in 4.4BSD rfork() Jeff Epler (Aug 02)
- Re: Linux clone() looks safe (Re: Vulnerability in 4.4BSD rfork() Marc Slemko (Aug 03)
- Re: sendmail -C: Known? Patches? (AIX 4.1.5) Eric Allman (Aug 06)
- Re: sendmail -C: Known? Patches? (AIX 4.1.5) Eric Allman (Aug 07)
- Re: sendmail -C: Known? Patches? (AIX 4.1.5) Gene Spafford (Aug 09)
- Re: sendmail -C: Known? Patches? (AIX 4.1.5) Troy Bollinger (Aug 10)
- procfs hole Brian Mitchell (Aug 10)
- Re: procfs hole Jonathan A. Zdziarski (Aug 10)
- Re: procfs hole Brian Mitchell (Aug 10)
- Program To decrypt password in ws_ftp.ini JeBe (Aug 10)