I will remind people again that the issue lays within upstream libraries such as libxml and have the potential to affect not just Apple (although everyone loves to target a single brand), but other operating systems and software, remember to keep your software up to date across the board.
The only XML-related bug I see in this group is the SceneKit Collada one; and as far as I'm aware, it's not the XML parser which fails in this case, it's SceneKit itself. All of these bugs are the sole responsibility of Apple Inc.
Did you even read any of these advisories before saying Apple didn't do it?
"I will remind people again that the issue lays within upstream libraries such as libxml and have the potential to affect not just Apple" < right here, where you said somebody else did it. These issues do not exist in upstream libraries.
I was about to post that these exploits should be substantially mitigated by iOS sandboxing (you can get arbitrary code execution, but can't get out of the exploited process's sandbox without a second exploit), but then saw CVE-2016-4627 [1] also in the 9.3.3 release notes, which is a local privilege escalation exploit that allows arbitrary code execution with kernel privileges.
There's not a ton of detail out there on the second exploit, so I'm not sure whether or not they can actually be paired to gain kernel privileges remotely. Still, more than enough reason to take these issues seriously and make sure you upgrade in a timely manner.
If you run an older version of OS X, does Apple supply security updates? How far back?
I run Mountain Lion (OS X 10.8.5) on one of my systems. For the longest time, whenever I click "Software Update", it says that there are no updates (though it does offer OS X El Capitan as an upgrade).
I can understand that Apple or any company doesn't want to support old software indefinitely, but if security updates are available as separate packages--without having to do a major OS upgrade--then you'd think that "Software Update" should offer it!
This is blatantly false. Apple has always provided security fixes for the past 2–3 versions before the current one. At their current version release schedule, that means a given version will be supported for at least 3 years or so.
At the moment security updates cover versions 10.9+. The most recent security update for OS X v10.8.5 was in August (a bit over 3 years after the initial release of 10.8), and 10.9+ have had an additional 5 security updates after that.
PDF is more or less an image format, and certainly in this context it serves the exact same purpose: visit web site, get served a file which exploits the browser and performs the jailbreak.
> Still can't believe the fact that they let people walk away with a subsidised phone
Did they ? The cheapest one was $599 initially. I don't feel that's the price of a subsidized phone. After a few months the price was dropped by $200, but that was to accelerate sales and capture a bigger market share.
Their pricing & sales model was unconventional, both for AT&T as well as customers, because the device was unique in so many ways back then.
I'm lost. Between the parentheses it says one has paid "full price", and therefore unsubsidized (or so I would assume if I paid the full retail price for a phone).
Since nobody else has said it yet, it looks like most, if not all, of these vulnerabilities would not have happened were the libraries written in Rust.
Indeed. There's a whole universe of logic bugs that lead to serious exploits.
Memory safety is nice, but I wish Rust evangelists would 1) stop acting like it's a panacea, and 2) acknowledge that Rust isn't really fully baked yet. I have various complaints about the language and standard library, but the real show-stopper is this: https://github.com/rust-lang/libc/issues/290
Yeah, they are pretty smug about it. The problem is that nothing short of perfect developers will completely stop errors but seeing how we see major memory safety exploits in C at least a few times a year for the past couple decades it might be time to start considering come sort of solution, whether it is Rust or otherwise.
Or any memory safe language. Heck, you could implement image decoding by doing an RPC to a sandbox with a shared memory segment that decoded the image to a device bitmap using Java or C# or JavaScript or pretty much anything.
Java specifically doesn't have this issue because its image decoders (except for JPG) are written in Java itself.
So whilst for the types of library that Apple OS' use, rewrites in Rust would avoid any odd IPC issues and be the most obvious drop-in replacement, you would pay the cost of rewriting the libraries as I guess there are no mature Collada or OpenEXR libraries in Rust. I do see a TIFF library though it says it doesn't support interlaced images.
So what does that have to do with the claim that (safe) Rust would help prevent a large class of vulnerabilities encountered in the wild? It's like saying you shouldn't bother with windows that provide better thermal insulation in your house because "some heat will always get through".
Some people do wrongly act like Rust will solve all security issues forever, but the OP did not.
Security is everyone's problem.