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. All the major vendors, within a few days, had at least made a public statement about the issue. As for Apple, they have been characteristically quite, which never seems to work in their favor. The general counter argument has been that since OSX is not a widely popular recursive DNS server, they haven't been putting their users in too much jeopardy.
As things normally go with Apple, they sprang an update on us. Late in the day yesterday, we got security update 2008-005. This release includes an update for Bind (along with a good number of items worth reviewing).
Excerpt from the release notes:
*BIND
CVE-ID: CVE-2008-1447Available for: Mac OS X v10.4.11, Mac OS X Server v10.4.11, Mac OS X v10.5.4, Mac OS X Server v10.5.4
Impact: BIND is susceptible to DNS cache poisoning and may return forged information
Description: The Berkeley Internet Name Domain (BIND) server is distributed with Mac OS X, and is not enabled by default. When enabled, the BIND server provides translation between host names and IP addresses. A weakness in the DNS protocol may allow remote attackers to perform DNS cache poisoning attacks. As a result, systems that rely on the BIND server for DNS may receive forged information. This update addresses the issue by implementing source port randomization to improve resilience against cache poisoning attacks. For Mac OS X v10.4.11 systems, BIND is updated to version 9.3.5-P1. For Mac OS X v10.5.4 systems, BIND is updated to version 9.4.2-P1. Credit to Dan Kaminsky of IOActive for reporting this issue.
No Port Randomization
The current countermeasure to this DNS cache poisoning vulnerability is to introduce increased entropy by forcing randomization of the query ID and the source port. Essentially, making it all the more difficult to spoof the DNS response. However, it appears that Apple forgot something. The client libaries on my OSX 10.4.11 system, post patch install, still does not randomize the source port.
Here is a comparison between a patched FreeBSD 6.3 system and my OSX 10.4.11 system.
FreeBSD 6.3
08:49:58.405934 IP [BSD].64328 > [SERVER].domain: 39741+ A? www.yahoo.com. (34)08:50:02.708123 [BSD].51023 > [SERVER].domain: 45758+ A? www.yahooooo.com. (35)
08:50:07.625034 IP [BSD].50648 > [SERVER].domain: 23806+ A? www.www.net. (29)
OSX 10.4.11
08:05:47.741385 IP [OSX].49193 >[SERVER].domain: 55613+ A? www.cnn.com. (29)08:05:48.207547 IP [OSX].49194 >[SERVER].domain: 1106+ PTR? 21.91.236.64.in-addr.arpa. (43)
08:05:51.717245 IP [OSX].49195 >[SERVER].domain: 27650+ A? www.cnn.com. (29)
The Bottom Line
For Apple, it matters most that they patch the client libraries since there are so few OSX recursive servers in use. The bottom line is that despite this update, it appears that the client libraries still aren't patched.
Update:
Swa Frantzen, the SANS Handler on duty, discovered the same thing on OSX 10.5.4
Thanks to Gregg Keizer for covering this topic at ComputerWorld.
And Ryan Naraine also found this interesting enough to cover at the ZDnet Zero Day Blog.
Comments (2)
The issue is deeper than it may seem but may be less significant as well.
The problem is that Apple's resolver isn't much like anyone else's and is only related to BIND in that it replicates some of the API of the old BIND 8 and earlier libresolv and keeps the name. pushing out the patched version of BIND didn't do anything useful for most MacOS users, because the Apple resolver in conjunction with lookupd does all most people would ever need for DNS resolution. That resolver seems to set up a new socket and let the system pick a source port for each of its queries. The system picks such "ephemeral" ports in sequence, which is the traditional BSD way. This means that it is slightly better than using a caching resolver running unpatched BIND, since BIND traditionally has set up a resolver socket at startup and reused it for everything, making the source port static. The bottom line is that really fixing the sequential ports the right way means putting port randomization in under the socket API, and FreeBSD has already proven that task to be harder than it sounds. It seems likely that Apple is putting that off for a while.
Mitigating this is the combined effect of the source port not being constant and a typical system sending query packets to a trusted and logically nearby recursive caching resolver such as a nameserver on their LAN or at their ISP. The predictable port+tid problem demands some basis for prediction in the form of DNS query packets directly from the vulnerable client, but there's no way to get the MacOS resolver library to send a query to anyplace other than where it is configured to ask for resolution.
Posted by Bill Cole | August 1, 2008 3:50 PM
Posted on August 1, 2008 15:50
Andrew Storms, please see comments at:
http://www.palluxo.com/2008/08/02/apple-dns-cache-poisoning-patch-leaves-users-at-risk/
It seems that the problem is not with randomization.
Posted by Daniel Toljaga | August 3, 2008 3:29 PM
Posted on August 3, 2008 15:29