On 22-May-08, the research unit of Core Security Technologies released the. Two of the vulnerabilities can crash a vulnerable system, while the third can potentially allow an attacker to take over your computer. Based on the communication notes in the official advisory from Core, it appears that Apple originally intended to release a patch before the vulnerability details were released, but the patch was delayed. In all three cases the vulnerabilities take advantage of the user opening specially crafted .ics calendar files.
The first two vulnerabilities are a class of bug known as a null-pointer dereference. Until very recently this type of flaw wasn't considered exploitable by an attacker, because it might crash your system or the running program but it couldn't allow someone to take over your computer. This changed in March 2008 when security researcher Mark Dowd used a null-pointer dereferencing bug in the Adobe Flash player to Apple Becomes First Victim in Hacking Contest," 2008-03-28). during the  (the same contest where Charlie Miller compromised a MacBook Air; see "
, and there is absolutely no indication it can be used with these iCal vulnerabilities. Core's own advisory states that they do not believe these vulnerabilities will do anything other than crash iCal if you open a malicious .ics file.
The third vulnerability is remotely exploitable by an attacker, but is a low risk due to the sequence of steps needed for it to run. You must first import the malicious calendar entry, then double-click it in iCal, then click Edit, then click the field to change the alarm. The exploit code will execute only if you click on the alarm field in Edit mode.
In all three cases, if the attacker inserts the malicious calendar entry into a calendar you subscribe to, it will automatically import into your system and could crash iCal (you still have to click the alarm in a malicious entry for the attacker to take over your system). These attacks haven't yet been seen in the wild, but Core's security advisory contains working proof-of-concept code from which a bad guy could easily build an attack.
This brings up a complex ethical issue about disclosure of security vulnerabilities. By releasing detailed information before Apple patched the flaws, Core places all Mac users at risk. On the other hand, as you can read in the Report Timeline of the advisory, Core worked with Apple to coordinate the release with the patch until communications seemed to break down at the last minute.
My personal opinion is that researchers should only release vulnerability details either after a patch is released, or if there is clear evidence the bad guys already know about the vulnerability and are exploiting it in the wild. However, some researchers disagree with my opinion and feel they should also release details if a vendor is unresponsive or doesn't patch within a reasonable time period. I used to share this opinion, but over time I've come to believe that the stakes have changed in the last 5 to 10 years, with exploits appearing within hours of vulnerability advisories. Releasing details before a patch helps the bad guys far more than users. All too often these situations become ego battles between the vendor and the researcher, with innocent users caught in the crossfire.
The good news is that in this particular case the overall risk to users is low. The two easiest vulnerabilities to exploit will only crash iCal, and only if you import a malicious .ics file or are subscribed to a compromised calendar. The third vulnerability is more serious, but unless you click on the alarm field in the malicious entry it can't run.
As usual, we advise you to follow safe computing practices. Be careful what you import into iCal, and make sure you keep your eyes open and update when Apple releases an update, which we expect soon. Your risk is low, and despite being unpatched, this vulnerability isn't keeping me up at night.
(Full disclosure: Core Security Technologies is currently a consulting client of mine.)