Questions Mount On Apple Security Issues
1:00 am, August 4th, 2008, Lonnie Lazar
Amid growing criticism of a lassiez-faire approach to security issues, Apple has canceled participation in a public discussion of its security practices at the Black Hat security conference scheduled this week in Las Vegas. Black Hat Director Jeff Moss told reporters in an interview Friday that unnamed members of Apple’s engineering team had agreed in early July to participate in a panel discussion on computer security issues, which would have been a first for the notoriously secretive company. “It was [going to be] them talking about security engineering and how they take security seriously,” Moss said, but “marketing got wind of it, and nobody at Apple is ever allowed to speak publicly about anything without marketing approval.”
In a separate security-related development, reports indicate the DNS security patch released by Apple on Friday may fail to fix the exploit flaw it was intended to repair.
Andrew Storms, director of security operations at nCircle Network Security Inc. and Swa Frantzen of the SANS Institute’s Internet Storm Center both detailed research indicating systems running the client version of Mac OS X were still incrementing ports, not randomizing them, as should have been the case if the fix had addressed the flaw. “Apple might have fixed some of the more important parts for servers, but is far from done yet, as all the clients linked against a DNS client library still need to get the work-around for the protocol weakness,” Frantzen said.
While Dan Kaminsky, the researcher who uncovered the DNS flaw in February and helped coordinate a multivendor patch effort indicated “if there was a huge population of people behind DNS servers running OS X, I’d be more worried,” Rich Mogull, an independent security consultant and former Gartner Inc. analyst said, “It may be a low priority in the scheme of the DNS vulnerability, but if all my servers are OS X, it matters. Within the Mac audience, it matters.”
Via Computerworld
Posted by Lonnie Lazar in Apple, Macintosh, News | Comment on this article
If you enjoyed this article:
Subscribe via RSS or email, or follow us on Facebook and Twitter
http://seattlepi.nwsource.com/local/373426_insecure04.html
This article provides a lot more insight into what happened, and just how close we came to the end of the world as we kn ow it. Read what happened, then let it sink in- it takes a minute to get the full implications
Meet the Internet’s superhero
After discovering a design flaw that left the Internet vulnerable to ciminal attacks, Dan Kaminsky of Seattle and 15 other computer geniuses set out in secret to fix the problem.
Anne Taylor, on August 4th, 2008 at 1:26 am
>lassiez-faire
Laissez-faire
bob august, on August 4th, 2008 at 5:31 am
Too bad they’re not at Black Hat.
Partners in Grime, on August 4th, 2008 at 7:39 am
It’s important to understand the mitigating factors to the “gotchas” by Andrew Storms and SANS. These can be found in comments by Bill Cole on Storms’s blog
http://blog.ncircle.com/blogs/sync/archives/2008/08/apple_dns_patch_fails_to_rando.html#comment-21389
and at Tidbits, by Glenn Fleischman
http://db.tidbits.com/article/9721
In short, while Apple should fix the problem in the domain name resolver used by Mac OS X as a DNS client, the actual risk is speculative. It would require an attacker to induce a client to initiate a DNS request–not nearly as easy as it is to get a recursive DNS server to make a query. The client would have to make at least one request directly to a host controlled by the attacker–difficult in light of the fact that clients send queries to the DNS servers that are assigned via DHCP (or manually).
Not stated outright in the above links, but I also believe that clients sitting behind network firewalls would be largely protected since spoofed UDP responses would be blocked by the firewall.
A far greater concern to clients on all OSes is that if your recursive DNS server is sitting behind a NAT, the latter may be rewriting the outbound ports for DNS lookups, effectively reintroducing the vulnerability regardless of the server’s patch status. This is described at
http://blog.ghostinthemachines.com/?p=48
Elliot Wilen, on August 4th, 2008 at 12:10 pm