Again buffer overflow in image decoding. Would think apple might just #threatmodel and #fuzz that to death... but you would be wrong. 2.7T market cap company can't do this...
They do, but some of these bugs are beyond what fuzzing can do. We don’t know that this is a buffer overflow or how complex the exploit chain was - the one linked above was anything but something you’d get by fuzzing.
I agree it is disappointing that this stuff isn’t all Rust or Swift yet but that’s in process. Of particular interest, did you notice how the new Lockdown mode is apparently a countermeasure? I would not be surprised to see some of those motivations expand into the base OS as they have time to improve.
Can't you trigger this by fuzzing? Sure, the JBIG VM won't be, but some random fuzzing should easily trigger out of bounds reads or writes.
Lockdown mode alters the iMessage user flow to such an extent that I don't see Apple enabling it by default. I don't think Lockdown prevents the RCE exploit, but I do think it simply blocks iMessage interactions from unknown numbers, so that the exploit can't even load.
The older one? Probably but I think the way it combined multiple overflows would have required a fairly advanced fuzzer, especially to look exploitable. The main point I had was that while fuzzing would have found interesting ways to crash ImageIO with PDFs, most people wouldn’t have expected that to be reachable without a click from iMessage. The relevant teams could have been rewriting everything they care about in Rust and this still would have happened because it was an obsolete usage of a format they don’t even use but which could be pulled in by the old GIF preview path.
I agree that most Lockdown mode features won’t be pulled in but looking at that list, note how many stop a NSO zero-click by adding a “have you ever interacted with this person?” filter to iMessage, FaceTime, HomeKit, etc. That makes me wonder whether a more polished UI might be acceptable to normal users where new numbers are basically text-only with warnings.
While not discounting the need to increase investment in this area, I will mention that there are very few things that can be solved by #buzzwords and #hashtags.
Apple has a long history of investing in all kinds of mitigations and security devices that make the App Store model secure and an equally long history of procrastinating on what is again and again and again causing their customers to be exploited.
A while ago I was surprised to learn that MS Internet Explorer had team of about 10 developers (I expected more) when MS already had more than 50000 employees total. Now knowing a bit more how sausages are made I would not be surprised to learn that this particular image decoder was maintained in Apple by a couple developers. To some extent this can be seen in corporations too: https://xkcd.com/2347/
If that. This weekend I ran into a TIFF decoding issue (Canon scanner produces TIFFs with embedded JPEG compression with different parameters than the outer TIFF container). This is an issue with libtiff and affects any Mac or iOS app using CoreGraphics, anything using ImagMagick, etc. GIMP, Nikon NX Viewer, and others with their own TIFF implementations are unaffected.
I doubt anyone at Apple cares. If a CVE is filed for libtiff, they’ll rebase, but I doubt they are actively fuzzing it or even have regression tests for it.
Coverage-guided fuzzing is extremely powerful and has proven to be very effective at finding oodles of vulns. But it is not perfect. You'll fail to drive the code to a bug or run into limitations of the sanitizers to actually detect a vuln.
You can stand up fuzz targets at all of the relevant endpoints and throw tons of compute at it and still fail to find lots of things. The problem is unsafe languages. Apple is taking steps to get things moved to swift, but it is slow going.
There was no fuzzing for this exploit lmao they developed a rudimentary assembly language inside the hacked pdf encoder by meticulously choosing the exact 70,000 pixel maps that overwrote the write pointers. And that's after they got the overflow exploit giving them control of the encoder/emulator.
Sure, but “internal bounties have fundamental problems of incentives at any scale” is a different problem than “Apple can't afford internal bounties on an adequate scale to compete with nation-state attackers”.
Unit 8200 is single largest Israeli military unit, their entire tech industry is filled with 82xx, 81xx and 99xx alumni.
This is what happens when you have universal conscription and the intelligence corps get their pick of the brightest conscripts.
It still doesn’t make them a state actor anymore than the dozen or so European malware vendors and the probably far more numerous US ones and that is before looking into the defense sector proper.
> NSO Group is a subsidiary of the Q Cyber Technologies group of companies.[7] Q Cyber Technologies is the name the NSO Group uses in Israel, but the company goes by OSY Technologies in Luxembourg, and in North America, a subsidiary formerly known as Westbridge. It has operated through various other companies around the world.[18]
