Mogull, too, was critical of Apple's security process in general and this example in particular. "Apple's mostly gotten a pass on security issues," he said, "and as long as customers aren't getting beaten up, that's not been a problem. But that can change very quickly."
Mogull recommended that Apple work more closely with the open-source community responsible for code integrated in Mac OS X, such as the ISC's BIND, and urged the company to change how it handles security. "Apple does need to change its security practices. It makes a great operating system, but it's going to be much more of a target going forward."
Storms saw the bright side of Apple not patching the DSN bug, however, saying that it could be one of the few instances when the company's time-to-patch can be measured accurately. "Let's give them the best case, for them, and say that they didn't know until Microsoft patched on July 8," Storms said. "But now there's a vulnerability with exploit code freely available. How quickly is Apple going to respond a get a patch out?
"For most of the vulnerabilities it patches, it's difficult to tell what their internal [patch] release cycle looks like," he said. "This is the first chance we've had to gauge how quickly they can get their act together."
But this isn't the first time that Apple has been taken to task over how fast it updates the open-source parts in its OS. Last year, for example, Charlie Miller, a researcher at Baltimore-based Independent Security Evaluators (ISE) who is noted for his Mac and iPhone vulnerability research, called the company "negligent" for taking too long to patch. More recently, Miller slammed Apple for waiting until July to update the iPhone's built-in browser after Miller had exploited the same bug to hack a MacBook Air in March at a security conference contest.
"They do have a history of being slow to patch their open-source code," Mogull agreed.