Re: The revised DNS.EXE that was released in response to MS08-037

"W" <> wrote in message news:P5qdnZfK--...
>
> Further reading suggests the 2500 UDP server ports that the DNS server is
> setting up is a pool used only for *client* requests from the DNS server out
> to other DNS servers. Is it correct?
>
> Why would Microsoft need to pre-allocate UDP server ports in order to do UDP
> client UDP requests?
>
> --
> W
>

It is a security update to prevent spoofing. Attackers know that normally, without the update, a random ephemeral response ports (service ports), which is normally UDP 1024 and above. They are the response ports used by all Windows communications (not just DNS). An attacker may guess/randomize a port attack at DNS attempting to gain access to create records by injecting their own commands. By reserving the port, or creating this socket pool, it reduces the chance of a randomization attack, which attackers are using against Windows DNS.

Here's more info about it, how to test and see what memory is being used, and ways to disable or reduce the pool, if you feel it is interfering with other services.

================================================== ================================================== ==
================================================== ================================================== ==
The DNS patch

The DNS patch released in July, 2008, reserves 2500 ephemeral UDP ports.

When you run a netstat -ab, it will display the 2500 UDP ports that have been reserved, but not necessarily in use. This is part of the increased memory consumption that you may see. I've noticed the following (your mileage may vary):

dns.exe Before After
Mem usage 9758K 36,232K
Peak Mem 10,208K 36,584K
Paged Pool 71K 798K
NP Pool 17K 4,833K
Handles 238 5,217
Threads 20 20

MS08-037: Description of the security update for DNS in Windows Server 2003,
in Windows XP, and in Windows 2000 Server (client side): July 8, 2008:
http://support.microsoft.com/?id=951748

MS08-037: Vulnerabilities in DNS could allow spoofing
http://support.microsoft.com/default.aspx/kb/953230

How to reserve a range of ephemeral ports on a computer that is running Windows Server 2003 or Windows 2000 Server
http://support.microsoft.com/kb/812873

You experience issues with UDP-dependent network services after you install DNS Server service security update 953230 (MS08-037)
http://support.microsoft.com/default.aspx/kb/956188

Some Services May Fail to Start or May Not Work Properly After Installing MS08-037 (951746 and 951748)
http://blogs.technet.com/sbs/archive...nd-951748.aspx

SBS Services failing after MS08-037 - KB951746 and 951748
http://msmvps.com/blogs/thenakedmvp/...nd-951748.aspx

================================================== ================================================== ==
================================================== ================================================== ==


--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSA Messaging, MCT
Microsoft Certified Trainer


For urgent issues, you may want to contact Microsoft PSS directly. Please
check http://support.microsoft.com for regional support phone numbers.

"Efficiency is doing things right; effectiveness is doing the right things." - Peter F. Drucker
http://twitter.com/acefekay

Hello W. Please read inline below..

"W" <> wrote in message news: ...
>I still don't get it, sorry.
>
> First, are these ports being reserved for client UDP requests made by the
> DNS Server outbound to other DNS servers? It's not clear on why you would
> need a pool of server ports reserved for that purpose.

It's to protect against DNS Cache poisoning based on a DNS vulnerability that was discovered last summer. It affects all DNS servers, and NOT just WIndows. It affects BIND and others. I mentioned some of this in my previous post.

Here's a link with all DNS vendor products that it affects:

Vulnerability Note VU#800113 - Multiple DNS implementations vulnerable to cache poisoning:
http://www.kb.cert.org/vuls/id/800113

>
> If the concern is for inbound traffic to the DNS server, I'm again perplexed
> why DNS Server would need to run any ports above 1024. Aren't all the
> incoming requests to DNS server on ports 53 UDP and TCP? What specific
> services and request types is DNS Server running on ephemeral ports? The
> fact is we block all of those ports to incoming connections, and we haven't
> seen any side effect from that yet.

Yes, this is true about the ports, however, if a crafty attacker can bypass a direct connection to DNS, from the operating system itself, then he can form his attack. There are many articles that describe the exact parameters down to the byte level of how it all works, if you like me to find and post them.

