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-1447

Available 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.

Many Patches Get Replaced

When it comes to Microsoft Patch Tuesday, August might just be better classified as a do-over. Of the 11 bulletins released today, 7 of them replace former bulletins. The bulletins being replaced are an interesting diversion in their own right. One dates back to 2003 while others were just released in the past few months. In one case, MS08-026 a remote execution in Word, has now been superceded by three new bulletins this month.

08-041 replaces 03-038
08-042 replaces 08-026
08-043 replaces 08-026 and 08-14
08-044 replaces 06-039
08-045 replaces 08-031
08-048 replaces 07-056
08-051 replaces 06-058 and 08-026

Is this a case of bad patch or new vulnerability? In all likelihood, the replacements signify a bit of both. A common tactic for any researcher is a history lesson in what you are investigating. By focusing your microscopes on older patches, 2 sets of clues are generally reveled - where code changed and what kind of changes occurred. The 'where' and the 'what' of any code base tells a lot. Where code was altered gives a researcher clues as to important locations for further inspection. Similarly, the 'what' tells a researcher what kind of functions or routines have been problematic in the past and might prove to be troublesome again. Chances are we are seeing additional fixes for past vulnerabilities as well as new flaws found by means of these history lessons.

Kill Bits Galore

Security advisory 953839 was also published today. The intent on this cumulative security update is to issue new kill bits for known vulnerable controls. A kill bit is a value in the registry, which instructs your computer not to execute the control if it is requested. This does not remove or update the vulnerable code, it just simply tells your computer not to run it. In today's update, we received roughly 90 kill bits on class identifies related to products by Aurigma and another 20+ on products from HP.

This is not the first time that Microsoft has utilized patch Tuesday to distribute kill bit settings from third party applications. While this method may be viewed as novel now, it will soon become relentless and tiresome as time moves forward. The reason is partly based on what we learned from Microsoft at last week's BlackHat talk. Microsoft announced their new security initiatives, one of these being their active efforts to deliver a holistic more secure system to Windows users, even if it means finding bugs in 3rd party products. Going forward, we can expect Microsoft to find vulnerable ActiveX controls and issue kill bit updates on patch Tuesday, thus making Windows generally more secure and providing the 3rd party vendor time to release proper updates for their software.

No surprise - we have more Apple iPhone security flaws

This time there is a security hole that bypasses access restrictions and it highlights again that Apple favors functionality over security. In this case, even when a user chooses to physically secure the device with a four digit passcode, the user still has access to some functionality. If someone selects "emergency call", that user can then gain access to other options that eventually provide almost complete access to the phone, without ever having to enter a passcode.

This highlights a fundamental design deficiency with the iPhone, and flies in the face of Steve Jobs' declarations about iPhone security. Even with some of the recent improvements in security, Apple internal decision making process always chooses functionality and aesthetics over security. The most recent demonstration of this internal bias is the quick release of updates to fix 3G connectivity issues this year, but security updates generally take several months.

I don't think this is an acceptable level of risk for most enterprises, and it's probably too much risk for many consumers. Until Apple begins to publicly address the fundamental design, development and process issues that move security to the back burner, enterprises will be forced to remain skeptical about the iPhone and will have to worry about the protection of confidential data on the device.