»

NSURLConnection Crashing Antidote

March 18th, 2008

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.

13 Responses to “NSURLConnection Crashing Antidote”

  1. Steve Streza Says:

    Nice. Glad this finally got fixed; I’ve been seeing it a lot.

  2. Ahruman Says:

    “May lead to arbitrary code execution” is a very broad description that applies to any sort of overrun or use of stale pointers. In the majority of cases, that’s a rather low-probability “may”, but once it’s reported not fixing it could be a big PR mess.

  3. Daniel Jalkut Says:

    Ahruman: Well I am just grateful that somebody inside Apple figured out that it had a potential for security vulnerability.

  4. Sengan Says:

    Thanks for reporting this, Daniel. I’ve seen it too.

  5. Dan Says:

    Nice. I routinely cruise security update notes looking for credit shouts from Apple and when I saw your name I took note. Oh so nerdy…

  6. Justin Says:

    This is great, and congrats! FWIW, there is still (to my knowledge) a crasher in Leopard, though, with NSURLConnection, that is related to HTTPS + auth, and I think a separate one involving HTTPS + auth + proxies. My bug report was marked as a dupe, though, and I can’t check on the status of the original. I know we talked about this before, but have you seen any issues with folks using HTTPS + MarsEdit? There have to be some folks out there using MarsEdit for secure sites behind password protection.

  7. Daniel Jalkut Says:

    I haven’t heard anything like that Justin, but I don’t think there are all that many people using HTTPS + Proxy and MarsEdit. I know some people using HTTPS without a proxy, and that doesn’t seem to be an issue.

  8. Conor Says:

    Congratulations, getting more famous everyday.

  9. Justin Says:

    Thanks for the feedback… FWIW, it is the combination of HTTPS, a proxy, and HTTP authentication using asynchronous NSURLConnection that does it, and not all the time. I’ll be sure to blog it up if/when I can get to the bottom of it.

  10. Paul McCann Says:

    I saw an occurrence of the 10.5 NSURLConnection problem this afternoon, when I attempted to get TextMate to update through an authenticating proxy server on a new machine I was setting up. At least I imagine it’s using https to get at the new versions. In any case Old Faithful spewed forth onto my shiny new screen…

    As per the 10.4 version of this problem, once the error kicks in it’s a difficult beast to get rid of.

  11. Paul D. Waite Says:

    And even if a bug has been reported, it might not have been reported well. A bug report that’s isolated the bug and provided clear steps to reproduce it can save a bunch of time on the developer’s end, reducing the cost of fixing it.

  12. John McLaughlin Says:

    It’s quite possible that the security aspects of this are as real as Apple outlined but here is what it sounds like to me:

    Someone at Apple was embarassed about the problem (or generally agrees that it’s unacceptable to have a problem like this exist) and wanted to fix it. However his boss said “Security fixes only” so voila — this becomes a ‘security problem’ (which means ‘it can now be fixed’)

    I see this at my work all the time — Management decides how/what they want to do but individuals who care deeply see what *needs* to be done and they figure out a way to make it work within the system.

  13. Dave MacLachlan Says:

    For folks trying to get NSURLConnection bugs to appear, I have had great luck with the _debug frameworks causing bugs in NSURLConnection to appear (https://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/getSoftware?bundleID=19915). You have to be an ADC member. Unfortunately I think we will need a new one with Daniel’s fix in it to be sure we’re not seeing his bug. I will file a Radar. Justin, this may help you out though.

Comments are Closed.

Follow the Conversation

Stay up-to-date by subscribing to the Comments RSS Feed for this entry.