Apple’s DNS Cache Poisoning Patch Leaves Users at Risk
August 2, 2008
(Correction) Apple said they patched one of the most serious security threats to their Mac OS X Server with July 31 update dubbed Security Update 2008-005. But, Andrew Storms, who works as a director of security operations at NCircle Proactive Network Security warns that the DNS client on the Mac OS X 10.4.11 distribution still remains unpatched.
DNS cache poisoning is a maliciously created or unintended situation that provides data to a Domain Name Server that did not originate from authoritative DNS sources.
This can happen through improper software design, misconfiguration of name servers and maliciously designed scenarios exploiting the traditionally open-architecture of the DNS system. Once a DNS server has received such non-authentic data, and once it caches it for future performance increase, it is considered poisoned, supplying the non-authentic data to the clients of the server.
Apple finally released the DNS flaw patch late on July 31, patching a critical DNS cache poisoning vulnerability that other companies began fixing on July 8. In his latest blog post, Andrew Storms maintains that despite Apple’s update, security patch still fails to randomize and it appears that the client libraries still aren’t patched.
“Did Apple forget to patch something? By the look of things, the DNS client on the OSX 10.4.11 distribution still has not been patched. A lot of people, including myself, have been prodding Apple on why they are so late to the table on this DNS patch.”
He explains that Apple was supposed to introduce “increased entropy by forcing randomization of the query ID and the source port” as a countermeasure to the DNS cache poisoning vulnerability. “However, it appears that Apple forgot something. The client libraries on my OSX 10.4.11 system, post patch install, still does not randomize the source port.”
The “client libraries” Andrew Storms tests and complains about is the DNS resolver. The resolver is the piece of the OS that queries BIND. It seems pretty clear Storms only tested the resolver on Mac OS X, when the resolver isn’t the issue. Yes, it would be great if all communications used randomized ports, including RESOLV, but BIND is the focus of the security advisories. BIND is where the cache poisoning can occur. BIND then passes the bad data along to RESOLV, and it doesn’t matter if RESOLV used a randomized source port or not. Considering Storms’ confusion about the issue, it’s not even clear that he tested RESOLV on the BSD system.
Another IT analyst, Paul Rubens, recently slammed Apple for not having enough “manpower” to deal with Mac OS X Server issues. “Microsoft is huge, and it is quite capable of doing more than one thing at a time. During the past two years, it worked on Vista, Windows Server 2008, the Hyper-V virtualization system and the Zune — all at the very same time. The same cannot be said for Apple… But would I put an Apple Server in my business? Not a chance, ” - he cautioned.
Do you not know the difference between the client and server version of Mac OS X? The server version, which is mentioned in your title, was successfully patched, so your title is wrong. The client version does not have the DNS program “bind” active–unless the user is a geek and chose to activate it. It is this client version that apparently was not patched. This could be a potential problem if bind on a client installation utilized an unpatched DNS server elsewhere, but authoritative DNS servers are supposed to be patched by now, aren’t they?
Editorial Team’s Response to ‘Dog:’ Maybe you should read article more carefully? True, Apple patched one of the most serious security threats to their Mac OS X Server on July 31, but Apple’s security patch still fails to randomize, leaving Mac users at risk. Therefore, the title of the article is 100% accurate as it conveys security analyst’s findings. Thank you for responding. - Editorial Team
As your article itself states, this vulnerability no longer affects servers, so your title is incorrect and misleading.
So the basic argument here is that the most recent version of the PREVIOUS system hasn’t been patched? Hmmm where are the fixes for Windows 95 and ME?
Paul Rubens’ article was very typical of the UK’s tech obsession against Apple. Look at the coverage of anything Apple on the The Register for a start - unless inserted by editor Tony Smith. He made some interesting points but obscured them by claiming that Apple was a toy maker. It is symptomatic of people who are beginning to find their field of expertise being encroached upon to damn with feint praise - which is kind of what Rubens did with his “Apple only make nice toys” argument.
The point being is that Apple have trodden on people’s toes. In all fields. Not just Microsoft - who this week proved they were so rattled by their competitors to mention them by name in a company rallying email by Ballmer - but all the mobile companies and their ilk.
Apple almost, just almost, broke the telecom monopoly up last year by making people BUY the phone and then get a decent service - unfortunately this year they have reverted to the subsidized handset model - but hey.
The DNS issue is bad and has been badly handled by Apple - but it is not the end of the world. It will be fixed.
If someone so clearly disqualifies themselves from unbiased discussion the way Paul Rubens did to himself directly in the included quote, their caution is obviously best taken with a huge grain of salt.
If the ability to produce products in multiple distinct product markets — and achieve success in them — is some sort of defining criteria for a reliable software company (which is not a point I would grant), failing to recognize that Apple not only participates in but achieves success ranging from influential to outright dominance across multiple distinct markets is a pretty big gaffe.
@Editorial Team:
With a little more investigation, it appears you (and Andrew Storms) are confusing the DNS server application “bind” with the DNS resolver facility (or “DNS client”) which runs on both clients and servers. The security threat is with bind, which runs on DNS servers. Yes, any network communication would likely be more secure with randomized source ports, but that is not the issue. The security hole that manufacturers have been patching is in the source ports used by bind only, which runs on servers, not on clients.
From my own testing, when it’s activated, the bind application on a patched Mac OS X 10.5.4 client system passes the randomized port test at:
http://www.provos.org/index.php?/pages/dnstest.html#
So what’s the problem? Do you even know the problem? Is that why Andrew Storms asks the question, “Did Apple forget something?” rather than saying anything concrete? Well, the answer to you and Andrew Storms is, “No, Apple didn’t forget anything.” Both postings are inaccurate.
Hi ‘Dog.’ (Neil?). Thank you for pointing this problem to us. We’ve made corrections. In our upcoming article, we’ll mention your testing results. Please check your e-mail, I sent you some info. Thanks!
Yes, this guy only tested the resolvers and only claimed to have done so. If you take issue with the resolvers not needing to be patched, then you should go read the CVE as it clearly states that clients (aka stubs) are also at risk:
“Stub resolvers are also vulnerable to these attacks, so system administrators should patch stub resolvers that issue queries in response to attacker behavior and that may receive packets from an attacker. Administrators should watch for patches to client operating systems that implement port randomization in the stub resolver. ”
and you know what, even HDMoore predicted his public exploit could be tailored for clients.
Is the mac at serious risk, maybe not…but the data he showed is correct.
it actually is not clear that port randomization makes a significant difference for a stub resolver, since a stub resolver only ever talks to its configured forwarder(s) and that severely narrows the audience for its non-random query ports. The key difference in a recursive nameserver is that by telling one of its clients to resolve a name, an attacker can make the server send queries to a target of the attacker’s choice, thereby gathering data about that server’s queries that make it possible to predict enough about normal queries to allow the attacker to fake answers to questions which that nameserver asks of others. For the stub resolvers like Apple’s or the one in glibc (which has the same issue) it is not possible to make the resolver send queries anyplace but where /etc/resolv.conf tells it to, so the sequential port numbers on queries is harmless. The attacker does not know where in the 16k ephemeral port range the resolver is at any time, so the port might as well be random.
Also note: if the attacker can see the DNS query packet that he wants to spoof an answer to, port randomization is worthless anyway. Given how stub resolvers work, seeing enough query packets to know that the stub is using sequential ports is likely to equate to access to all of its queries, and that makes guessing unnecessary.
Andrew Storms is not crying wolf. If you understand the details of the bug, it’s clear.
Furthermore, the bug is not (just) in bind. If it was in bind, then why was Microsoft hosting the emergency meeting where the world’s top people in DNS got toghether? It was in many products, not just bind. Listen to Kaminski’s talk. (He’s the guy that discovered the flaw). Kaminsky says problem exists on regular clients too. Resolvers need to be fixed too. As Kaminsky explains, the clients are a major problem; they’re just not as “your jugular vein has been cut and you’ll bleed out in 30 seconds” big a problem as the servers.
There are OS X servers I’ve set up that are both authoritative and (using split DNS) recursive; I’m very concerned. I’m glad where I (long ago) took the extra precautions to make the servers hidden masters, and to disable recursion from external IPs, but I’m still angry with Apple for leaving these systems extremely vulnerable for weeks, even with these precautions I’d taken. The lack of full randomization is also still of great concern to me. This : http://isc.sans.org/diary.html?storyid=4810 is maddening!