102
votes
All Apple users are recommended to immediately update their devices to patch a zero-click, zero-day exploit captured in the wild
Link information
This data is scraped automatically and may be incorrect.
- Title
- BLASTPASS: NSO Group iPhone Zero-Click, Zero-Day Exploit Captured in the Wild - The Citizen Lab
- Published
- Sep 7 2023
- Word count
- 253 words
if you have any Apple devices, you should go apply this update ASAP. this is essentially a worst-case vulnerability (remote code execution with no user interaction needed) and it was found being actively exploited in the wild.
Apple's pages about the update:
https://support.apple.com/en-us/HT213905 (iPhone and iPad)
https://support.apple.com/en-us/HT213906 (macOS Ventura)
https://support.apple.com/en-us/HT213907 (watchOS)
CVEs:
https://nvd.nist.gov/vuln/detail/CVE-2023-41061
https://nvd.nist.gov/vuln/detail/CVE-2023-41064
Think it's worth enumerating the versions here too:
To clarify, these are safe versions with the exploit patched.
Is this a new one that is not related to the one that affected kaspersky labs?
https://arstechnica.com/information-technology/2023/06/clickless-ios-exploits-infect-kaspersky-iphones-with-never-before-seen-malware/
I guess it is, wild that we have seen back to back iMessage exploits like this. This is stuff straight out of hackers in the movies, just breaking into arbitrary phones.
that was from June? yes, this one is brand-new and just announced. the attack vector seems broadly similar (maliciously crafted iMessage) so it's possible this one was found as part of follow-up research looking for similar vulnerabilities.
2023 has been a pretty good year for that.
I get the feeling that these state sponsored orgs have a pretty large backlog of exploits and have at least one still working one available at any time.
The traditional “discover and update” method of security just isn’t good enough. We need systems that prevent bugs outright. Or limit their reach. Memory unsafe languages have to go at a minimum.
Yes.
That's not how it works.
That is already how it works.
It is actively being worked on. (I think it is being done wrong, but that is a separate point.)
It kind of can be. Obviously we're can't click our fingers and magically wish all bugs away, but we are slowly learning what sorts of things reduce the chances of bugs happening. It's just that we seem very reluctant to actually implement those things because it's hard, and writing buggy code is cheaper.
For example, Ann Marie Neufelder has done a bunch of research in this area - you can see some of her conclusions here. We also know that a lot of the most serious bugs come from bad memory management, and we have good ideas how to stop them - either via languages with managed memory, or languages that use the compiler to prevent memory errors. Rust, for example, seems to be directly solving problems at Google.
So yes, I think we do need to be looking at systems that prevent bugs. I think that's a realistic goal to have for software development as a discipline, and it's one we've typically not concentrated enough on.
So I can’t get through your first link without an ad blocking machine so I’ll have to try that later.
I will say the simple adoption off the unsafe one liner has caused a bunch of issues for rust last time I looked (years ago).
Suddenly even though all your code is safe it’s compromised because that crate you used was fine but it used a crate that had improper usage of unsafe and now you’re screwed.
Rust is better but this stuff is extremely hard. Especially when your super safe product gets blown out in the market by the laughably unsafe and cheaper/faster competitor.
Edit-
Going through the link now, I'll straight up say I have no where near the credentials to question their results, but I do feel there's some odd stuff here. Just jumping out at me-
"1. Not enough time" | "457. usually late projects are late because they started late, not because of insufficient time"
Uhh...i mean, while maybe true, I know that there's a hell of a lot of pressure and corner cutting even if you have the same number of hours to complete a project when you start behind, and still kinda feels like a version of "not enough time".
"4. Agile development" | So far, not a single project in our DB used this completely and consistently from start to finish."
Uh...yeah. That's kinda one of the huge complaints about it, so this feels like playing semantics. "Horrific attempts at the Agile theory that are then mutated by managers who think they can skip their part or rules they don't like" ranks where then, because that's probably what they meant to say if you're going to be this specific?
"9. Object oriented design and Code. | 395. While OO code may be more cohesive, that doesn't mean its defect free"
Again maybe this is old or i'm just too bad at coding to get this, but this reads like someone saying "OO sucks" and she responded as if they said "we should use OO more". I absolutely have heard a TON of criticism about OO patterns and inheritance is all but treated as an antipattern at this point from what I've seen, being the core factor of so many nightmares, so i'm inclined to believe that "oo is a problem" is the intent and that I'm maybe not getting this?
"4. Code Reviews | 366. Because the criteria for the reviews is often missing or not relevant to reducing defects".
Again, this feels odd. Reads as if it's saying "yes code reviews would work but you're doing them wrong so it doesn't count?" which...odd way to show that. Same logic with a couple of these.
On her top 10 list-
Avoid Big Blobs: yeah..this is nice, but seems to conflict with earlier statements. Namely big blobs are more likely to happen to people who are rushed...say because the project started late or they've switched in and out of agile 5 times.
Not skipping requirements, design, unit test, test, change control, etc even for small releases. While coders absolutely are guilty of this, it's also often exacerbated by pressure from management. You can ship a product that meets its function but has untested behavior, and boy don't they love hand waving those steps when the deadlines and sales promises start showing up.
"The factors associated with increased defect density....
3. Large projects spanning over many years with many people"
I don't think this one is news, but like...this is just the reality for some projects. Google chrome is not going to have a small tight team of founding vets behind it, ditto with any other similar sized project...such as iMessage?
I also can't help but wonder how badly the data is skewed by the sectors represented. 67% of the studied projects being Defense or space strikes me as not really looking at the majority of software out there?
While they are ABSOLUTELY falling prey to the same problems as more commercial sectors, they have different focuses and sometimes easier ways to force issues to push in the direction of safety. If you can argue cutting a corner will blow up a rocket and kill people (or uh...not as the case may be with defense), you can probably get the foot put down on proper testing. If you argue it might leak someone's data unintentionally, especially on a commercial product, they'll probably try to weasel their way around not asking "yeah but could they prove it was us" and ship it?
I do think the whole thing is very interesting to read, and worth reading for anyone who cares about the subject, but i'm not sure how well this supports your statement about "Systems that prevent bugs outright".
I've spent a lot of time trying to just code in styles that don't even represent error states, and it's HUGE boon to my code reliability, but I also screw around in F# on minor programs and have a ton of ability to practice and set my own deadlines. I know a few people who code for the military, and believe me when I say that just getting a new language even considered is a fight, ESPECIALLY if there's any sort of potential performance hit or MASS upgrade required. Rust is doing fucking magic by being so compatible with existing code, but the sheer quantity of stuff that must be rewritten is hard to even fathom, and it's going to cost even more.
Point being, humans are flawed, and incentives are flawed. People want features more than they want security, and even if they cared only about security, it's an extremely difficult thing to do, and something we've spent decades TRYING to do better. And yet we STILL have nulls and javascript to show for it.
I don't really want to get into language holy wars, but the point is that these sorts of languages work - they probably reduce the defect rate of software projects. Of course, that defect rate is never going to be zero, but when it comes to memory and safety issues like this, we could be doing a lot more than we've historically done.
I agree with the thrust of your argument. I disagree only with the strong proposition that it should be possible to prevent defects or security flaws altogether. Primarily for two concrete reasons:
I agree that preventing defects entirely is ultimately impossible - they're stochastic events, we cannot predict them in advance, we can just reduce their chances of happening.
That said, we know a lot of ways to reduce those chances, but I feel like they are not implemented anywhere near as often as they could be.
I'd love for you to expand on this point, I know there are new languages designed around better memory management, but I don't know enough to tell good implementations apart from bad ones.
Do you have an example of a language you think is doing it well?
It is something I plan to write about in more detail in the future, but here is a rough sketch of some of the issues (I was going to say brief, but although it is rough, it is not brief, because there is a lot of ground to clear).
So, starting with this framing is already a bit problematic. When the foundation is rotten, anything you build on top of it is suspect—extricating ourselves from our current fix requires a careful step back and reflection (or else a couple of centuries of incremental evolution, which seems like a likelier direction the mainstream to take, unfortunately). Trying to prevent use after frees and buffer overflows (for some slightly narrow definitions of those two bug classes) by construction is very nice and cute and valuable (and also has some very specific consequences I will get to); but it's a half measure, and I find it pretty absurd and sad that languages are still popular for writing applications which do not afford even that much.
Concretely—consider as an example unix. From unix's own perspective, it is safe. Unix is a capability-safe programming language: its capabilities are called 'file descriptors', and its units of security encapsulation are 'processes'; one process cannot forge another's file descriptors, or access another's memory, so the system is safe. This rosy ideal turns out to be completely inadequate. In reality, what we have ended up with is a stratified system—there are two strata of communication: communication between processes, and communication within a process. There is an inherent tension because:
Applications which are designed for security (like chrome or qmail) will use 'privsep' and separate themselves into multiple processes, but there is always a pressure to consolidate, because communication between processes is slow, difficult, and error-prone. Even though it is possible to forge pointers and file descriptors within a process. In a well-architected computing system, it should be just as easy and fast to communicate between security domains as within a security domain. One consequence of this is that hardware memory protection has to go: transitioning between hardware memory protection domains is obligatorily slow. However, the 'memory safety' guarantee ensures by construction that code does not forge pointers, meaning that the basic invariants of the system can be maintained. And of course, taking this a step further we get pervasive and uniform capability safety: ambient authority has to go. Distributing programs as raw machine-code binary artifacts also has to go.
Rust, for example, is not too interesting. It admits unrestricted access to 'unsafe', rather than making it a capability, and similarly admits unrestricted access to other shared resources, like the network and the file system. This also makes it extra-vulnerable to supply-chain vulnerabilities.
Rust is also statically typed, which makes it obligatorily somewhat brittle. Although some useful things have come out of type theory (like session types), it tends to be somewhat absolutist and have its head stuck up its ass, which limits its applicability. The academic work on static analysis is far, far ahead in terms of sophistication and usefulness, even though (or perhaps because) it has the restriction that it has to run on the code as it is, rather than forcing you to change it if it can't figure something out. Insofar as human intervention makes sense, it is not through something like a traditional static type system, but rather things like:
Attendantly required is a re-think of the 'compiler' and 'program' and what their roles are, both technical and social. Our present-day '''state of the art''' compilers (gcc and llvm) are basically a souped-up 1980s design which has persisted due to borked incentive structures. Fran allen, inventor of optimising compilers, discusses the notion of a 'program data base'—we were well aware of these issues, but have since forgotten (I had never heard of a program data base before then, and find no relevant results when I google, even though allen implies that everybody knows what it is). There is much more to say, but I must be getting to bed. Two more links, as much for levity as anything:
Thanks for the great overview! Regarding your Unix example, it sounds like this isn't a problem that can fixed easily and requires a ground-up rewrite with a different architecture (or a brand new OS), probably with a different language that makes very different decisions on what architectures it facilitates you to make. Am I reading you correctly?
It sounds really interesting, I think we need more boundary-pushing ideas like this. Are you (or anyone you know) currently working on implementing these ideas?
You can build an 'operating system' embedded inside of a unix. It won't interoperate, and it will be slower and less robust than it could be if it ran on bare metal, but it will mostly work, and save you the trouble of writing device drivers; this is more or less what web browsers do. And then you can think about embedding existing code (esp. important for stuff like media decoders or w/e)—insofar as it's memory-safe, you can stick it in a sandbox as-is; or pay the performance penalty for sandboxing memory-unsafe code. Broadly, it's a good idea to try to meet existing structures where they are; imagine running a dos game and clicking on a pixel to see the code that generated it. See also: binsec.
Many of these are ideas I've gotten from talking to other people about these issues. Some are very old, while others make more sense in light of recently-developed technology. The specific organisation is my own, as are a good number of the details. But, although I'll probably do a little bit of dissemination, I have, frankly speaking, better things to spend my life on than revolutionising computers (and this has as much as anything to do with a more general disillusionment with computers than some of my compatriots). Doing some work on the 'compiler' agglomeration as a side-project, because that interests me and I have things to contribute there.
Other projects: yes, they exist. Pruning because I don't want to give anybody any unwanted publicity. CLOSOS is not too ambitious, by these standards, but it is okay and has some momentum behind it; I'm sure Robert would appreciate eyeballs and code contributions—https://github.com/robert-strandh and https://github.com/s-expressionists/. Arcan is no less ambitious than I am, but its author has somewhat different ideals and values than I do (less different than it might seem at first glance!), as well as different priorities and experience. (https://www.divergent-desktop.org/blog/2020/08/10/principles-overview/ might be a better place to start, though some things are still not obviously explicated.)
Also bundled up in all of these is, as you can probably guess, a set of ideals that extends beyond plain security or correctness (though there ends up being a lot of overlap in mechanism). I've given a more security-focused frame, but it's really not my area of expertise; my interests are more in the domains of performance, interface design, and interactivity.
Edit: Capabilities are important, but they have largely made their way into the canon, if not yet the mainstream. A lot of early work on them was done in e, though it languishes now. And e's notion of validators also mirrors some of what I mentioned about pluggable type systems.
To be clear, "Apple devices" appears to mean iPhones and iPads, at least according to Apple's info. I don't see this affecting their other devices.
Someone correct me if I'm wrong.
the CitizenLab description says "including iPhones, iPads, Mac computers, and Apple Watches"
Apple's page only says iPhones and iPads
but 2023-41061 (linked above) mentions watchOS, and 2023-41064 mentions MacOS Ventura
so it's unclear but it seems to be affecting everything that can potentially display an iMessage
edit: ahh, figured it out - Apple has two other pages for the respective watchOS and MacOS updates:
https://support.apple.com/en-us/HT213906 and https://support.apple.com/en-us/HT213907
So if I have an older mac running Big Sur is it still vulnerable?
One of the more interesting questions to me is does this affect those who have switched iMessage off? I suspect it does but that is conjecture on my part. A case of worst-scenario thinking, perhaps, but the most practicable perspective, I would submit.
I’m not sure if disabling iMessage is enough but “Lockdown mode” did seem to prevent this attack.
https://arstechnica.com/gadgets/2023/09/apple-patches-clickless-0-day-image-processing-vulnerability-in-ios-macos/
Its unfortunate that the prevailing narrative thru all of this is "Update now!!!" when it should be "Enable LockDown".
Have you seen what sort of restrictions are in place when you enable "Lockdown Mode"? If you have a corporate issued device that uses MDM, can't use Lockdown at all.
I can't speak to MDM specifically but I know you can still supervise the device, you just can't enroll it or apply supervision and profiles while Lockdown is activated, you have to
disable it > (devices resets itself) > do it then > reapply Lockdown when MDM/supervision/profile is applied > profit?That link is about iOS, but it looks like there's an update for Mac OS too.
It's a library, so I'd guess the vulnerability depends on which apps you use and what they read from the Internet.
I hope that Apple's and Meta's lawsuits against Israel's NSO Group can move forward.
https://www.reuters.com/legal/us-supreme-court-lets-metas-whatsapp-pursue-pegasus-spyware-suit-2023-01-09/
This is super timely, especially given some of the responses I've received with regard to the questionable safety of iMessage use.
Previously on Citizen Lab (2021): FORCEDENTRY: NSO Group iMessage exploit targeting Apple's image rendering library
Does this affect older Apple devices, ones older than iPhone 8 or iPad Air 3, who didn't get the update? I have one of these older devices just for an iMessage group chat I can't access otherwise (thanks Apple).
Nope. There should be a law against keeping bootloaders locked if devices aren't getting security updates.