Microsoft Downplaying Recent DNS Vulnerability

Microsoft Watch writes "Microsoft downplays a recent DNS vulnerability in all Microsoft operating systems (XP, Vista, 2000, and 2003), claims Amit Klein, the security researcher who published the original vulnerability description (PDF) earlier this month. According to Klein, the description in Microsoft's Secure Windows Initiative blog entry is misleading, contains disinformation about the DNS transaction ID algorithm, and downplays the severity of the issue. Klein refutes Microsoft's claim that there is no way to reproduce the next transaction ID, given a series of observed transaction IDs. He shows that this is possible in his paper, which Microsoft had before publishing the SWI post, as well as on the series of data provided in the SWI blog itself."

Comments

Re:Unlikely, but...

[Uncle Focker]

Or rather than spending all that effort in trying to downplay it, they could just fix the vulnerability and stop all the would-be attackers in their tracks. Nah, that would make too much sense.

Okay, I don't get the issue here.

[ThreeGigs]

Reading TFA and the details on the vulnerability, it seems to me that the attacker must first be able to sniff packets being sent to the DNS server from the desktop PC. This means the attacker apparently must have access to the network the desktop is on.

Now, forgive me if I'm missing the obvious, but why would an attacker, *who can read an outgoing request to a DNS server in real time*, not simply craft a reply using the outgoing packet data as a model? Why bother figuring out the transaction ID when an attacker, according to the scenarios given, *should already have it*, having gotten it from the sniffed packet.

I just don't see how being predictable makes this any worse, when you're apparently dealing with someone already on your own network, or on the route between you and your DNS server.

Re:Okay, I don't get the issue here.

[photon317]

Precisely. If the transaction IDs are secure, then you have to play "man in the middle" to sniff the request and fake a response. But if you can guess the transaction IDs, you can blindly send a spoofed response from elsewhere on the net and fake out the user's DNS resolver. The details of doing this in practice can be tricky, but it's doable. That's why the dnsext working group has been trying to improve this aspect of the protocol. While MS's implementation has flaws that make it more predictable than it otherwise should be, the fundamental problem is with the decades-old DNS protocol to begin with. The transaction IDs are 16-bit numbers, which is very limiting if you need to generate secure sequences of them that can't be guessed. It's not too hard to just spam responses with random response IDs and get some small success rate with only 16 bits to play with.

One of the current proposals (which I'm not a fan of because of other technical implications for DNS) is that since DNS query names are case-insensitive and copied by the server from the request packet to the response packet, to use the "uppercase bit" of each letter as more bits for the secure transaction ID. The fact that people are willing to consider hacks like these should tell you something about how badly we're backed into a corner on this issue with the DNS protocol. Hopefully soon someone will do something sensible like standardize an EDNS1 with extra transaction ID bits in the OPT RR, and then in like 10 years (if history is any guide) it might actually see wide deployment.

Why is this news?

[IchBinEinPenguin]

$DUDE finds vulnerability in $PRODUCT made by $VENDOR.
$DUDE claims this is really serious and should be fixed at once.
(optional) $DUDE does the Right Thing and tells $VENDOR about it so they can fix it before he goes public.
$VENDOR replies that $DUDE's claims are overblown.
Flamewar on /., lots of page hits, lots of add revenue, PROFIT!!
(optional, much later) $VENDOR quietly fixes $PRODUCT.

RTFA

[magamiako1]

Article Conclusion:

April 30th, 2007 - Microsoft Security Response Center (MSRC) were informed of this issue.

March 18th, 2008 - Microsoft releases a service pack for Windows Vista (Vista SP1), which includes a fix for this issue.

April 8th, 2008 - Microsoft issues a fix ([19]) for Windows Vista, Windows XP SP2, Windows 2003 and Windows 2000 SP4. The fix is downloadable at Microsoftâ(TM)s website. Simultaneously, Trusteer discloses the vulnerability to the public (in the form of this document).

Also, as stated above, the scenarios required to pull this off are pointless. If someone is sniffing your traffic in your switched network, they already have access to your network that could invoke far more problems than simple DNS poisoning.

Re:Unlikely, but...

[Divebus]

Is it possible that Microsoft was downplaying it to lessen the effects? Microsoft will certainly take security to the next level:
  "Are you sure you want to poison the DNS stub resolver cache? Allow or Deny."
That'll fix it.