A couple months ago I reported on a particularly nasty, crashing bug in NSURLConnection. What was particularly nasty about it was how widespread it was. I had received dozens of crash reports, all containing the same tell-tale sign of a problem in this part of the system.
After getting tired of explaining again and again to customers that the bug was in Apple’s code and the best we could do was hope for a fix, I realized that maybe it was worth me writing up the bug and reporting it to Apple. I supposed maybe, even though this bug’s crash log shows up as fairly common in Google, nobody has bothered to report it yet. So I wrote the aforementioned blog post and reported a bug.
Since the issue only affects 10.4.11 users, I figured the chances of a fix might be slim. Apple naturally is most concerned with the latest releases of 10.5, although they continue to issue security fixes to protect users on 10.4.11. But this was just an extremely annoying crash, not a security vulnerability, as far as I knew.
After writing the blog post I started to hear from other developers that the crash logs were extremely common for them, too. One developer mentioned that he had no less than 100 separate crash reports in his logs, from users afflicted by the problem. Users reported that it affected them while using Safari, MarsEdit, essentially any application that uses Cocoa to access resources from the web.
It sucked, man! But would it ever be fixed? Well, I have to confess that my expectation for a fix went up when Apple contacted me a few weeks ago to ask me how I would like to be credited in a forthcoming security update. How interesting! I had not reported any bug recently which I thought had security implications. I immediately became hopeful that it would be have something to do with this nasty epidemic of a bug.
Today, Apple released Security Update 2008-002, whose release notes include the following note:
Description: A thread race condition exists in NSURLConnection’s cache management, which can cause a deallocated object to receive messages. Triggering this issue may lead to a denial of service, or arbitrary code execution with the privileges of Safari or another program using NSURLConnection. This update addresses the issue by removing an unsynchronized caching operation. This issue does not affect systems running Mac OS X v10.5 or later. Credit to Daniel Jalkut of Red Sweater Software for reporting this issue.
Everything about this description sounds like the bug I reported, except that I didn’t realize it could possibly be used to exploit the security of a system. I guess this is one of those situations where it’s lucky there was as security flaw, because without it, I don’t know if it would have ever been addressed.
Now users are not only protected from this strange security vulnerability, but perhaps more significantly, protected from the repeated frustration of crashing in their network enabled applications!
The moral of the story for other developers (and users, too): always report bugs, even if they seem so widespread as to have been “surely reported.” It turns out that my frustrated effort to bring attention to this problem might have been what Apple needed in order to spot the security flaw and ultimately decide to fix it.
Many, many thanks to Apple for fixing this problem! Of course, I am putting a lot of faith in this actually meaning it’s fixed, but it sure sounds like it is. Time will tell if the “willCacheResponse” crash logs stop trickling in.
