For the entire history of Mac OS X, Apple has had a grand time poking fun at Microsoft about a lot of things, but Cupertino has made a point of getting its licks in over Redmond's track record with security. The malware problem, the effortlessness with which Windows XP was attacked via Internet Explorer and other vectors -- oh, what a fun time Apple had.
However, through the Windows XP and Windows Server 2003 lifecycle, a funny thing happened. Microsoft really listened to the criticism, took it to heart, and started not just saying it took security seriously, but showing that it did. We can argue about how annoying some of the implementations have been, but the fact is, Microsoft learned. While the idea of a "patch Tuesday" may seem odd to a home user, for a network administrator, having advance notice of upcoming patches is a good thing.
But what about Apple? Well, on a very basic level, Apple got lucky. The flavors of BSD Unix have always had a good level of security, Unix itself is designed reasonably well from a security POV, and, up until Mac OS X 10.4, Mac OS X was not able to really handle high-end server roles. So, Apple's default stance of "We'll tell you what you need to know, when you need to know it, and you'll like it" wasn't a big deal. But it wasn't good. When you report a security issue, you want--no, you "need--open communication. Getting told "We're looking into it" or "It's already been reported", or worse, "Apple takes security seriously, but we don't comment about unreleased products" is... well, frustrating is the best word that I can use in a family publication.
A lot of people in my line of work had been predicting that, at some point, Apple's attitude towards security, and the company's opaque nature were going to eventually bite it in the keister--and hard. It was just a matter of when, but when it happened, it would put a severe hurt on the goodwill Mac OS X had created over the years.
Welcome to "when".
As reported by Rich Mogul and Glenn Fleishman in TidBits, (and hundreds of other sources around the Internet), security researcher Dan Kaminsky accidentally discovered a technique wherein an attacker could compromise DNS servers, (part of the essential functionality of the Internet), via what is known as Cache Poisoning. This technique allows an attacker to change, or "poison" the caches where DNS servers store the data that allow you to use "www.apple.com" to get to 188.8.131.52.
So let's say, you want to get an update to an application. You enter in the URL, i.e. "http://www.goodvendor.com/", and connect to that site to download the update. The problem is, the DNS server you use -- say, your ISP's or your own -- has had its cache 'poisoned', so while you explicitly typed in the proper URL, you end up at some other server; instead of downloading the correct, safe update, you download a trojan horse and install it, because you think it's safe. While attacks on DNS servers have been around for a while, this vulnerability made such attacks far easier to pull off than they previously had been.
This kind of attack makes most of the ways you detect phishing sites useless, because the URL will be the correct one, not some 'almost' correct URL. You'll just get re-routed to the wrong place. This is not theoretical either -- there are active exploits for this right now.
Considering that everyone using the Internet relies on DNS in a way that is the very definition of 'Mission Critical', this vulnerability and the relative ease with which it can be exploited, Kaminsky, and other people (like Paul Vixie, who helped create BIND, the software that pretty much every Unix-based OS uses for DNS) took immediate action. Kaminsky, Vixie, and others, including the United States Computer Emergency Response Team (CERT), privately notified all affected vendors, including Apple, by May 8; Apple was specifically notified on May 5. They then waited two months until July 8 to publicly notify the rest of the Internet community.
By July 8, guess who was the only OS vendor to not have patched their DNS? If you guessed 'Apple', you're sadly correct. To add to the frustration, inquires by quite a few Apple customers only brought the standard PR boilerplate.