Bugtraq mailing list archives
Re: [Full-disclosure] Microsoft DNS resolver: deliberately sabotagedhosts-file lookup
From: "Thor (Hammer of God)" <thor () hammerofgod com>
Date: Sat, 15 Apr 2006 11:39:18 -0700
It's a simple method to bypass malicious host file modification. Probably in response to malware like MyDoom, which specifically altered the hosts file to keep clients from accessing AV sites ( go.microsoft.com was also specifically included in MyDoom as well.) I agree that there should have been better documentation of this, but I think the noted objections are a bit hyperbolic. (Or as Dr. Tom Shinder would say, a "Creative Interpretation.") Statements like "deliberately sabotaged,"corrupting the resolver," and "intentional dsn poisoning" sound like something Steve Gibson would say. It's a local hosts-file entry filter, and is in the API. Malware hosts-file modification is common-- it makes sense for Microsoft to do this, though again, it would have been nice to see this functionality mentioned in the SP2 documentation. If administrators are really freaked about this, then they can block in their own internal DNS, proxies, firewalls, etc... This boils down to a "home user" issue, and thus, I think the decision to create exceptions was smart. If one doesn't want auto-updates on, then turn them off. I don't think host-entries are a smart way of blocking updates anyway. While it's unfortunate that the OP wasted a lot of his time trying to do this, one should note that a google for [turn off media player updates] returned KB278960 as the top hit. While I find the behavior interesting and feel it should be documented (it may be, actually... But I couldn't find anything in my MSDN Library or google) it is clearly by design, and IMHO, nothing more than an attempt to thwart the actively-exploited practice of malware modification of the hosts file, and not more Evil Empire Conspiracy. t On 4/13/06 12:01 PM, "Derek Soeder" <dsoeder () eeye com> spoketh to all:
Dave, great find! Those lists you dug up are named DomainScreenList and HostsScreenList in the symbols for DNSAPI; here they are for reference... DomainScreenList: windowsupdate.microsoft.com windowsupdate.com microsoftupdate.com download.microsoft.com update.microsoft.com HostsScreenList: microsoft.com www.microsoft.com support.microsoft.com wustats.microsoft.com microsoftupdate.microsoft.com office.microsoft.com msdn.microsoft.com go.microsoft.com msn.com www.msn.com msdn.com www.msdn.com A quick check suggests that this behavior debuted with XP SP2, and is present on 2003 SP1 as well. (I haven't looked at 2003 RTM, but it would be interesting if someone please would.) Although one could argue that this measure is intended to thwart attempts to block updating Microsoft products, it's indefensible because: 1) It's a point-in-time, cat-and-mouse defense against an ephemeral malware technique, a change that causes permanent headaches in situations like yours, and the potential for negative publicity as a result. 2) As far as I know, their malicious software removal tool didn't exist back when this behavior was created, so what good was keeping access to Microsoft open going to do an infected system? What good does it do to install a patch for a vulnerability that's already been exploited onto the computer of the archetypal "home user"? 3) Although it falls in line with removing raw sockets and limiting half-open TCP connections, making these Microsoft hosts and domain unfilterable is even more egregious because of the implications you mentioned, and because this behavior was never publicly documented. 4) Their selectiveness seems unfair. I'm sure all the antivirus/antispyware companies whose domains regularly end up in hosts-files would love to be added to the list, too. (So would everyone else whose software reports "anonymous usage statistics" and all the other companies making money from web advertising.*) Going back to #3, it would have been more disruptive but less controversial if they had removed regard for the hosts-file entirely, or made the resolver only consult the hosts-file after all else failed, thereby preventing it from being used for blocking. It's not a great analogy, but this move is sort of like if they had only blocked raw IP packets headed for a Microsoft IP address, instead of raw sockets entirely. Like those other XP SP2 changes mentioned above, there does not appear to be a way to disable this hosts-file screening behavior through configuration. -- Derek
Current thread:
- RE: [Full-disclosure] Microsoft DNS resolver: deliberately sabotagedhosts-file lookup Derek Soeder (Apr 14)
- Re: [Full-disclosure] Microsoft DNS resolver: deliberately sabotagedhosts-file lookup Thor (Hammer of God) (Apr 17)
- Re: [Full-disclosure] Microsoft DNS resolver: deliberately sabotagedhosts-file lookup Ansgar -59cobalt- Wiechers (Apr 18)
- Re: [Full-disclosure] Microsoft DNS resolver: deliberately sabotagedhosts-file lookup Paul Wouters (Apr 19)
- Re: [Full-disclosure] Microsoft DNS resolver: deliberately sabotagedhosts-file lookup Geo. (Apr 19)
- Re: [Full-disclosure] Microsoft DNS resolver: deliberately sabotagedhosts-file lookup Thor (Hammer of God) (Apr 23)
- Re: [Full-disclosure] Microsoft DNS resolver: deliberately sabotagedhosts-file lookup Geo. (Apr 23)
- Re: [Full-disclosure] Microsoft DNS resolver: deliberately sabotagedhosts-file lookup Thor (Hammer of God) (Apr 25)
- Re: [Full-disclosure] Microsoft DNS resolver: deliberately sabotagedhosts-file lookup Thor (Hammer of God) (Apr 17)
- <Possible follow-ups>
- Re: RE: [Full-disclosure] Microsoft DNS resolver: deliberately sabotagedhosts-file lookup john (Apr 19)
- Re: [Full-disclosure] Microsoft DNS resolver: deliberately sabotagedhosts-file lookup Thor (Hammer of God) (Apr 23)
- Re: [Full-disclosure] Microsoft DNS resolver: deliberately sabotagedhosts-file lookup John Biederstedt (Apr 23)
- Re: [Full-disclosure] Microsoft DNS resolver: deliberately sabotagedhosts-file lookup Thor (Hammer of God) (Apr 23)
- Re: [Full-disclosure] Microsoft DNS resolver: deliberately sabotagedhosts-file lookup Thor (Hammer of God) (Apr 23)