>
> The link to the description of the security update doesn't actually explain
> what the update does; that linked article is focusing on peripheral issues
> like which files are affected and how to determine if the update causes
> problems.
>
> I really need to see the bigger picture here and I don't understand who is
> the client and who is the server, and how the attack against the DNS server
> is proceeding and how the MS08-037 fix addresses that.

Here is the actual exploit code, if you are familiar with this sort of thing. You can also check with Metasploit.org for more information.
http://www.caughq.org/exploits/CAU-EX-2008-0002.txt
>
> --
> W

You can choose not to install it, but I would if I were you. It's your company's system. If an attacker were to find an unpatched system, they will have a little fun with it.

Here are some other links to read up on:

beezari DNS bug leaks by matasano: (good explanation in laymen's terms)
http://beezari.livejournal.com/141796.html

Enterprise Systems DNS Flaw Ignites Controversy:
http://esj.com/security/article.aspx?EditorialsID=3244

Microsoft's Domain Name Server system fix may not be working: (how it may affect Exchange servers)
http://www.gcn.com/online/vol1_no1/46704-1.html

Redmond News DNS Problem Is 'Important' To Patch, Microsoft Says:
http://redmondmag.com/news/article.a...orialsID=10080

Let me know what you think.

Ace

In message <> "W"
<> was claimed to have wrote:

>First, are these ports being reserved for client UDP requests made by the
>DNS Server outbound to other DNS servers?

Yes.

>It's not clear on why you would
>need a pool of server ports reserved for that purpose.

Poor implementation. A better implementation would only reserve ports
as needed, and would then release them once they're no longer being
used.

>If the concern is for inbound traffic to the DNS server, I'm again perplexed
>why DNS Server would need to run any ports above 1024.

This is TCP/IP 101.

For two IP connected hosts to interact, you need a method to uniquely
identify the request (a stateful connection in TCP, or stateless in
UDP), in most cases this is done by building unique
srcIP:srcPORT:dstIP:dstPORT sets.

Any client making an outbound connection needs a unique port number on
the local host (or at least unique enough that no other connection to
the same dstIP:dstPORT has been active recently), by convention ports
above 1024 are used.

>Aren't all the
>incoming requests to DNS server on ports 53 UDP and TCP? What specific
>services and request types is DNS Server running on ephemeral ports?

None. No services are provided at all, but rather, your local DNS
server is listening for responses.

>The
>fact is we block all of those ports to incoming connections, and we haven't
>seen any side effect from that yet.
>
>The link to the description of the security update doesn't actually explain
>what the update does; that linked article is focusing on peripheral issues
>like which files are affected and how to determine if the update causes
>problems.
>
>I really need to see the bigger picture here and I don't understand who is
>the client and who is the server, and how the attack against the DNS server
>is proceeding and how the MS08-037 fix addresses that.

This is the place to start. When your desktop asks your local DNS
server to resolve www.microsoft.com, your desktop is the client and your
DNS server is the server. If your DNS server doesn't know the answer,
then it asks another DNS server (an upstream resolver, if so configured,
or any along the chain of root / .com / microsoft.com servers
otherwise), in this capacity your DNS server is the client.

If you host your own internet facing DNS for your company example.com,
when someone out in the world asks for example.com, you're the server.

In other words, think if it like this, when you're asking a question
you're the client, when you're answering, you're the server. When your
DNS server doesn't know the answer, it has to ask someone else, so it's
acting as a client at that point.

When acting as a server (listening for requests from clients) requests
come in to your port 53 (UDP or TCP), you send the response back to the
same IPort that asked the question. This only requires a hole or two
in your firewall, 53 (UDP and TCP)

When acting as a client, your DNS server sends an outbound request to
microsoft.com:53, but it sends that request from a randomly assigned
port on your side, in modern versions these requests come from the large
range of ports DNS assigns.

The vulnerability is that previously it was possible to guess the
complete srcIP:srcPORT:dstIP:dstPORT set which allowed an attacker to
spoof responses, and with enough spoofed responses timed when a real
query was likely to be asked, the victim would end up accepting a
spoofed response.

If your DNS server is an authoritative server and doesn't do any
recursive lookups of it's own, you don't need this wide port range to be
open. However, if you're doing recursive lookups, you do need this
range open in your firewall -- However, since there is always an
outbound packet first and the remote server is answering your request,
if your firewall is stateful and allows outbound traffic, you don't
specifically need to open the inbound return path.

"Dave Warren" <dave-> wrote in message news:...
> In message <> "W"
> <> was claimed to have wrote:
>
>>First, are these ports being reserved for client UDP requests made by the
>>DNS Server outbound to other DNS servers?
>
> Yes.
>
>>It's not clear on why you would
>>need a pool of server ports reserved for that purpose.
>
> Poor implementation. A better implementation would only reserve ports
> as needed, and would then release them once they're no longer being
> used.
>
>>If the concern is for inbound traffic to the DNS server, I'm again perplexed
>>why DNS Server would need to run any ports above 1024.
>
> This is TCP/IP 101.
>
> For two IP connected hosts to interact, you need a method to uniquely
> identify the request (a stateful connection in TCP, or stateless in
> UDP), in most cases this is done by building unique
> srcIP:srcPORT:dstIP:dstPORT sets.
>
> Any client making an outbound connection needs a unique port number on
> the local host (or at least unique enough that no other connection to
> the same dstIP:dstPORT has been active recently), by convention ports
> above 1024 are used.
>
>>Aren't all the
>>incoming requests to DNS server on ports 53 UDP and TCP? What specific
>>services and request types is DNS Server running on ephemeral ports?
>
> None. No services are provided at all, but rather, your local DNS
> server is listening for responses.
>
>>The
>>fact is we block all of those ports to incoming connections, and we haven't
>>seen any side effect from that yet.
>>
>>The link to the description of the security update doesn't actually explain
>>what the update does; that linked article is focusing on peripheral issues
>>like which files are affected and how to determine if the update causes
>>problems.
>>
>>I really need to see the bigger picture here and I don't understand who is
>>the client and who is the server, and how the attack against the DNS server
>>is proceeding and how the MS08-037 fix addresses that.
>
> This is the place to start. When your desktop asks your local DNS
> server to resolve www.microsoft.com, your desktop is the client and your
> DNS server is the server. If your DNS server doesn't know the answer,
> then it asks another DNS server (an upstream resolver, if so configured,
> or any along the chain of root / .com / microsoft.com servers
> otherwise), in this capacity your DNS server is the client.
>
> If you host your own internet facing DNS for your company example.com,
> when someone out in the world asks for example.com, you're the server.
>
> In other words, think if it like this, when you're asking a question
> you're the client, when you're answering, you're the server. When your
> DNS server doesn't know the answer, it has to ask someone else, so it's
> acting as a client at that point.
>
> When acting as a server (listening for requests from clients) requests
> come in to your port 53 (UDP or TCP), you send the response back to the
> same IPort that asked the question. This only requires a hole or two
> in your firewall, 53 (UDP and TCP)
>
> When acting as a client, your DNS server sends an outbound request to
> microsoft.com:53, but it sends that request from a randomly assigned
> port on your side, in modern versions these requests come from the large
> range of ports DNS assigns.
>
> The vulnerability is that previously it was possible to guess the
> complete srcIP:srcPORT:dstIP:dstPORT set which allowed an attacker to
> spoof responses, and with enough spoofed responses timed when a real
> query was likely to be asked, the victim would end up accepting a
> spoofed response.
>
> If your DNS server is an authoritative server and doesn't do any
> recursive lookups of it's own, you don't need this wide port range to be
> open. However, if you're doing recursive lookups, you do need this
> range open in your firewall -- However, since there is always an
> outbound packet first and the remote server is answering your request,
> if your firewall is stateful and allows outbound traffic, you don't
> specifically need to open the inbound return path.

Dave,

Excellent explanation!

Ace