Slashdot Mirror
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."
Don't you just love it when they do that? Is there a strong enough term for those that go so completely out of their way to ignore facts and reality that it defies belief and leaves the sensible stunned? (reminds me of the Chewbacca Defense in a way)
I work for the Department of Redundancy Department.
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.
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.
Things are bad when trolls have to troll themselves simply because nobody will feed them...
Anonymous Coward
"gnutoo" is a sockpuppet of well-known troll twitter. He has already posted on this article with four different accounts. Please do not reward this type of behavior - the more karma an account has, the more trolling damage it can do.
I in the past have implemented DNS resolver libraries since UNIX has classically had a terrible problem of either providing only a non-reentrant gethostbyname() or a flaky (blocking) gethostbyname_r() function. In fact, for years programmers have suffered through terrible client side host resolution libraries since it blocking DNS calls were never considered poor taste before programs like web browsers needed to look up entries while rendering.
Also, since POSIX is entirely unaware of the GUI API, there has never been a good method of communicating events to the application. Ideally, there would have been a system related to select() or poll() which would have allowed host name resolution to be part of the same application loop as other socket communication.
That being said, Windows has more or less always include host name resolution as part of the application event loop. Even back when Winsock 1.1 was primarily used. When the host name is resolved, an event is passed to the application. But it is not my intention to discuss DNS from an application level, but instead from a protocol level.
This hack that the reported document is definately a hole in Windows DNS client implementation, Microsoft should fix it, they should treat any vulnerability with respect and diligence. This hack however requires a lot of things to happen at once.
First of all, it requires that the attacker is in a position where they can reliably observe point to point DNS traffic. Meaning from the workstation to the server and back. When used with switches and dslams, this is not generally possible since unless the switch has a defined observer port (which HP procurve allows, but disables by default) traffic is closed and only broadcast requests will be observable outside the point to point path.
Second, it requires that the attacker is located in a position on the network where they can respond to DNS requests faster than the server. So, if the edge switch they're connected to puts them physically closer to the target, but the switch has a higher speed uplink to the backbone, there's still little chance the attacker will inject their packets in time.
Third, it requires making the machine which is being attacked to perform multiple DNS queries. If the attacker gets lucky (another if) the user will be setup for proxy server auto discover which was typically true in earlier versions of IE. Then using a broadcast type situation, they'd be able to configure a proxy server which would inject web pages to the clients computer containing multiple DNS entries. Unfortunately, this would remove the need to perform DNS lookups and they'd have to shut off the proxy and hope the browser falls back to proxyless operation mode.
Finally, it would require that his math for calculating the next DNS event id, source port, etc... is sound. I haven't checked the math, nor am I inclined to since even if we assume he's 100% correct, requiring it to rain at an angle of 32degs precisely at 12:05.2334 UTC on April the 19th of 2009 while Christopher Columbus rises from his grave to baptise the next baby Jesus is just irrational.
Hackers, save yourself some time, if you have this kind of access to the network, use a keylogger, much higher chance of success and much easier. Just remember to not hide under the desk of the computer you're trying to log.
This is old news, with a new twist.
1) It was discovered as the cache-poisioning problem.
2) It Affects MS DNS clients, and IIs Server. ( Clients for their poisoning effects, and IIs Servers for the actual poisioning.
3) You can fix ANY client by pointing to OpenDNS, ( I have had extensive corrspondance with their technical team. )
4) Microsoft was suppoed to fix this for All the Clients and servers, they backed off and said it was only for Server 2003, and Vista....
then only for Vista SP1, then... didnt make Vista SP1...
Its all based upon a POOR choice of random number generator, and It looks like it may not make it into XP SP3 either.
Perhaps... Vista SP2...