Apple Updates Block Zero-Day Malicious Image Exploit
Apple has released a set of emergency security updates, including iOS 18.6.2 and iPadOS 18.6.2, iPadOS 17.7.10, macOS 15.6.1 Sequoia, macOS 14.7.8 Sonoma, and macOS 13.7.8 Ventura. The updates address a critical vulnerability in ImageIO that has been exploited.
The ImageIO vulnerability, which Apple credits as being discovered internally, could allow an attacker to use a maliciously crafted image file to corrupt memory in an exploitable way. Apple acknowledged that this security flaw “may have been exploited in an extremely sophisticated attack against specific targeted individuals.” This wording suggests that the vulnerability was weaponized for nation-state use in operations against high-value targets, likely involving spyware like Pegasus.
Given the active exploitation, we recommend updating your devices promptly, especially if you are in a position that might be targeted by sophisticated attackers. While most users are extremely unlikely to be affected, there’s no benefit in leaving your devices vulnerable in case the exploit is resold to less discerning attackers.
At this point, I would hope Apple punishes the individuals responsible for this vulnerability. There is NO EXCUSE for memory corruption given how well understood the means to prevent are now.
I assume you’re not a software developer.
Although there are very good tools for identifying and fixing memory problems, we are not even close to the point where an expert programmer can be expected to produce perfect code all the time on a system as big and complicated as a major operating system.
It’s also possible the vulnerability is tied to an open-source module or component of the affected software.
Hello David,
I have a few comments in response to your comment:
I was a software developer for many years at a major aerospace company. I don’t want to escalate this discussion into a “who’s right, who’s wrong” debate, however:
While I agree with you totally about not expecting perfect code from developers on such a huge product set (that is, Apple’s various Operating Systems), on the other hand, if Apple could focus some of their massive software development army on developing more and better regression tests, some bugs (perhaps not all) might be caught and avoided prior to release.
The “problem” is, developing a better and more robust regression-test suite is not sexy work, but it is valuable work.
As a good example, in this particular case, literally and potentially endangering the lives of certain individuals (for example, journalists, political activists, etc.) via releasing potentially dangerous bugs, is also not sexy.
You can ask yourself, how many times have you seen in the various Tidbits commentary threads, comments such as: Why doesn’t Apple spend more time and effort fixing bugs, in addition to focusing so much on developing major updates for the annual release of the Operating Systems, (including introducing yet more bugs)??
Because Apple does have a massive software development army, they could address both bug eradication, and major Operating System releases.
I updated my Sequoia Mac this morning when I got the update prompt. Currently updating several iDevices. No update yet for an older Mac running Monterery.
Strange thing that Sequoia 15.6.1 is a 1.56 GB download, when ImageIO is a framework - which should be updateable without having to touch much else.
I need 14gb free on my phone to install this??
I’m afraid, as a former Apple quality assurance programmer, I have to agree. Some outdated comments on this at “The Era of “Update Automatically” is Over.
Apparently the bug in this case is insufficient bounds checking, according to Apple’s report on the “security content” of macOS 15.6.1:
I also am not a developer.
Nevertheless, I’m under the impression that bounds checking became established element of good coding practice long, long ago.
That sounds simple. Except…
Cupertino/Redmond: A vast team works around the clock, laying siege to their own software — bounds checking, unit testing, pounding it for integration flaws.
Pyonyang/GRU: A vast team works around the clock, laying siege to the same software — bounds checking, unit testing, pounding it for integration flaws.
Most often, Team A uncovers the vulnerability before Team B. Sometimes Team B, with the resources of an entire nation/state, uncovers the vulnerability before Team A.
I’m with Dave. The size of Team B is greater than the entire population of Cupertino by a large factor. (Cyber-incompetence at our own state and federal government level is generally not a matter of resources.)
Pyongyang is a poor example. Apple makes all of North Korea’s estimated annual GDP in just 18 days.
I’m not satisfied with this explanation anyway. Team B could disappear into a hole tomorrow and I couldn’t care less. Team A on the other hand runs our lives. I expect much more from Team A. Allowing Team B to score a preventable win every once in a while and then just shrugging it off as no big deal is to me entirely unacceptable. At least as long as Team A wants to remain in charge of our tech. In my book, if you’re king of the hill and want to remain there, that comes with expectations.
While I won’t disagree, I will note that regression tests only catch regressions, i.e. bugs that were found, fixed, and have reappeared. I haven’t seen anything suggesting this particular bug is a regression (although I could have missed it), so regression tests wouldn’t have helped.
These sorts of “maliciously crafted” images (or whatever) are particularly hard to catch, as the existing test cases will be a collection of valid inputs and inputs that have caused (different) problems in the past. Fuzzing can help, although developing a fuzzer that creates inputs that aren’t immediately rejected and knowing how many times to run an inherently probabilistic test is difficult. Code reviews can also help, although it takes particularly detail oriented people (who have their own work to do) to catch these kinds of things, and even detail oriented people’s minds wander reading through 1,000 lines of code, making them miss the subtle vulnerability on the line 1,001.
While I’ve been critical about Apple’s QA here and elsewhere, this seems like something particularly hard to catch, and requires putting resources on a problem that might not even exist, so I can’t be too critical in this case.
Yes, but I worked on mission and safety critical stuff, where bugs were NOT ACCEPTABLE. i’m always disgusted by the attitude that “bugs are inevitable and therefore acceptable.”
And yeah, software QA is probably the only part of software where you CAN throw bodies at the problem and get a positive result.
We’ve had the technology to prevent memory corruption for many years. We’re just not willing to use the technology, because it would require more thinking and less hacking.
You can get results, but not by throwing the wrong bodies at the problem. It’s all too easy to rat-hole on testing what’s easy to test (or worse, what’s easy to automate), and miss more important areas. The decline in written (and reviewed) test plans makes this a lot worse.
So does the low prestige of testing, with managers appointed for reasons other than competence, and testers too junior (or not good enough) for engineering jobs. AI has started making this even worse; to upper management unfamiliar and unconcerned with testing, lots of low-priority tests written by a bot can seem an adequate substitute for (rather than supplement to) fewer tests written by an intelligent human.
Yeah, that would be my question…my MacBook Air is early 2015 and I’m stuck in Monterey. Are older OS, like Monterey, in trouble, potentially from this attack?
Unfortunately, there’s no way to know—that’s the downside of using operating systems that no longer receive security updates. That said, I think there are three reasons not to worry:
As long as you take precautions about avoiding sketchy sites, running something like Malwarebytes every so often, and so on, you should be fine.
And use a robust ad blocker, since a lot of malware (or at least phishing screens that make you think you’ve been attacked) seem to be distributed through ad networks.
The other thing to pay attention to if you are stuck on Monterey is to make sure you are using a current browser.
I’d avoid Safari on Monterey, but most other commonly used browsers appear to be supported, at least for a little while longer.
(I agree with this advice)
Thanks for this… as it happens, I don’t use Safari, but I do use Chrome and Brave, and, generally speaking, I use a VPN, depending on where I’m going online.
FWIIW Firefox is still supported on my “retired” iMac running Mojave (used as a media server). Every few weeks Firefox alerts me to an update. So I don’t expect Monterey will be a problem.
Agreed. Don’t forget to keep an eye on the Firefox release schedule, though. Mozilla says that they will make a decision on support for Firefox 115 ESR on Mojave sometime next month:
I’m definitely keeping an eye on that. If Firefox stops supporting macOS 10.12 (Sierra), then I’ll have to pick from two choices for my 2011 MacBook Air:
When I applied the update to my M2 Macbook Air it wouldn’t reboot. The message was that my firmware was corrupted. Had to use another mac (what if I didn’t have one!) and about 1.5 hours of time to “revive my firmware” (which worked). If not, the only other alternative was to “restore to factory settings” and load my latest time machine backup (which was about 3 weeks old). Did anyone else have this problem? I just turned off “Automatic Update”.
I did not. Neither on an M4 nor on an M1 MBP.
Apple stores will help. And I assume so will authorized dealers. Obviously, that’s not convenient if you’re far away. Perhaps a neighbor or friend close by could help.
An excellent reminder to all of us to always keep an up-to-date backup. If you modify files, apps, and/or settings on a daily basis, you probably also want to make sure you have an at least daily backup.
IMHO that’s a good idea. Most will want to keep Install Security Responses and system files on though.
Settings > General > Software Update > Automatic Updates > click on the circled i
My 2019 MacBook Pro (Intel) applied the update automatically with no problem. But I am nervous for my Mac Mini M1, which is my main file server. (And it is backed up by Time Machine AND Carbon Copy Cloner nightly.)
I’ve always heard “wait a week to see if there are any problems”. Now I’m a believer :)
Anecdotal of course, but I’ve installed it on my M2 MacBook Air (my main productivity machine) and my M1 Pro Mac mini (a media server, plus a few other server type things - my main Syncthing repository, my main backup source for online server accounts, my spamsieve monitoring device, plus it also monitors my other devices to look for loss of connectivity). Both installed without an issue at all.
Fair enough… But once you’ve figured out what and how to test, doing the tests can be ‘parallelized’ across many workers.
Depends on the nature of the testing.
It requires particular skills to design proper tests and develop test-automation scripts and tools. These skills have a bit of overlap with software development skills, but they are distinct. Developers do not generally make for good test engineers.
Once the tests and scripts have been developed…
Junior engineers can launch automated tests and collect results. But you shouldn’t need people to do this at all. Best practices today involves CI/CD practices, where automated software builds (nightly or other schedules) trigger automated testing. Not every test can be run for every build, but the full suite should be run for every build that will become a release.
For those tests that can’t be automated (and there are always some), junior engineers can do the job, but they are going to require training if they don’t have prior experience with testing (and if they do, they’re probably no longer junior-level engineers). If you just throw them at a device and a test-plan document, they’re not going to do it all right.
Apple may be doing all the right things here. I don’t know. This is just a response to the idea of “throwing bodies at the problem”.