Why did Apple take so long to fix Darwin Nuke vulnerability?

happygeek 0 Tallied Votes 510 Views Share

According to a SecureList posting dated April 10th, researchers Anton Ivanov, Andrey Khudyakov, Maxim Zhuravlev and Andrey Rubin discovered a vulnerability in the Darwin kernel back in December 2014. Why is this of interest? Well, the Darwin kernel is an open source part of both the Apple operating systems. The vulnerability could allow remote attackers to launch a DDoS on a device running OS X 10.10 or iOS 8. More worryingly, it could allow the attackers to send just a single, solitary incorrect network packet in order to crash the target system and impact upon any corporate network it may be connected to. Sounds pretty serious right? Apple obviously thought so, seeing as it took the company which is so profitable that it ranks in the top three companies on the planet more than three months to fix it. The updated OS X 10.10.3 and iOS 8.3 software releases patched the holes, but even so, three months plus!!!

This is actually something of a big deal if you ask me, and not untypical of Apple which has stood accused of taking far too long to fix vulnerabilities in the past. Yes, I appreciate that it's better to get things right than rush out fixes that break something else or don't do the job properly. However, and it's one mega however if you ask me, while a small to medium sized organisation might be forgiven for taking a while to patch code with limited resources to throw at the problem, Apple is not a small or medium sized organisation. Apple is fecking huge, one of the biggest mega-corps on the planet with money gushing out of the wazoo. If Apple wanted to fix something quickly, then Apple could fix something quickly, without cutting corners.

The Kaspersky Lab researchers which analyzed the vulnerability reckon it affected devices with 64-bit processors and iOS 8 including iPhone 5s, iPhone 6, iPhone 6 Plus, iPad Air, iPad Air 2, iPad mini 2, and iPad mini 3 as well as the OS X 10.10 hardware of course. That's a pretty broad sweep and, I repeat, a pretty big deal. A Kaspersky spokesperson explains that the vulnerability is exploited while processing an IP packet of specific size and with invalid IP options. After processing the invalid network packet, the system will crash. OK,. there are some caveats here such as the system only crashing if the IP packet meets the following conditions: size of the IP header should be 60 bytes, size of the IP payload should be less than or equal to 65 bytes, IP options should be incorrect (invalid option size, class, etc.). You may think that makes it less than a pretty big deal, after all surely that's a lot of specifics to match? Well, not really. If researchers could uncover "several combinations of incorrect IP options that are able to pass through the Internet routers" then cybercriminals and hacktivists are just as capable of doing so.

I'm not an anti-Apple ranter, so please don't lay that one on me, but I do think that a three month (nearer four in actual fact) time scale for patching such vulnerabilities is simply ludicrous. If Apple really take security as seriously as it likes to say it does, then it needs to walk the walk as well as talk the talk. And this wasn't walking, this was crawling through treacle while wearing flippers...

Dani AI

Generated

Short answer: the public timeline looked long, but several non‑sexy engineering and disclosure reasons usually explain multi‑week/month responses. ’s frustration is understandable; ’s request for comparative patching guidance is the right practical follow‑up. Apple’s public stance is to investigate and coordinate before confirming or publishing details, which is part of why fixes sometimes take time. (security.apple.com)

Kernel bugs in particular are expensive to fix safely. Reproducing a kernel crash, producing a minimal fix that doesn’t open other holes, backporting that fix to multiple supported trees, and running broad regression and performance tests across CPU families, drivers and firmware all add calendar time; even large teams can’t shortcut that without risking widespread breakage. See discussion of kernel testing and release stabilization. (lwn.net)

There’s also the coordinated‑disclosure reality: many researchers and vendors follow formal timelines and ask for confidentiality while a patch is prepared and validated. Government and industry guidance codify these expectations (and recommended timeframes), so a visible delay can be a consequence of responsible coordination rather than negligence. (cisa.gov)

Practical takeaways for anyone managing Macs, iPhones or mixed networks: (1) treat vendor advisories as authoritative and apply critical fixes promptly; (2) use compensating controls and isolation if immediate patching isn’t possible; (3) adopt a repeatable patch program — NIST’s enterprise patch guidance is a solid starting point for cross‑platform workflows. Those steps will reduce exposure when any vendor (not just Apple) needs extra time to ship a safe kernel fix. ()

ChaoticCoder 0 Newbie Poster
Good question. I've been looking for some good comparative research on OS patching/security. Additionally, a solid resource for managing patching of small networks with all of the different OSs. (WIN7/8, MINT, iOS, and OSX).
http://www.digitaltrends.com/computing/decrypt-os-security-showdown/
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.