> The exploit involved PassKit attachments containing malicious images sent from an attacker iMessage account to the victim.
Man, iMessage is a security disaster for Apple. No matter how much work they do in other areas, it seems like they'll paying for a while for their decisions around the iMessage architecture.
At least they’re trying? Meanwhile Google has spent 2 decades refusing to release a messenger that encrypts by default because they think they should be able to mine all your personal conversations.
I take that back, they announced encrypted messaging, then never released it, then probably fired the engineer who said it’d be a feature in allo (or whatever their last attempt was).
iMessage or android messages? iMessage is E2E by default, unless one or more parties own multiple apple devices, in which case apple stores an encryption key on iCloud and maintains E2EE connections with every connected Apple device. This changes if you turn on Advanced data protection-- then iCloud no longer has the ability to decrypt messages. Somewhat unrelated but ADP is off by default as most customers do not want or need this.
Android Messages, the competitor to iMessage. The parent claimed that Google resists encrypting anything so they can mine your data. I was merely trying to ask for accuracy. I don't know the technical aspects of every Google messaging app but as the other responses in the thread confirm, Messages is end to end encrypted by default for non-SMS messages.
I just checked and Google does have a Messages app, different from the Messages app on my phone, probably by Samsung, which deals with SMSes. According to Play it has 1B+ downloads so it's probably preinstalled.
Anyway, the competitor of iMessage and Messages is WhatsApp. Nobody is sending me SMSes except banks so even iPhone users use WhatsApp to send messages to friends and to groups in my country. If somebody would insist using only iMessage they would be out of the loop. And about Messages, well, I don't have that app, I receive no SMSes, I still communicate with everybody so I guess that nobody uses Messages too.
That would be probably 100% of the iOS users that I know, including my entire family. Everyone's got an iPhone, iPad, Apple Watch, Macbook etc. It's such a nice ecosystem, so it's hard not to get hooked.
iMessage is E2E even without ADP, even with groups and multiple devices. The details are complex, but they are publicly documented here[1]:
The issue (I think) you are referring to is that if you enable iCloud backup[2] or iCloud for Messages[3] (both of which move effectively move the storage of the messages to the cloud, either as part of the device backup or as the canonical representation that devices sync from respectively) then the messages decoded on device will be stored in blobs that iCloud has the keys to unless you enable Advanced Data Protection.
How is that related? Encryption doesn’t really protect against malicious payloads being sent. Quiet the opposite actually as they can’t be scanned / stripped on the server.
Though it can fall back to SMS in case you don't have data, which isn't E2EE. I'm not sure what the UX flow is like in that case, whether it warns you and asks for permission to send over less secure channel.
I was under the impression that this is a 'proprietary' extension between Google devices, and that there was no RCS-standard-based E2EE:
> The RCS specification defines several types of messages. Our implementation of E2EE uses varying strategies for encrypting each type of message to maximize user privacy while still adhering to the RCS specification.
No that's not true.
Google just fails miserably at anything social, but almost every chat attempt from them eas encrypted, and now they are pushing RCS, which is also E2EE.
Google started pushing for carriers to use RCS in 2015, and launched it's own app for it in 2019 after that failed to move quickly enough. They didn't start adding E2EE to it until 2020, and it wasn't the default until 2021.
You are confusing security (no exploits) with privacy (encryption). The iMessage system is really private (no third party not even Apple can read your messages) but traditionally full of security holes (messages once decrypted can harm the rest of your device).
I'm not confusing anything. The entire point of the exploits in question are to BREAK the privacy provided by messenger. Google doesn't provide any in the first place, and actively mines your data. Who needs an exploit when it's never encrypted in the first place?
To further this: you realize NSO isn't selling these exploits to Russian kiddies to steal your bank info, right?
These exploits are used by people like the Saudi Government to uncover a Jeff Bezos affair. They're after politicians/power brokers for the purpose of accessing otherwise secure communications for the purpose of stealing state secrets or blackmail.
It absolutely does, you're exactly one subpoena away from that happening. Then you're at the mercy of Google deciding whether they care more about you or their balance sheet.
> no third party not even Apple can read your messages
This is not something that can be stated as fact unless 3rd party clients for a service exist. Apple can, with complete honesty, claim that messages are encrypted at rest/in transit all they want, but since they publish the only implementation of the client, they can modify it at any time to expose the messages to them, in any number of ways.
They're slowly rewriting the whole thing in Swift which should eventually eliminate most of the non architectural attack vectors. Most of them were mitigated in iOS 14 where they did some rather large architectural changes.
When I look at an initiative like BlastDoor, I'm struck by how unlikely it is that every other messaging app makes a similar investment on every platform. Does WhatsApp have a similar architecture? Has the Gmail app rewritten all its image parsers in a similar manner? Has Tinder? And sure, if you compromise WhatsApp you only get access to its internal memory and may not be able to escalate to other apps or OS storage - but compromising someone's WhatsApp messages isn't any less serious, and there's history of escalation being possible: https://techcrunch.com/2019/05/13/whatsapp-exploit-let-attac...
It's a miracle that these kinds of zero-click zero-days don't get announced every single week. Though maybe they do, and we just don't know about them...
Some of the problems with iMessage have to do with the fact that it's integrated with the system SMS app. It seems that there are a large number of legacy requirements in the GSM spec that require the Messages app to be privileged in some way, especially with regards to automatic processing of data received. There have been plenty of iMessage or Messages related vulnerabilities.
I do wish there was a way to turn off automatic downloading of attachments like images etc. from at least non contacts. I think many/most other chat applications, by default, sanitize and/or format images and media on upload on the server by transcoding image data to prevent things like this and save bandwidth (e.g. Facebook/Meta appears to recompress images server side). However, there are obviously security and privacy considerations to doing this, and the client is not exactly something you want to trust to do this, so I can understand why they would be reluctant to implement something like this.
Perhaps this is one potential use of Treacherous (trusted) computing/remote attestation - the client runs a remotely attested signed binary code that will read an image file, encode the pixels as a jpg, and output a signed output that will only be accepted by the server if untampered.
Obviously, there would be issues with that approach as well, but it could potentially prevent the use of the iMessage network to send "crafted" media files.
Apple have a service which attempts to do this, BlastDoor. The issue here is feature surface area unrelated to GSM. My guess from the CVEs is that this exploit revolves around sending a valid Wallet/PassKit item attachment which has a malicious image. The payload is safely _deserialized_ by BlastDoor itself, but is then passed off to the PassKit framework which happily detonates it.
IMO Apple should make a middle ground Lockdown mode - something that still allows attachments (which Lockdown mode doesn't, making it difficult for many users to employ), but forces them to be 1-click. This is something I would use personally and would at least protect me from getting 0-clicked by attacks like this; I'd never click a Wallet item from an unknown sender, but I also can't live with the restrictions in Lockdown mode.
It pisses me off man. If someone sends you a link on iOS, you can't copy it without doing a long press that loads all the spyware on the website in a preview window
Apple's architectural fix here is to move file parsing and other risky operations into proper sandbox harnesses, and to tighten these harnesses year after year.
This is the path that WebKit has followed, and the sandbox for the WebKit JIT is incredibly hard to break through these days
One can't even mark all messages as read in iMessage, which seems to me like the most basic functionality. Something is really messed up in how this thing has to run if you can't do that
iMessage is overall a lot more complicated and integrated than I like it to be. Want to switch accounts, you gotta log your entire user or device out of iCloud. Logging back in will often create issues. Using old Mac/iPhone OS versions creates issues. Messages and attachments are received separately by different devices, and weird things happen when one device is out of space. Deleting messages or blocking senders is per-device. Different devices might miss some messages or even get them out of order. A device waking from sleep often gets messages delayed by minutes (like email), and you're notified a second time for them. And lastly, the "effective. Power لُلُصّبُلُلصّبُررً ॣ ॣh ॣ ॣ 冗" vulnerabilities.
Compared to Facebook Messenger where there's one consistent state in the master server and neatly sandboxed web or iPhone app calling it. And yeah, I know these are partially by-products of e2ee vs traditional, and nobody else has really done e2ee messaging with multiple devices.
The other problem with logging out and back in is that it resets to all iClouds insane defaults that you have to manualky comb over to fix. Its 1000% dark pattern and default nonsense.
Interestingly, no kernel vulnerability or anything is mentioned.
As far as I know, any parsing code for iMessages should run within the BlastDoor sandbox – is there another vulnerability in the chain that is not reported here?
One CVE is in Wallet and Citizen Lab mention PassKit. My guess is that BlastDoor deserializes the PassKit payload successfully, then sends it to PassKit which subsequently decodes a malicious image outside of BlastDoor.
It may be the case that either the kernel vulnerability hasn't been analyzed or fixed yet, or that they were not able to capture it. Many of these exploits have multiple stages and grabbing the later ones is difficult.
Curious why no fix is out for iOS 15 yet. Is iOS 15 not vulnerable to this attack? Or is there often a delay in backporting security fixes that I'm not aware of? And if so, should I be implementing a workaround if I wanted to protect against these exploits?
They've been supporting iOS 15 with security updates for devices that can't update to iOS 16. Not sure how long they'll continue doing it but I imagine it'll be for a good while.
Its super interesting to me how much its emphasized that you shouldn't use this (Lockdown Mode) unless you are a journalist or otherwise in direct danger. They really do try to talk you out of it. Its curious, because there's very little difference in functionality other than disabling a lot of Apple nonsense from running in the background expanding your attack surface.
Apple doesn't want it's users to have an interior experience. It might be subtle so it makes sense that they don't want fully uninformed users from enabling it for no real reason. Currently it's not clear anyone who's not under risk of state sponsored monitoring should bother enabling it. Thus it's not clear why they should message it any other way.
Here we go again... NSO Group has a long history of 0-click, 0-days against iMessage, and just a few months ago Kaspersky caught a different zero day iMessage exploit targeting their staff.
If Apple repeatedly fails at securing their devices from an attack vector that has been demonstrated over, and over, and over... no wonder China is banning government officials from using their devices.
Android is moving away from C and towards more secure languages. From one of their recent blog posts, the majority of code written for android is now in memory safe languages.
Of course, it's not necessary to use a language where "Give control of your phone to remote attackers" is one of the possibilities at all.
General purpose languages, whether that's something like C or Rust or even Javascript are not the appropriate tool. Turing Completeness is a bad idea from a security point of view, not a wonderful feature.
> Not sure what the answer is for existing memory-unsafe code.
It's an engineering approach that involves writing "A buffer overflow issue was addressed with improved memory handling" an awful lot. Hopefully one day they will finish improving the memory handling!
And for this problem specifically Android can use WUFFS. WUFFS is a special purpose language for Wrangling Untrusted File Formats Safetly. Trading away generality (the ability to write a program which say, sends email) gets them complete safety and excellent performance.
In Rust we can't trivially write a bounds miss by mistake. But in WUFFS we just can't write a bounds miss at all. Like, that's not a thing in WUFFS, it doesn't compile. You can write your own bounds checks and show WUFFS that works, or you can write code which clearly can't have a bounds miss with no checks, that works too. But you can't just "forget" or "screw up" those won't compile.
This would be frustrating in a general purpose language. WUFFS doesn't have a "Hello, World" program because it lacks both strings and the idea of outputing to the screen. But WUFFS isn't a general purpose language, however it's the correct way to write the code that takes image files we got from some dubious source and processes them.
When Apple announced they wanted to provide proper security for vulnerable iPhone users, this is what that would look like coming from a company which actually cared about security. What you got is what it looks like from a company which prioritised marketing.
The pixel is decent if using graphene is. Not sure if any system is good by default. Apple fans think their defaults are somehow more private or secure, mostly due to marketing.
Decent? From a security perspective it's superior to the iPhone. As for Graphene, unless you've personally vetted the code I don't see how it can be trusted. And I won't even go into the drama that OS comes with.
Then what do you call the custom OS that ships on the Pixel? Of course it's a custom built OS that's designed to work with the custom hardware on the Pixel.
>One device series does not offer a glimpse of the market.
Security is defined by the marriage of software and hardware. The reason the Pixel is so secure is because of this. The OP made a blanket statement which did not apply to the Android ecosystem.
On Android you can disable automatic link preview and downloading of MMS messages. You can also swap out the application that handles text messages entirely.
Also the application that handles text message is itself sandboxed and limited to a fixed set of permissions (to be fair, that include messaging other humans, so an exploit would still be very bad, just not "remote root" bad).
That's the part that is still unclear with this BLASTPASS business. Surely iOS isn't running the messaging app as a device root, right? There's some other presumably-unpatched privilege elevation attack going on?
Hard truth for people to hear, here. So many insist that all technology is neutral. It's really satisfying to watch the super "enlightened/rational/logical" crowd react emotionally though.
To foster your point, I quote a comment from another post on HN now
> And the whole reason for the hydrogen burning [by SLS' engines] was to keep the space shuttle contractors jobs. Once again it's not a technical reason but a pork barrel one.
All things are political and technology is a thing.
That doesn't mean you can't analyze if a specific technical decision was made primarily on technical grounds/merit or if it is mostly a political one without a technical basis.
Sometimes even if they wanted to ban purely for security reasons, it would be blocked because it could trigger political repercussions, or seen as a offensive move by the opposition country
>I think the reasons are far more political than technical.
You may be right but sometimes the local optics track better when a political reason is given and the local authorities might also expect better compliance with political reasoning. Similarly, "We are getting pwned," never tracks well. There are solid reasons, long ago, why China stopped using Nortel.
The two issues are intertwined, and from their perspective the real risk is likely relying on a US company during a time when US/China relations are quite tense. But Apple repeatedly having 0-click 0-day iMessage exploits being used in the wild certainly doesn't help. At a minimum it's a very good justification for them to move to a domestic solution like Huawei and HarmonyOS.
That's needlessly defeatist and "it's so bad out there there's no point in trying" is a thought terminating cliché.
We can and should improve development practises, mitigate vulnerabities (ASLR, WAFs, etc), isolate systems from each other, and model threats in a way that we know where and how to do those things. It's not easy but just moaning "everything sucks" isn't how to fix it.
Apple, Google, etc. have whole teams of talented people dedicated to doing exactly these types of things, and they undoubtedly help prevent many vulnerabilities from escaping the labs. Yet vulnerabilities are still created and exploited despite their best efforts. As long as software is created by imperfect humans, it will reflect the imperfections of its creators.
It's not knowable for any, but it is knowable for some. You just have to build systems that are in the some and are inherently safe. Difficult, not impossible.
I agree, I just wanted to clarify that isn't mathematically impossible to make provably secure systems. It's just hard enough that it's not often done.
As sibling commenter wrote: they do exactly that. But the same way we fail to see all the cases prevented by vaccines, you only see when their work fail to work in the rare case.
And I mean this extremely rhetorically. The software launched along with the iPhone 4S. Going by geekbench, that CPU was 20-30 times weaker than a modern iPhone on a per-core basis.
I know the screens on the new phones are 5x bigger, but there is plenty of room for that sandbox.
That depends entirely on what the software needs to do.
For image decoding in particular, you can put the software into an exceptionally restrictive sandbox, or use a language that builds in the same restrictions.
No I/O. No system calls. Just churn internally and fill a preallocated section of memory with RGBA.
The broader system will still have weaknesses, but it won't have this kind, and this kind keeps happening.
What exactly is "an exceptionally restrictive sandbox"?
There are virtual machines such as JVM, V8, or even QEMU. These are sandboxes, which run either some special bytecode or native code with extreme performance drawbacks. Media decoders are performance- and energy-sensitive pieces of software in the end.
And media decoders actually ARE sandboxes of sorts. They are designed to interpret media formats, sometimes even Turing-complete bytecode in retrictive and isolated environments. And like any sandboxes, they too have bugs.
> And media decoders actually ARE sandboxes of sorts. They are designed to interpret media formats, sometimes even Turing-complete bytecode in retrictive and isolated environments. And like any sandboxes, they too have bugs.
It's pretty easy to sandbox a simple bytecode, but that's not the bulk of what a media decoder is doing. A plain old decoder is mostly not sandboxing what it does.
That's an awfully big preallocated array you have there. It would be pretty inefficient for that section of memory to be copied around, right? Let's map it into both processes. Also, image decoding is pretty hard, let's offload some of it to dedicated hardware. Of course, that hardware needs to have access to it mediated by the kernel. And the hardware needs to be able to access that shared memory, which was of course allocated correctly and the IOMMU setup was done correctly…
You see how even simple things are difficult to secure when they have to be implemented in practice?
Mapping pure RGBA across processes is safe, but also a single extra copy is not a big performance impact in the first place for an image decoder.
Configuring the IOMMU is one of the easiest parts of doing it in hardware. That's not going to make things "difficult to secure". And allocating the chunk of memory is trivial.
If you've seen an exploit caused by a big pre-allocated array of untrusted RGBA data, please explain how.
(If you mean they put evil data through it and then used a separate exploit to run it, that's not a vulnerability, that's just "data transfer exists".)
And you seeing someone screw up an IOMMU doesn't disqualify it from being one of the easiest parts of a hardware decoder.
Code to calculate size of preallocated array is incorrect. Size ends up too small or underflows.
Buffer is reused across calls. Buffer is actually mapped across processes and thus page-aligned. Code to check how much space is needed checks number of pages versus actual number of bytes, and fails to clear leftover data correctly.
Code receives RGBA buffer but expects some other encoding. Accidentally reads out of bounds as a result.
You can definitely say “oh these are stupid and I wouldn’t screw this up” but people do and that’s what really matters.
> Code to calculate size of preallocated array is incorrect. Size ends up too small or underflows.
If you go outside the array you copied/mapped out of the sandbox, then that doesn't let the attacker code escape the sandbox, you just put some of your own data onto the screen.
If you mean the sandbox isn't given enough memory, then that will make the sandbox exit when it hits unmapped addresses.
And how did you screw up length x width x 4?
> Buffer is reused across calls. Buffer is actually mapped across processes and thus page-aligned. Code to check how much space is needed checks number of pages versus actual number of bytes, and fails to clear leftover data correctly.
The sandboxed process doesn't have any way to exfiltrate data. At most it can display it back to you, which is not really any worse than innocent code which could also send back the leftover data.
> Code receives RGBA buffer but expects some other encoding. Accidentally reads out of bounds as a result.
Reads out of bounds and does what with it? That doesn't sound like a vulnerability to me. It might display private data or crash, but that's entirely of its own volition. The behavior would be the same between innocent code in the sandbox and malicious code in the sandbox.
There’s a million ways to screw that up. People botch SCM merges. People are hungover. People are distracted. People are tired. People are heartbroken. People are going through divorces. People have parents dying. People forget numbers. People make copy-paste mistakes. All the time.
> The sandboxed process doesn't have any way to exfiltrate data.
You can abuse it to gain a (known-page-offset) write primitive in the other, non-sandboxed process to which the buffer is also mapped.
But if you do that every image looks wrong and it's vanishingly unlikely to get into a release.
> You can abuse it to gain a (known-page-offset) write primitive in the other, non-sandboxed process to which the buffer is also mapped.
There's no reason to have the memory mapped into both processes at once, and you can't exploit the bytes you write without a real vulnerability.
Since it's a one-shot write into the buffer, if your intent is using it as an exploit step then you might as well encode an actual image with your exploit-assisting bytes.
> But if you do that every image looks wrong and it's vanishingly unlikely to get into a release.
The code doesn't have to be wrong for every input. It may be wrong just for pathological cases that don't occur in the field unless specifically crafted.
> Since it's a one-shot write into the buffer, if your intent is using it as an exploit step then you might as well encode an actual image with your exploit-assisting bytes.
The assumption was that the code tries to clean up the buffer immediately after use.
> The code doesn't have to be wrong for every input. It may be wrong just for pathological cases that don't occur in the field unless specifically crafted.
I could argue this more but it doesn't matter, that was just a little tangent, getting the size wrong will not let anything out of the sandbox.
> The assumption was that the code tries to clean up the buffer immediately after use.
Cleaning up would be removing the mmap. How are you going to exploit that? Your scenario is not very clear.
I think you're going for a situation where the sandboxed process can write to data in the host process outside the buffer? In a general sense I can imagine ways for that scenario to occur, but I can't figure out how you could get there via mmapping a buffer badly. A buffer mmap won't overlap anything else. If the mmap is too small then either process could read past the end, but would only see its own data (or a page fault).
> Cleaning up would be removing the mmap. How are you going to exploit that? Your scenario is not very clear.
If a buffer is going to be reused across calls, then cleaning after use is not the same thing as unmapping. One example for cleaning up a buffer after use would be zeroing.
If there's a bug in the calculation for the amount of zeroing needed, then leftover attacker-controlled data can bleed back from the sandboxed into the unsandboxed process and survive beyond the current transaction (because the code failed to zero the buffer correctly after use).
In other words, the attacker can now write arbitrary data into the unsandboxed process's memory at a semi-known location (known page offset) inside the mapped buffer. That data may not be very useful on its own, because it's still confined to the mmapped buffer. But it's now relatively well protected from reuse (until the next decoding task arrives).
That's plenty of time to do shenanigans. For example, you can combine it with an (unrelated) stack buffer overflow that may exist in the unsandboxed process, harmless on its own but more powerful if combined with an attacker-controlled gadget in a known location.
It's hard to see why the buffer wouldn't be per image. There's no reason to reuse that.
> In other words, the attacker can now write arbitrary data into the unsandboxed process's memory at a semi-known location (known page offset) inside the mapped buffer.
But what is the arbitrary data going to be?
1. If it's gadgets with known lower bits, then you could put that into a plain-old image file, no decoder exploits needed. Also this requires the second dumb mistake of the coder going out of their way to mark the buffer as executable.
2. If it's data you want to exfiltrate, you could just gather that after you trigger your unrelated exploit. This is only useful if everything aligns to drop the private data you want in that specific section of memory, and then the buffer is reused, and then the private data is removed from everywhere else, and then you run an unrelated exploit to actually give you control. This is exceptionally niche.
> It's hard to see why the buffer wouldn't be per image. There's no reason to reuse that.
Premature optimization is a thing. Most software developers are prone to it in one way or another. They may just assume a performance gain, design accordingly and move on. They may be working under a deadline tight enough so they never even consider checking their assumptions.
Or maybe the developer has actually run the experiment and found that reusing the buffer does yield a few percent of extra performance.
> But what is the arbitrary data going to be?
An internal struct whose purpose is to control the behavior of some unrelated aspect in the unsandboxed process. The struct contains a couple of pointers and, if attacker-controlled, ends up giving them an arbitrary process memory read/write primitive.
It sounds like you picked option 1 then, which means you don't need to take control of the sandbox. "Create an image that put arbitrary bytes into the buffer that stores its decoded form." simplifies to just "Create an image." There is no vulnerability here. This is just image display happening in a normal way. It's something to keep an eye on but not important itself. You have to add a vulnerability to get a vulnerability.
The original problem of preventing image decoding exploits has been solved in this hypothetical.
> Your original request was: “If you've seen an exploit caused by a big pre-allocated array of untrusted RGBA data, please explain how.”
I asked that in a context of whether you can contain vulnerabilities in a sandbox. If something doesn't even require a vulnerability, then it doesn't fit.
Also please note the words "caused by". A few helper bytes sitting somewhere are not the cause.
> Which is exactly how exploit chains work.
> A single vulnerability usually doesn’t achieve something dangerous on its own. But remove it from the chain and you lose your exploit.
Being part of an exploit chain doesn't by itself make something qualify as a vulnerability. (Consider arbitrary gadgets already in the program. You can't remove all bytes.) And I've never seen "you can send it bytes" described as a vulnerability before. Not even if you know the bytes will be stored at the start of a page!
iPhones can be provisioned with pretty extensive profiles/MDM so I doubt that part. They probably see all the zero-days and decide game respects game. Just not secure enough for such an incredibly insular power structure as theirs, even without the US connections.
I don't get why they wouldn't already insist on Huwawei and HarmonyOS unless this is more of an Inner Party issue where all the high-ups use iPhone intentionally because its more private than Huawei
I wonder what phone Z has been using all this time...
A few years ago kaspersky caught something that had to be removed by their rescue ISO. That ISO was blocked from downloading its updates and their UK support team couldn’t resolve the issue so never got to find out what it was, but it doesn’t look good there was a block preventing it from working.
Lockdown mode means you're able to use less stuff. In this case the "pass" feature doesn't exist in Lockdown mode and that's the attack target AIUI. So, if most people don't use it (because less stuff works) then it can be "successful" statistically because maybe the attackers aren't targeting the stuff you're allowed to use and you don't get exploited.
But this isn't a stable solution really. If Lockdown is popularized, NSO obviously will attack the things which are available in Lockdown. Apple shows no sign of only allowing it in Lockdown once it's actually safe - instead they've just arbitrarily decided what to allow and what not to allow.
Not entirely true because NSO (or their clients) have very specific target requeriments. If they want to target another Jamal Khashoggi and lockdown mode is used, they have their incentive to buy and create the demand for any 0day that they can then re-sell to their lovelly clients. No need statistics for this, the incentive is purely greed.
The downsides of using Lockdown Mode are minimal and well worth if you are an at-risk target. It's about reducing the attack surface and potentially getting notified if nation state actors try to attack your phone.
I got a new phone last year because my old phone could not call emergency services. Even if it was still receiving updates it's not clear that this would be fixed though. Google seems to think that local regulations prevent them from fixing this users of certain of their phones on certain carriers.
Maybe not throw away but give away. Just look at how many people buy a new phone every 2 years or even shorter period. Something must happen to their old phones.
People do that exact same thing with iPhones, so clearly Apple must suck too. /s
A lot of phone purchases anymore fall into the fashion side of consumerism. They don't actually care about X, Y or Z new features. They just want to show off that they have the new thing.
I've decided to upgrade instead of fix a 3-year-old phone that was because even if I could fix the hardware I still would not be able to safely enable bluetooth due to an arbitrary code execution bug in android that was not patched. It was otherwise perfectly good for my needs. I could not install a custom ROM because my model was not well supported and any I could not rely on such ROMs passing safetynet/play secure checks which the extremely vulnerable OEM ROM would reliably pass.
2) EU politicians don't know about Android updates because they don't understand how SW works and most probably have iOS anyway. The only time they hear about tech is when some Joe Schmoe insults them on Facebook so they send the courts after Facebook to doxx that person and get Facebook to moderate and ban "hate speech" on their platform. All in a day's work.
Granted, US politicians don't understand how tech works either, judging by the senate hearing of TikTok CEO ("Mr. CEO, can TikTok access my WiFi?"), but they have a powerful local tech industry to tell politicians what they should lobby for, while the EU doesn't.
It's to do with whether Android as a platform is patching older devices.
If they aren't then it may be better for everyone that they are destroyed rather than allowing them to be compromised and exposing security risks to the user.
That wasn’t a bad or mock-worthy question at all. TikTok’s app requests access to devices on the user’s local network. Why does it do that? Officially in order to connect to TVs/speakers, but what else could it decide to do with the access it’s granted?
>>> If the EU is so concerned about ewaste. They need to be more concerned about Android phones that are thrown away because they don’t get updates than a cord.
I just checked for updates for my Apple Watch as well, and I see an update for it ("This update provides important security fixes and is recommended for all users" - watchOS 9.6.2). I remember attempting to update earlier in the week (Tuesday?), and I don't remember seeing anything that day. I don't know if the update is related or not, but I decided to share anyway.
I don't think the EU is that much concerned about E-waste. If they were, they would not waste their time with chargers and instead focus on appliances and cars.
These things are not mutually exclusive, iirc they are doing appliances & cars, it's just that phones are often highlighted & batteries are usually the first thing that fails and can be easily replaced in all cases die to how build electronics. Charger standardization was in the pipeline for about a decade so not exactly a priority it being only passed now.
They didn't specify micro-b just that the phonemakers should settle on a port (which is partially why they didn't mandate it, the hope was that the industry would figure itself out but it didn't). Micro-b at the time was the most popular port for any handheld appliance. USB-C was only published in 2014.
Grsecurity generally focuses on the kernel side of things, although it does include a number of userspace mitigations as well. Still, when you have such ripe primitives not even Grsecurity can protect you.
What we really need is to just have radically lower bug density. Buffer overflows need to die. UAFs need to be made far less common. The "distance" between vulns needs to be greatly increased. Having design and validation issues sitting smushed between a dozen memory safety issues is just not something you can deal with through software mitigation techniques.
An app like iMessage is just too sensitive (ie: unauthenticated communication with many image parsers) to be built the way that it is. Fundamentally it just can't be safe without core components being rewritten with memory safety in mind. Grsecurity and other mitigations would be an awesome defense in depth and would be particularly helpful to avoid subsequent privescs, but I'm far more concerned with "anyone can text me an image and own me thanks to 1990s style bugs".
I'm not convinced that that's true. All we know is that one vulnerability was a "buffer overflow" - pretty vague. If this were, for example, an overflow on the heap, which Grsecurity mitigations would even impact it? Improved ASLR? Mprotect restrictions? There are very few mitigations in the Grsecurity patches that even touch userspace in a way that isn't focused on kernel protection.
Maybe if it's a stack based overflow something like PAX_RANDUSTACK would have had some impact but it depends.
And in case this at all comes off as me thinking anything negative about Grsecurity, I assure you that's not the case. I proudly wear the "Grsecurity Cheerleader" badge that Spender threw my way over a decade ago.
The US could demand NSO on a platter if they realty wanted to, but they don't. Israel intelligence often aids the US alphabet boys and the NSA on various offensive operations and intelligence gathering, which is why NSO is allowed to keep doing business by both parties.
And the US barely has an inherent interest in Saudi Arabia. Israel is credited for helping the US "fight terrorism in the Middle East" or maintain those puppets, but really they're just helping us help them. When it comes to things that don't directly benefit Israel, they don't care. Israel has never even fought ISIS for example, the largest recent terrorist threat in the region. And they're allowed to maintain some neutrality in situations like Russia's attack on Ukraine. You might even call them neutral wrt ISIS since they aren't in this mostly symbolic list: https://www.state.gov/the-global-coalition-to-defeat-isis-pa...
For all the things Israel has done against the US's wishes (like West Bank settlement), the US has struggled to do just one thing Israel doesn't like: the Iran nuclear deal. But at least one of our major parties is somewhat willing to push it. I think they're also somewhat annoyed with our focus on Ukraine.
It’s truly shocking how misinformed you are about foreign policy.
Israel attempted to maintain some level of neutrality wrt Russia bec when they show preferences, Russia punishes the local Jewish population… which they promptly did as soon as Israel showed any support for Ukraine.
Israel shares a ton of intel with the US regarding many of the local terrorist organizations in the ME. Not to mention they’re flying sorties into Syrian airspace almost nightly. (Infamously Syria AA shot down a russian spy plane, killing 11, thinking they finally caught an Israeli plane)
And Israel’s absence from that symbolic list was likely a precondition to get many of those Arab and African nations on the list. Israel has ISIS locally so there’s no doubt they’re fighting isis.
Finally wrt the Jordan’s west bank: they lost it years ago and it’s so odd you keep calling it that… maybe use the actual name for the area and suddenly Israel’s policy will make sense.
Are you an NSO psychopath or something?! Those funny propaganda jokes you're spewing are not working. The Israeli Hasbara lies are so bad and funny (Oh we won the land instead of we are scumy occupiers and land thieves haha.) This Israeli murder cult is sad and pathetic.
You're the one who has no argument, other than pure hatred. Any sane human being would be against criminal genocidal ideologies like Zionism and Nazism. Cheering the monstrous crimes of those political ideologies is nothing but vile hate. It is a murder cult, come with an argument or f off. It is not my job to educate you if you're brainwashed.
> And Israel’s absence from that symbolic list was likely a precondition to get many of those Arab and African nations on the list. Israel has ISIS locally so there’s no doubt they’re fighting isis.
Israel has never fought in any battle involving ISIS or carried out any smaller strikes against them. Some others who aren't in the coalition, like Russia, have. https://en.wikipedia.org/wiki/List_of_wars_and_battles_invol... Their operations in Syria have been against regime forces, Hezbollah, and other targets unfriendly towards Israel, not ISIS.
Even if there's significant ISIS presence in Israel (which I've never heard of), it hasn't convinced them to help fight ISIS next door. Their stance is neutral, and they don't pretend otherwise.
> Israel attempted to maintain some level of neutrality wrt Russia bec when they show preferences, Russia punishes the local Jewish population… which they promptly did as soon as Israel showed any support for Ukraine.
I didn't say there was no reason, because obviously there would be, including trade. They have been allowed to stay mostly neutral.
> Finally wrt the Jordan’s west bank: they lost it years ago and it’s so odd you keep calling it that… maybe use the actual name for the area and suddenly Israel’s policy will make sense.
It's the common name for the region used in America, that's all. I truly don't know what other name you had in mind, but whatever you call it, the US has been unhappy with Israel's policy.
> Even if there's significant ISIS presence in Israel (which I've never heard of), it hasn't convinced them to help fight ISIS next door. Their stance is neutral, and they don't pretend otherwise.
this is simply false. They help a ton and as I've said they've directly attacked them both within Israel's 1919 borders and assisted with attacks elsewhere in the region.
> I didn't say there was no reason, because obviously there would be, including trade. They have been allowed to stay mostly neutral.
so then why bring it up? but again, trade had nothing to do with it, its to protect the innocent people who cannot leave russia and who will be discriminated against due to their religion (much like you are doing right now).
You seem to think the NSO is some rogue org within Israel. Couldn’t be further from the truth. It’s simply a plausible deniability org that works for everyone, and counts every single US intelligence agency among its clients. The fact that you’re all upset about what they’re doing is exactly the point, you’re pointing your finger the NSO when it’s the NSA who’s paying them off.
We bought a vassal state with highly competent people. They are generally independent in internal affairs and so NSO group would have nothing to do with the government.
But you're right, we don't need that one at all any longer. Someone once told me that Israel would align more closely with Russia if we did that, which is a laughable come back, like, okay? have fun with that.
Retracking the various forms of funding and defense contractor slush funds would be a simple step.
Given where the group is headquartered, I doubt it. That unacknowledged aerial platform will remain firmly planted on the ground until the next defenseless target is chosen.
Please don't suggest that people should be murdered with drone-launched missiles for making software. Making software is a peaceful act, regardless of what purpose that software serves.
That is not a reasonable position, "peacefully" writing software that you know is to be used to murder and silence other people makes you just as complicit those crimes (definitely an accessory). No better than a getaway driver.
Software is speech (ie protected expression), like writing books.
A getaway driver is involved after the crime is committed. To assign the same level of culpability to a tool-maker would imply that they have the ability to predict the future.
A better example would be a car or firearm manufacturer. How the tool is used is up to the user.
Software doesn't root people's phones, cops and spies do. Someone sent that iMessage, and it wasn't the author of the software.
Speech can be murderous, and more importantly, it can be punishable. Ok, what about if the getaway driver drove him there as well, and explicitly expressed knowledge of the crime that was to occur and refused to abandon the effort upon receipt of such knowledge.
So at what point does the world bring sanctions against Israel for allowing organizations like this to exist there? Everyone knows NSO is just a dubiously legal version of common APT groups, so how do they still exist after these years?
Any politician who attempted something like that would immediately find themselves on the wrong side of the table with various three letter agencies. You’re incredibly naive if you think Israel or really anyone else is responsible for this. They’re simply doing the bidding of various first world intel orgs that want/need plausible deniability.
Game theory. They alert the big players of who is doing what, if they didn’t exist, China and Russia would get all this business and be at the cutting edge (and not share the most pertinent info).
this is actually not specific to israel, there are similar groups in other countries. finfisher was somewhere in benelux I think? hacking team was in italy. these two were pretty much dismantled but are just regrouping under new names.
this is a problem of all nation states wanting this kind of service, not of israel in particular.
We're all very lucky that CitizenLab exists as they are often the first discovery point of numerous similar exploits. They proactively scan the phones of internationally sensitive people and publish their findings. I'm not aware of any other public service that has had this much success exposing mobile device attacks. Attacks which have completely and utterly compromised the entire device that someone keeps with them all day every day.
I tip my hat to CitizenLab and the good work they do.
Again a buffer overflow in image decoding, that sounds similar to the one from 2021 [1]. That one was wild, building a CPU out of primitives offered by an arcane image compression format embedded in pdf, to be able to do enough arithmetic to further escalate to arbitrary code execution!
And a much older bug with TIF rendering in iOS 4 used by jailbreakme.com back in the day. It was wonderful pressing a button in Safari and suddenly seeing my iPod touch reboot with Cydia installed.
Your phone would reboot with a pineapple logo and console messages flying across the screen like a 1337 h4cker, starting with the "regents of the University of California, Berkeley" message. Then you'd go install a ton of Cydia hacks.
This is the frustrating part: that is cool from a technical perspective but terrifying when you think about this stuff being used to target journalists, activists, etc. Maybe not everyone gets the bone saw but some will - and from the sounds of it it’s people standing up to abusive people:
> Last week, while checking the device of an individual employed by a Washington DC-based civil society organization with international offices, Citizen Lab found an actively exploited zero-click vulnerability being used to deliver NSO Group’s Pegasus mercenary spyware.
What is frustrating is the NSO group continues to exist despite all the bad they do. How many people are they responsible for being on the receiving end of a bone saw?
Maybe that’s true, it probably is, but they should still be sanctioned into oblivion considering they consistently are in the headlines on the wrong end of this being used for deeply questionable purposes.
The US enjoys some fruits of their labor and they're conveniently distanced from any explicitly funded operations to avoid blow back when exploits are publicized. They won't enforce sanctions or, more practically, withhold the massive defense subsidies they give to Israel.
>... as greed leads them into bed with the wrong people.
I'd hope they're at least targeting their own customers as part of state-sanctioned operations. Still, that doesn't justify the dissidents they indirectly facilitate being thrown under the bus. Or on the receiving end of a bone saw, as another commenter put it.
True, but there’s a real question about how effective they’d be. NSO has the veneer of legitimacy which means they can hire top notch talent by pretending their products are just law enforcement tools – fewer people would be comfortable working for a Russian mercenary group or able to tell their friends and family their work for a Chinese government vendor wasn’t helping oppression. That doesn't mean that everyone in the world is comfortable working for them but think about how it is for Palantir where a significant percentage of top tech talent don't seek employment there due to ethical concerns - NSO has similar problems but they'd be an order of magnitude worse if they weren't in a close ally country.
Allowing a US+Israel-approved* company to do this makes higher revenues possible, meaning they can attract higher talent => more hacks. Which would be fine if we prevented them from selling to unwanted customers. With weapons, we control who gets them, regardless of money.
* I was going to say "sanctioned," but that word can mean two entirely opposite things, it's dumb
At the risk of being boring: software liability would go a long way towards getting companies to do this work themselves. Even though Apple is the largest company on the planet an entity that has a small fraction of the budget is apparently able to do a better job. I don't see why Apple couldn't make those people an offer they can't refuse. That takes them off the market and has them doing something productive.
Yes they can? It's totally possible for a small, well connected, group to be writing small pieces of custom code in very critical applications, like core reactor controls system for navy submarines.
...implying the scrutiny Boeing is held to does anything beneficial.
The regulatory capture resulted in a pathological operating module that put over 346 in an early grave because they couldn't be arsed to not cut corners; then on top of ot all, there's no substantive finding of liability or wrongdoing.
Laws that are ultimately unenforced due to 2B2F might as well not exist at all.
I don't want to defend Boeing's management but even with the worst failure in, what, half a century? it's still much safer to fly than drive so I wouldn't be so quick to throw aviation security culture under the bus.
I think you should really think about what you're saying. Would you cut makers of physical artifacts the same slack, say a small prepared food producer who just can't afford to vet their supply chain or final product to make sure it's not contaminated?
This has already played out. Most consumer software specifies that it cannot be used in medical devices, or for nuclear energy production. So some version of this already exists. But should this apply to video games? Horoscope websites? Random number generators? I'm just pointing out that it isn't a universal argument.
> Even though Apple is the largest company on the planet an entity that has a small fraction of the budget is apparently able to do a better job.
NSO Group is Israeli and (most likely) filled to the brim with former Unit 8200 staff. About the best of the best what the IDF has to offer - they've been said to match the NSA in quality.
> I don't see why Apple couldn't make those people an offer they can't refuse.
For all that can be guessed, they're a semi-private company, deeply connected with the Israeli government [1]. No one can pay these guys enough. If you want them to stop, you'll have to get the Israeli government to agree, and they won't give up any asset that gives them an edge over Iran or its numerous other enemies.
So stop shipping iPhones to Israel until they play ball. If they're that smart they can roll their own phones. These companies do immense damage and endanger lives the world over. Given enough time and budget there is nothing that can't be cracked and it's the very worst actors that have access to this stuff.
As much as I agree with you... I think it's most likely that the US NSA, UK's MI(whatever), Israel's Mossad and a bunch of other secret services all cooperate with each other. No way these guys get taken down, and no way that the sanctions that have been nominally announced actually get enforced at the murky, intransparent bottom layer of the secret services.
Someone has to crack open the phones of drug kingpins, terrorists etc. after all.
So tourists (or people visiting for family or work) who own iPhones wouldn't be able to use them in Israel? You can probably see how that's a tough sell.
Yes, that's exactly it: you harbor this sort of company you will not be able to pretend it's business as usual on other fronts.
After the 500,000th Facebook post of tourists linking NSO to 'my holiday in Israel was spoiled and I won't be going back there' I'm pretty sure they'd get the message.
I'm ok with whitehat hackers but this shit has to stop. Mind you, I have an old Nokia so it's not as if I'm affected, the only thing I have to worry about is the baseband processor and my telco. But there are plenty of people who need a smartphone for their work and their opsec is pretty much as good as their phones' security.
You are severely underestimating the power of an entity like Apple. HN regularly spouts opinions that if US companies don't like the GDPR they should just stop doing business with the EU. That's a massive block of consumers and I highly doubt any company that likes its bottom line is going to take that approach.
But we're talking about one company here that simply should stop selling their crap to the highest bidder. I'm at some level ok with the Israeli's doing what they do, they're no different than any other nation state. But to allow this sort of entity to operate from your soil in a commercial manner, including selling those exploits on the open market where they will inevitably be used against the home country as well seems 'optional' to me and there is a lot of Israelis that like their smartphones.
Why would an entity the size of Apple risk their reputation and everything they stand for to avoid a run-in with a relatively tiny company in a relatively small part of the world that is causing an enormous amount of problems?
That would be an extraordinary act of political activism which is never, ever going to happen. I'd argue it's not a corporation's place to take such an action in the first place. This is, if anything, a diplomatic matter and should be left to the state.
I mean what next, stop selling to the KSA because of their gay rights issues? Iran? Russia? Where does that end? Well, it won't even begin, and rightly so. This is a state matter and they should stay in their lane. They're doing all they can, and should.
BTW, I bet there's more than a few USA organisations who are quietly very annoyed about Apple's relentless bug-fixing. Organisations like NSO are tolerated for a reason.
Ha! Thats some nice fan fiction. Look at how Elon is torpedoing himself even further trying to take on ADL(lets be frank they clearly have ties to Israel). It took far right wing people + Elon bringing the issue up to even have a discussion on pushing back against ADL (and now ADL can just say thats just clearly anti-semetic people being anti-semetic) so the issue is already dead.
Apple being a public company with many institutional portfolios holding their stock would not survive these portfolios dumping their shares due to pressure if they announced this. This could even be enough to force remove Tim Cook from his role. Why would he take such a drastic position?
This rot is at all layers of the western world(UK, Canada, AUS, NZ, France at least). All the way from state governments passing laws saying you cannot boycott Israel or else you'll be barred from contracts(Anti-BDS laws) to congress removing members from their committees if they criticize Israel(eg. Illhan Omar) and signing loyalty pledges to Israel. When ANY new resistance appears against Israel, multiple groups in all of these countries move at light speed to enact a response.
The downsides of having these exploits is clearly acceptable to all the people that make the decisions. And it's not like a regular person can use these exploits against members of congress to make them feel the pain. They'll just 'Julian Assange' you.
What you are proposing requires massive reform at ALL level of government and across the western world as this is not only a US problem. Good luck with that.
This requires changing fundamental beliefs of the majority of people who vote in these governments. They have a special "bond" with Israel and they wont willingly let go of that. You'll be better off just reverse engineering the complete iOS binary and finding every possible exploit.
> It took far right wing people + Elon bringing the issue up to even have a discussion on pushing back against ADL (and now ADL can just say thats just clearly anti-semetic people being anti-semetic) so the issue is already dead.
The issue is dead because Elon's grievance is patently absurd. He's accusing the ADL of singlehandedly engineering a 60% drop in Twitter ad sales. It would be genuine comedy were it not for the fact he's handing a megaphone to the worst-of-the-worst groyper kindernazis.
Thats my point. Pushing back against the ADL is almost impossible and when it finally happens it is associated with these knuckleheads. Therefore it is easy to dismiss...but there are serious abuses done by the ADL (just look up their history) and they now get to skate free.
You seem to be implying the issue is the messenger and his dimwitted minions, when really it's the message itself. If these guys are as nefarious as you're implying, surely the richest man on the planet could dig up something that's not prima facie absurd?
Thanks for clarifying. I'm not familiar enough with this organization to either stake a position for or against, but one passing observation based on that wiki page :
> Right-wing groups and pundits, including right-wing Jewish groups, have criticized ADL as having moved too far to the left under Jonathan Greenblatt, labeling it a "Democratic Party auxiliary"
> In August 2020, a coalition of progressive organizations launched the "Drop the ADL" campaign, arguing that "the ADL is not an ally" in social justice work. The campaign consisted of an open letter and a website, which were shared on social media with the hashtag "#DropTheADL". Notable signatories included the Democratic Socialists of America, Movement for Black Lives, Jewish Voice for Peace, Center for Constitutional Rights, and Council on American–Islamic Relations.[179] The open letter stated that the ADL "has a history and ongoing pattern of attacking social justice movements led by communities of color, queer people, immigrants, Muslims, Arabs, and other marginalized groups, while aligning itself with police, right-wing leaders, and perpetrators of state violence.
Always interesting to see entities criticized for being both too far left and too far right.
To me, the ADL doesn't seem right or left within the US. The evident goal of their org today is to silence criticism of US-Israel relations and run PR for Israel in general, which makes sense given its founding org. That's its own thing, in fact it'd be counterproductive to do it in a partisan way.
> So stop shipping iPhones to Israel until they play ball.
For what purpose? They would still procure iPhones through gray channels and hack them because that's what their victims use. Should Apple also stop selling phones in every other country, because that's where many of NSO's exploits are actually used?
What other purpose? Annoy the local population? Create a grey/black market where you're even more likely to be given a "pre-hacked" unit?
I’m sure there are a lot of committed patriots there but I doubt it’s the whole company. Tim Cook could drop 1% of their cash on hand and see how many of them would turn down a million or two as a signing bonus, and if that didn’t work he could escalate to 10% or toss in some stock. I find it unlikely that wouldn’t tempt a lot of people, especially since the U.S. is one of Israel’s staunchest allies so it’d be pretty easy to tell yourself that pile of cash isn’t selling out.
The real reason they don’t do that is trust: how could you ever be confident that someone wasn’t passing information back to Unit 8200 or even helping them out?
I understood but am skeptical of that - they'd block sale of the entire company but I think it'd be a surprise if they prevented a bunch of Israeli nationals from accepting prestigious jobs with an American company.
Consider as well that designing (known obsolete at the time, with no practical threat to Israel) long range weaponry for a relatively benign enemy (Iraq was never Iran or Egypt) is likely far more forgivable than assisting a far more powerful foreign power with a history of at times cool relations with Israel with the current high priority useful intelligence tool which they are known to have a unusual world class edge in right now.
Gerald Bull was annoying. Someone good leaving any of the APT groups in Israel to help Apple get better security or anyone else would be borderline treason.
NSO seems more like a business. If Israel wanted to, they could pay NSO to keep their software internal/private, no?
The more devices that get exploited, the more exploits that get closed. That's how you lose your edge against your enemies.
Unless they're so confident in their stream of exploits that it's worth burning a few. Or these nation states are buying the devices to operate these exploits and operating them in their security labs...hrmmmmm...
It appears that the Israeli government operates the same way as the Russian government with respect to their private black/gray hat companies and groups: hacking other people is OK, just don't hack our nationals or our institutions, and we're cool. And if they hack companies or people seen as hostile, so much the better.
I don’t understand your comment. Are you saying that involving trial lawyers and US juries to collect big settlements from Apple is going to stop the NSO Group? Or is it that the NSO Group should be liable for the actions of their clients?
I don't understand your comment either. You say you don't understand and then you give a choice between two narrow interpretations neither of which seems to cover what I wrote.
To make this a bit more productive:
If Apple were liable for their defective products then they might decide not to ship them at all until they can be sure enough that the risk of the lawsuits putting them out of business is small enough that they can absorb it.
This worked wonders for other industries (notably: automotive, airlines, medicine). It may slow them down a bit, you may have a wait a bit longer for the next iteration of some gadget. But that's a small price to pay in my opinion.
As for the NSO group: I'm suggesting that Apple use their well filled cash coffers to buy these guys out, and failing that that they use some of that money to sue them for all of the damages that Apple incurs as a result of their actions as well as any criminal charges that they might get to stick. See 'Skylarov'.
It wouldn't be the first time that a US judge finds fault with a foreign company. At a minimum it would slow them and their employees down to the point that they will be in a US jail the next time they visit Disneyland. If it works against illegal gambling operations I see no reason why that sort of mechanism can't be brought to bear against state sponsored hacking groups and their employees.
> If Apple were liable for their defective products then they might decide not to ship them at all until they can be sure enough that the risk of the lawsuits putting them out of business is small enough that they can absorb it.
> This worked wonders for other industries (notably: automotive, airlines, medicine). It may slow them down a bit, you may have a wait a bit longer for the next iteration of some gadget. But that's a small price to pay in my opinion.
That's quite a big price for non life-critical equipment that is a billion times more complex than a pacemaker or the safety-critical parts of an airplane or car.
Pacemakers are one of literally millions of regulated medical devices. If my CPAP fails one night, I don't die, but it's still regulated to ensure it's not gonna fail. You want this to be pacemakers vs Tetris but it's not. It's hearing aids and contact lenses and insulin pumps and wheelchairs and nebulizers and all kinds of devices that will not get you killed if they fail AND YET they are highly regulated and rightly so.
I mean, i assumed from context it was meant regulated in the way life-critical devices are regulated, since the mentioned industries like airlines that have elements that must apply with the regulations life-critical software has to be (e.g. full mc/dc test coverage and what not).
If the goal posts are being moved to regulated in any form, phones already meet this criteria as there exists regulations they are subject to.
So what regulation precisely did you have in mind and would it prevent the issue being discussed?
A billion times more complex than the safety-critical parts of an airplane? I think you lack perspective on avionics packages and the safety measures that are undertaken in that industry. Additionally, I think you're vastly over estimating how complex a smartphone is.
A billion might be hyperoble (although i dont think its a totally unreasonable guess either), but phone software is many GB large, i could easily believe that there are a million more MC/DC points in phone software, than in the safety critical part of airplane software.
> If Apple were liable for their defective products then they might decide not to ship them at all until they can be sure enough that the risk of the lawsuits putting them out of business is small enough that they can absorb it.
I think this works best at that level, like if there’s a sliding scale based on your company’s importance to normal people’s security. I think a lot of developers are worried that their two person consulting team is suddenly liable for bugs but it’s totally reasonable to say that Tim Cook should shake the spare change out of his office couch, call Graydon Hoare into his office and say “here’s a billion dollars, who should we hire so I never hear the phrase ‘buffer overflow’ again?”
That's true, but I'm not entirely sure why this would be relevant to include in my comment? It's just pointing out that other vendors exist in this space other than NSO Group. I don't even see the hypocrisy if I had posted that while working at one of the places I mentioned? How would you rephrase it?
(It seems like you know me, are you someone I've met before?)
If Apple buys NSO Group and shuts it down, other firms are incentivized to enter the market especially because of the prospect of a nice payday if Apple buys the new firm, too.
Anyone buying them and shutting them down won't even temporarily make the problem better, as NSO has competitors who would immediately hire the best people.
The interesting thing is that, as the article states, Lockdown Mode, which is intended for users with exactly that kind of risk profile, does in fact prevent this attack.
the more interesting thing is why the default state has to be made vulnerable in the first place instead of just making lockdown the default method of using an apple device
In Safari, yes, losing the JavaScript JIT is hefty but I’d somewhat cynically argue that it’s probably balanced out performance-wise if you install an ad blocker.
The even more interesting thing is that all functionality increases the attack surface and therefore makes all devices more vulnerable. The most secure state is not to have the device at all or, failing that, to have it permanently turned off. This is true of every device, not just apple.
The reason people possess devices is to use functionality and therefore they have to make some tradeoffs in terms of security. The default state is what apple currently think is the best tradeoff in terms of risk vs functionality for most people. For people with an extremely unusual threat profile it stands to reason a different tradeoff might be appropriate.
That said, they do give a lot of granular control to the user to turn off individual functions if the user feels differently and wants to change their stance eg iMessage can be disabled with a switch in settings.
Honestly I find it a little reassuring that these are the lenghts you have to go to find a reproducible exploit. Granted the failure mode is not great…
Yeah, it’s been too slow but we have come a long way from when any motivated person could find an exploit in a binary file decoder with a day or two of work.
I wrote a patch to fix it that one of the jailbreaks used. I wasn't in the scene, but wanted to protect my ipod touch. So I figured out a patch and gave it to somebody named "pumpkin" on IRC. It's been a long time, but I remember it was fun to learn ARM assembly and figure out how to rewrite the code to get enough space to insert a test and return.
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...
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.
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.
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.
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.
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.
Which actually makes me more sympathetic to Chrome not (yet) adopting JPEG-XL.
Don't get me wrong, I think JPEG-XL is a great idea, but to everyone saying "how can supporting another image format possibly do any harm", this is the answer.
Why not implement all image codecs in a safer language instead?
That would seem to tackle the problem at its root rather than relying on an implementation's age as a proxy for safety, given that that clearly isn't a good measure.
Often it's infeasible to justify rewriting a lot of existing code, but my point is that these days this concern shouldn't really be an obstacle to integrating a new codec.
It should certainly lower the bar of adopting a new codec if the implementation is in a memory-safe language.
Even so, it is more code, and somewhat more risk. Lack of safety elsewhere might end up using code that is otherwise safe in order to build an exploit (by sending it something invalid that breaks an invariant, or building gadgets out of it, etc.).
Adding something in rust into a browser means you now need to bundle all of the needed crates and that your browser now also needs rustc to build… at a minimum.
You also need potentially to audit all the crates and keep them up to date and so on… without crates you can't do so much.
I can see that for components heavily interfacing with high surface area things like encryption, hardware interfacing etc., but why would that be true for a relatively “pure” computational problem like an image codec? Bytes in, bytes out.
RLBox is another interesting option that lets you sandbox C/C++ code.
I think the main reason is that security is one of those things that people don't care about until it is too late to change. They get to the point of having a fast PDF library in C++ that has all the features. Then they realise that they should have written it in a safer language but by that point it means a complete rewrite.
The same reason not enough people use Bazel. By the time most people realise they need it, you've already implemented a huge build system using Make or whatever.
I'd guess it's a combination of labor required to rewrite them and that you'd more or less have to use a safe systems language in order to not have a performance regression
Firefox led a hand in making Rust, so I imagine if there is a browser that can make a more secure browsing experience, it would be Firefox, by making media decoders in Rust.
Almost all people don't want to or aren't capable of implementing image codecs, the safer languages aren't fast enough to do it in, and the people who are capable of it don't want to learn them.
Definitely, but GP was specifically using this as an argument for Google not supporting a codec in Chrome. If anybody can spare the effort to do it safely, it’s them.
Of course as the blog post says, just because memory safety bugs are overcome doesn't mean vulnerabilities have stopped; people find other kinds of vulnerability now.
I don't buy that being able to manually copy data into a memory buffer is critical for performance when implementing image codecs. Nor do I accept that, even if we do want to manually copy data into memory, a bounds check at runtime would degrade performance to a noticeable extent.
"Manually copy data into a memory buffer" is pretty vague… try "writing a DSP function that does qpel motion compensation without having to calculate and bounds check each source memory access from the start of the image because you're on x86-32 and you only have like six GPRs".
Though that one's for video; images are simpler but you also have to deploy the code to a lot more platforms.
I don't dispute that these optimizations may have been necessary on older hardware, but I think the current generation of Apple CPUs should have plenty of power to not need these micro optimizations (and the hardware video decoder would take care of this anyway).
> Why would an iPhone be running x86-specific code?
The same codebase has to support that (since there's Intel Macs and Intel iOS Simulator), and in this case Apple didn't write the decoder (it's Google's libwebp). I was thinking of an example from ffmpeg in that case.
> and the hardware video decoder would take care of this anyway
…actually, considering that a hardware decoder has to do all the same memory accesses and is written in a combination of C and Verilog, I'm not at all sure it's more secure.
It takes a while. At Google at least, new systems in android are required to be built in rust and there are major efforts to rewrite significant systems. But it takes time and rewrites are dangerous in other ways. And you need all the tooling to handle everything else an engineer does beyond simply writing code.
From where I sit, it also feels like the industry has really only coalesced around "the only real solution is safer languages" in the last 2-3 years. "Rewrite it in swift/rust" was way more controversial in 2019. So hopefully we'll see significant progress in the next several years.
How long do you think it is reasonable to go from "we are now in agreement that rewriting stuff is the right call" to "all media processing code is written in a memory safe language"?
Because sandboxing on iOS is terrible. Not that any of the other commercial vendors are any better.
If they could provide good sandboxes do you think the highest security certifications advertised on their website [1][2] would only certify protection against attackers with “basic attack potential”, the lowest possible level. Three whole levels below “moderate attack potential”. I mean, seriously, they certify their security sucks on their website, is it any wonder their security sucks.
No. From a security perspective a Common Criteria certification to the lowest possible level does not establish meaningful security. That is kind of the point.
The companies that develop easily hacked systems that are repeatedly hacked hundreds of times a year like Apple, Microsoft, Cisco, Amazon, Google, etc. can only achieve certification levels indicating they are easily hacked. They have never once succeeded at certifying meaningful security. The certification is pinpoint accurate, just the trillion dollar commercial IT companies do not like the results.
I agree it is largely not a useful differentiator, but that is because all of the commercial IT vendors are certified incompetent. The Common Criteria will not help you determine which fish in the barrel is hardest to shoot. Its job is to distinguish serious security by professionals.
1) Because that takes work
2) Because that makes things a bit slower, so it’s a stand-off between Apple and Google because neither of them wants to be the “laggy” phone
Image decoding can be ported to rust, however most video/image decoding software is rarely ported (performance reasons and what not) - and used as a library instead.
Java would have similar issues as well. It'd be using a compiled C code as an external library in cases like these.
The price of an Android zero-click is now 500k more than the price of an iOS zero-click for Zerodium now. It would appear they have a significant stock of iOS zero-clicks and a lesser amount for Android:
If you flick through the fixes for Android CVEs, you'll notice that there are only a few remote code execution vulns and they're all in C code. The rest are bugs in the Java side but they're all logic bugs and yield exploits like local privilege escalation, or they're privacy issues.
So the Android strategy of using Java a lot definitely seems to have wiped out a lot of memory corruption and RCE bugs. The remainder are a mixed bag and it's hard to imagine any sort of systematic mitigation or fix.
You can't really compare Android and iOS by CVE because iOS isn't open source or distributed to vendors, so Apple fix a lot of security issues without a public CVE ever being created.
I appreciate that a solution is for people to update immediately. It really makes me wonder if my Android phones over the years have had 1-days exploited by the sheer incompetence of the ecosystem in updating phones.
Not much confidence when you get an update with security patches from 2-3 months ago.
I understand that, and I'm partially assessing that in the context of any high targets who might be using the latest Android flagship, that frankly still suffers from the same problem as all Android phones.
> they aren't just flying around hitting random devices.
For the moment, but only until other wankers reverse engineer the security flaws based on the updated 16.6.1 firmware from Apple. After that you too are vulnerable if you haven't updated.
Unless proven by leaked testimonials I would not fully trust GrapheneOS to be fully safe either. Maybe they have zero days as well and we just didn't discover them because of obscurity but NSO bought them and uses them.
My dad used to say "Known devil is better than unknown angel."
Isn't it time we made first messages from all new contacts plain text only, and all other messages some very restricted subset rather than some crazy extensible system that isn't so different from ActiveX?
And on top of that, maybe the whole app should run in a sandbox.
And on top of that, perhaps it should all be a webview to give one more layer of protection.
There is even precedent for doing this seamlessly: the Apple Mail client will not render media from unknown senders without user confirmation. iMessage should have the exact same behavior for the same reasons. It’s frustrating to watch greedy project managers re-learning the exact same lessons that a previous generation already learned the hard way, especially when they all work in the same building.
This is for a different reason (all useful e-mail clients do the same thing!). If Mail (or thunderbird or whatever) loaded the media, then the sender could know you opened the e-mail (by sending each recipient a unique image), leaking information.
Mail does this for privacy, not security. Emails can load remote content and this can be used to track you. This is not generally true of images sent in iMessage because they get sent directly.
Does the Apple Mail client do this for images included with the message (instead of referencing by URL)? Like another comment mentions, this is done for other reasons, and many clients render embedded images by default.
This is very different from ActiveX. ActiveX had hundreds of exploits widely available freely on the dark parts of usenet, and exploited by every proverbial scriptkiddie in a basement against a swath of computers across the world.
iMessage has had a handful of exploits which are licensed out for extortionate amounts by people like NSO to a very small number of scummy nationstate threat actors in extremely targetted but very high-threat attacks on very high-profile targets.
True but a useless fact. One way to interpret u/seanhunter's comment is to make the comparison between imessage and activex in the known exploit space and then extrapolate into the unknown space assuming equal proportions. Seems reasonable to me.
I really don't think that's true - the state of appsec and security awareness in general has really improved a lot, and all of the major platforms (windows included) are much much more secure now by default than in the activeX era.
It's definitely not the case that anyone can just throw together an iPhone zeroday, which is why the price of these exploits is so much higher.
What's not clear to me is given all of the layers/security features Apple has, say you are able to get an iMessage exploit where you can run code... you can't access the file system/cache of other apps (like your banking app to get cookies/tokens), can you?
It means it runs through iMessage. Whether the "turn off iMessage" feature is enough I don't know. But if turning off iMessage actually stops any messages and SMS/MMS etc from running through iMessage at all, it's a pretty decent bet.
Yeah I can't believe we are still seeing this happen over and over again. Whenever you see "zero click" you know it's one of the complex payloads like images, fonts. The answer shouldn't be "don't render images". We should be able to trust that a component that parses external data such as an image, simply can't do anything malicious regardless of input.
If that means sandboxing, fine. If it means having to rewrite all the image parsers from the ground up in a safe language or formally prove them correct, fine. Just get on with it. Apple is rich enough to be able to run their own space program ten times over, I think they could write provably correct imaging libs too.
Your problem isn't the quality of your own code, it's that Google exists and is unable to stop their employees from doing stupid things like inventing WebP, because now you need to support WebP too which means using their code to do it.
(Worse, WebP is at least two completely different formats - the lossless mode has nothing to do with the lossy mode.)
I think Apple should either sandbox or reimplement even the most complex formats. Video formats might be painfully complex to implement, but to avoid zero-click you don't even need to safeguard the whole process. You stop autoplaying and you ensure the safety of the parts that parse the metadata/thumbnails required to show the preview. Then worst case you have at least a 1-click threat when someone plays the video which then calls into some 3rd party code.
a) Google should be doing that in a memory safe language, kinda nuts that they haven't started doing that already
b) Apple could definitely write their own? Unless I'm missing something crazy here, it seems like they could burn 8 figures and just have their own implementations that are safe
They already did - WebP added a lossless mode and VP8 was updated to VP9.
Though the same may happen to JPEG; it always had 10-bit and 12-bit modes but most decoders don't support them. (Not sure if they can decode it as 8-bit or not.)
Rewriting would introduce new bugs; it would take a large number of engineering hours away from delivering shiny new things; and a formally correct version would probably be less power-efficient.
It won't happen because these targeted attacks don't affect the bottom line whatsoever. Nobody is switching to Android just because a journalist or NGO employee occasionally gets pwned.
It doesn’t really matter if there are 100 new bugs for every memory unsafety bug fixed. Those new bugs in an image codec would be hangs/crashes or incorrect rendering and that’s it. And that might be serious but it’s not a security vulnerability.
Yes parsers are already sandboxed, and violating the sandbox boundary is where the actual valuable exploit is. Parser vulns are near worthless without the rest of the chain building on it, and the millions of man-years it would take to re-write every last one of them as "provably correct" is better spent hardening sandbox and privilege boundaries.
Which is a completely different problem than simply rewriting things in a safe language.
What is the cause of the sandbox escape in this case? Somewhere (too high in the stack) there is a C-ish program where someone does pointer arithmetic or an array deref in C which is the same thing.
The security model of a sandboxed process is that even full arbitrary code execution cannot do anything the sandbox says the process cannot do, and the process the parsers run in is sandboxed to only be able to communicate to other processes through very limited interfaces that have no access to network or disk.
Naive question, does apple have any way of detecting and informing users who are current victims of these types of exploits when security fixes are issued?
880 comments
[ 3.4 ms ] story [ 367 ms ] threadMan, iMessage is a security disaster for Apple. No matter how much work they do in other areas, it seems like they'll paying for a while for their decisions around the iMessage architecture.
I take that back, they announced encrypted messaging, then never released it, then probably fired the engineer who said it’d be a feature in allo (or whatever their last attempt was).
Anyway, the competitor of iMessage and Messages is WhatsApp. Nobody is sending me SMSes except banks so even iPhone users use WhatsApp to send messages to friends and to groups in my country. If somebody would insist using only iMessage they would be out of the loop. And about Messages, well, I don't have that app, I receive no SMSes, I still communicate with everybody so I guess that nobody uses Messages too.
The issue (I think) you are referring to is that if you enable iCloud backup[2] or iCloud for Messages[3] (both of which move effectively move the storage of the messages to the cloud, either as part of the device backup or as the canonical representation that devices sync from respectively) then the messages decoded on device will be stored in blobs that iCloud has the keys to unless you enable Advanced Data Protection.
[1]: https://support.apple.com/guide/security/how-imessage-sends-...
[2]: https://support.apple.com/en-us/HT211228
[3]: https://support.apple.com/guide/icloud/what-you-can-do-with-...
Though it can fall back to SMS in case you don't have data, which isn't E2EE. I'm not sure what the UX flow is like in that case, whether it warns you and asks for permission to send over less secure channel.
I was under the impression that this is a 'proprietary' extension between Google devices, and that there was no RCS-standard-based E2EE:
> The RCS specification defines several types of messages. Our implementation of E2EE uses varying strategies for encrypting each type of message to maximize user privacy while still adhering to the RCS specification.
* https://www.gstatic.com/messages/papers/messages_e2ee.pdf
They use "vnd.google.rcs.encrypted" in the Content-Type header.
[0]: https://support.google.com/messages/answer/13508703?sjid=102...
You are confusing security (no exploits) with privacy (encryption). The iMessage system is really private (no third party not even Apple can read your messages) but traditionally full of security holes (messages once decrypted can harm the rest of your device).
I'm not confusing anything. The entire point of the exploits in question are to BREAK the privacy provided by messenger. Google doesn't provide any in the first place, and actively mines your data. Who needs an exploit when it's never encrypted in the first place?
To further this: you realize NSO isn't selling these exploits to Russian kiddies to steal your bank info, right?
These exploits are used by people like the Saudi Government to uncover a Jeff Bezos affair. They're after politicians/power brokers for the purpose of accessing otherwise secure communications for the purpose of stealing state secrets or blackmail.
Someone that can't get a valid subpoena.
Someone that wants to track anything else you do on your phone outside the messaging app.
This is not something that can be stated as fact unless 3rd party clients for a service exist. Apple can, with complete honesty, claim that messages are encrypted at rest/in transit all they want, but since they publish the only implementation of the client, they can modify it at any time to expose the messages to them, in any number of ways.
Edit: Further info: https://googleprojectzero.blogspot.com/2021/01/a-look-at-ime...
It's a miracle that these kinds of zero-click zero-days don't get announced every single week. Though maybe they do, and we just don't know about them...
these exploits aren’t utilized haphazardly - someone has to be willing to pay
I do wish there was a way to turn off automatic downloading of attachments like images etc. from at least non contacts. I think many/most other chat applications, by default, sanitize and/or format images and media on upload on the server by transcoding image data to prevent things like this and save bandwidth (e.g. Facebook/Meta appears to recompress images server side). However, there are obviously security and privacy considerations to doing this, and the client is not exactly something you want to trust to do this, so I can understand why they would be reluctant to implement something like this.
Perhaps this is one potential use of Treacherous (trusted) computing/remote attestation - the client runs a remotely attested signed binary code that will read an image file, encode the pixels as a jpg, and output a signed output that will only be accepted by the server if untampered.
Obviously, there would be issues with that approach as well, but it could potentially prevent the use of the iMessage network to send "crafted" media files.
IMO Apple should make a middle ground Lockdown mode - something that still allows attachments (which Lockdown mode doesn't, making it difficult for many users to employ), but forces them to be 1-click. This is something I would use personally and would at least protect me from getting 0-clicked by attacks like this; I'd never click a Wallet item from an unknown sender, but I also can't live with the restrictions in Lockdown mode.
This is the path that WebKit has followed, and the sandbox for the WebKit JIT is incredibly hard to break through these days
isn't that what Lockdown Mode is for?
Compared to Facebook Messenger where there's one consistent state in the master server and neatly sandboxed web or iPhone app calling it. And yeah, I know these are partially by-products of e2ee vs traditional, and nobody else has really done e2ee messaging with multiple devices.
https://support.apple.com/en-us/HT201222
As far as I know, any parsing code for iMessages should run within the BlastDoor sandbox – is there another vulnerability in the chain that is not reported here?
For context, here's another report from them outlining a similar vulnerability: https://citizenlab.ca/2021/08/bahrain-hacks-activists-with-n...
But it is totally possible for them to have been able only to identify one of them if they didn't intercept the whole attack.
Looks like they just released an update that fixes CVE-2023-41064 at least: https://support.apple.com/en-au/HT213913
Has an iPhone in the lockdown mode been hacked so far, using a zero day vulnerability (not tricking the user to install a malicious program)?
https://techcrunch.com/2023/04/18/apple-lockdown-mode-iphone...
CL link : https://citizenlab.ca/2023/04/nso-groups-pegasus-spyware-ret...
If Apple repeatedly fails at securing their devices from an attack vector that has been demonstrated over, and over, and over... no wonder China is banning government officials from using their devices.
General purpose languages, whether that's something like C or Rust or even Javascript are not the appropriate tool. Turing Completeness is a bad idea from a security point of view, not a wonderful feature.
Well, of course the real issue was the car crash. But wearing a seatbelt would have sure helped!
Swift: A memory-safer systems programming language: https://www.swift.org
Firebloom: A memory-safer C variant: https://support.apple.com/en-il/guide/security/sec30d8d9ec1/...
Not sure what the answer is for existing memory-unsafe code.
It's an engineering approach that involves writing "A buffer overflow issue was addressed with improved memory handling" an awful lot. Hopefully one day they will finish improving the memory handling!
In Rust we can't trivially write a bounds miss by mistake. But in WUFFS we just can't write a bounds miss at all. Like, that's not a thing in WUFFS, it doesn't compile. You can write your own bounds checks and show WUFFS that works, or you can write code which clearly can't have a bounds miss with no checks, that works too. But you can't just "forget" or "screw up" those won't compile.
This would be frustrating in a general purpose language. WUFFS doesn't have a "Hello, World" program because it lacks both strings and the idea of outputing to the screen. But WUFFS isn't a general purpose language, however it's the correct way to write the code that takes image files we got from some dubious source and processes them.
When Apple announced they wanted to provide proper security for vulnerable iPhone users, this is what that would look like coming from a company which actually cared about security. What you got is what it looks like from a company which prioritised marketing.
The Pixel is.
>At least Apple will have it patched within the year of discovery. Can't say the same for other Android vendors.
And the Pixel would have the patch released quicker.
As opposed to proprietary Google code that cannot be vetted?
One device series does not offer a glimpse of the market.
Op’s point stands.
Then what do you call the custom OS that ships on the Pixel? Of course it's a custom built OS that's designed to work with the custom hardware on the Pixel.
>One device series does not offer a glimpse of the market.
Security is defined by the marriage of software and hardware. The reason the Pixel is so secure is because of this. The OP made a blanket statement which did not apply to the Android ecosystem.
This eliminates this whole class of attack.
That's the part that is still unclear with this BLASTPASS business. Surely iOS isn't running the messaging app as a device root, right? There's some other presumably-unpatched privilege elevation attack going on?
I have one friend that absolutely refuses to update his 7-year-old Samsung.
I got the fix on my phones (including my 8), iPads and Watch, today.
That does not make the situation right for Apple.
Do you actually think security is the reason they are being banned? I think the reasons are far more political than technical.
> And the whole reason for the hydrogen burning [by SLS' engines] was to keep the space shuttle contractors jobs. Once again it's not a technical reason but a pork barrel one.
That doesn't mean you can't analyze if a specific technical decision was made primarily on technical grounds/merit or if it is mostly a political one without a technical basis.
You may be right but sometimes the local optics track better when a political reason is given and the local authorities might also expect better compliance with political reasoning. Similarly, "We are getting pwned," never tracks well. There are solid reasons, long ago, why China stopped using Nortel.
Such as?
We can and should improve development practises, mitigate vulnerabities (ASLR, WAFs, etc), isolate systems from each other, and model threats in a way that we know where and how to do those things. It's not easy but just moaning "everything sucks" isn't how to fix it.
Something that many companies are not willing to invest in since it will have a negative impact on the shareholder values.
Often risks are accepted, and cybersecurity insurance is used to mitigate those risks.
And I mean this extremely rhetorically. The software launched along with the iPhone 4S. Going by geekbench, that CPU was 20-30 times weaker than a modern iPhone on a per-core basis.
I know the screens on the new phones are 5x bigger, but there is plenty of room for that sandbox.
but somehow our society still moved everything to digital world and hasn't collapsed yet
meanwhile there are definitely shitton of highly motivated people trying to break systems
so, it is somehow possible to writer *safer* systems
For image decoding in particular, you can put the software into an exceptionally restrictive sandbox, or use a language that builds in the same restrictions.
No I/O. No system calls. Just churn internally and fill a preallocated section of memory with RGBA.
The broader system will still have weaknesses, but it won't have this kind, and this kind keeps happening.
There are virtual machines such as JVM, V8, or even QEMU. These are sandboxes, which run either some special bytecode or native code with extreme performance drawbacks. Media decoders are performance- and energy-sensitive pieces of software in the end.
And media decoders actually ARE sandboxes of sorts. They are designed to interpret media formats, sometimes even Turing-complete bytecode in retrictive and isolated environments. And like any sandboxes, they too have bugs.
> extreme performance drawbacks
That's just not true.
> And media decoders actually ARE sandboxes of sorts. They are designed to interpret media formats, sometimes even Turing-complete bytecode in retrictive and isolated environments. And like any sandboxes, they too have bugs.
It's pretty easy to sandbox a simple bytecode, but that's not the bulk of what a media decoder is doing. A plain old decoder is mostly not sandboxing what it does.
You see how even simple things are difficult to secure when they have to be implemented in practice?
Configuring the IOMMU is one of the easiest parts of doing it in hardware. That's not going to make things "difficult to secure". And allocating the chunk of memory is trivial.
(If you mean they put evil data through it and then used a separate exploit to run it, that's not a vulnerability, that's just "data transfer exists".)
And you seeing someone screw up an IOMMU doesn't disqualify it from being one of the easiest parts of a hardware decoder.
Buffer is reused across calls. Buffer is actually mapped across processes and thus page-aligned. Code to check how much space is needed checks number of pages versus actual number of bytes, and fails to clear leftover data correctly.
Code receives RGBA buffer but expects some other encoding. Accidentally reads out of bounds as a result.
You can definitely say “oh these are stupid and I wouldn’t screw this up” but people do and that’s what really matters.
If you go outside the array you copied/mapped out of the sandbox, then that doesn't let the attacker code escape the sandbox, you just put some of your own data onto the screen.
If you mean the sandbox isn't given enough memory, then that will make the sandbox exit when it hits unmapped addresses.
And how did you screw up length x width x 4?
> Buffer is reused across calls. Buffer is actually mapped across processes and thus page-aligned. Code to check how much space is needed checks number of pages versus actual number of bytes, and fails to clear leftover data correctly.
The sandboxed process doesn't have any way to exfiltrate data. At most it can display it back to you, which is not really any worse than innocent code which could also send back the leftover data.
> Code receives RGBA buffer but expects some other encoding. Accidentally reads out of bounds as a result.
Reads out of bounds and does what with it? That doesn't sound like a vulnerability to me. It might display private data or crash, but that's entirely of its own volition. The behavior would be the same between innocent code in the sandbox and malicious code in the sandbox.
There’s a million ways to screw that up. People botch SCM merges. People are hungover. People are distracted. People are tired. People are heartbroken. People are going through divorces. People have parents dying. People forget numbers. People make copy-paste mistakes. All the time.
> The sandboxed process doesn't have any way to exfiltrate data.
You can abuse it to gain a (known-page-offset) write primitive in the other, non-sandboxed process to which the buffer is also mapped.
But if you do that every image looks wrong and it's vanishingly unlikely to get into a release.
> You can abuse it to gain a (known-page-offset) write primitive in the other, non-sandboxed process to which the buffer is also mapped.
There's no reason to have the memory mapped into both processes at once, and you can't exploit the bytes you write without a real vulnerability.
Since it's a one-shot write into the buffer, if your intent is using it as an exploit step then you might as well encode an actual image with your exploit-assisting bytes.
The code doesn't have to be wrong for every input. It may be wrong just for pathological cases that don't occur in the field unless specifically crafted.
> Since it's a one-shot write into the buffer, if your intent is using it as an exploit step then you might as well encode an actual image with your exploit-assisting bytes.
The assumption was that the code tries to clean up the buffer immediately after use.
I could argue this more but it doesn't matter, that was just a little tangent, getting the size wrong will not let anything out of the sandbox.
> The assumption was that the code tries to clean up the buffer immediately after use.
Cleaning up would be removing the mmap. How are you going to exploit that? Your scenario is not very clear.
I think you're going for a situation where the sandboxed process can write to data in the host process outside the buffer? In a general sense I can imagine ways for that scenario to occur, but I can't figure out how you could get there via mmapping a buffer badly. A buffer mmap won't overlap anything else. If the mmap is too small then either process could read past the end, but would only see its own data (or a page fault).
If a buffer is going to be reused across calls, then cleaning after use is not the same thing as unmapping. One example for cleaning up a buffer after use would be zeroing.
If there's a bug in the calculation for the amount of zeroing needed, then leftover attacker-controlled data can bleed back from the sandboxed into the unsandboxed process and survive beyond the current transaction (because the code failed to zero the buffer correctly after use).
In other words, the attacker can now write arbitrary data into the unsandboxed process's memory at a semi-known location (known page offset) inside the mapped buffer. That data may not be very useful on its own, because it's still confined to the mmapped buffer. But it's now relatively well protected from reuse (until the next decoding task arrives).
That's plenty of time to do shenanigans. For example, you can combine it with an (unrelated) stack buffer overflow that may exist in the unsandboxed process, harmless on its own but more powerful if combined with an attacker-controlled gadget in a known location.
> In other words, the attacker can now write arbitrary data into the unsandboxed process's memory at a semi-known location (known page offset) inside the mapped buffer.
But what is the arbitrary data going to be?
1. If it's gadgets with known lower bits, then you could put that into a plain-old image file, no decoder exploits needed. Also this requires the second dumb mistake of the coder going out of their way to mark the buffer as executable.
2. If it's data you want to exfiltrate, you could just gather that after you trigger your unrelated exploit. This is only useful if everything aligns to drop the private data you want in that specific section of memory, and then the buffer is reused, and then the private data is removed from everywhere else, and then you run an unrelated exploit to actually give you control. This is exceptionally niche.
> harmless on its own
Ha.
Premature optimization is a thing. Most software developers are prone to it in one way or another. They may just assume a performance gain, design accordingly and move on. They may be working under a deadline tight enough so they never even consider checking their assumptions.
Or maybe the developer has actually run the experiment and found that reusing the buffer does yield a few percent of extra performance.
> But what is the arbitrary data going to be?
An internal struct whose purpose is to control the behavior of some unrelated aspect in the unsandboxed process. The struct contains a couple of pointers and, if attacker-controlled, ends up giving them an arbitrary process memory read/write primitive.
It sounds like you picked option 1 then, which means you don't need to take control of the sandbox. "Create an image that put arbitrary bytes into the buffer that stores its decoded form." simplifies to just "Create an image." There is no vulnerability here. This is just image display happening in a normal way. It's something to keep an eye on but not important itself. You have to add a vulnerability to get a vulnerability.
The original problem of preventing image decoding exploits has been solved in this hypothetical.
Your original request was: “If you've seen an exploit caused by a big pre-allocated array of untrusted RGBA data, please explain how.”
> It's something to keep an eye on but not important itself. You have to add a vulnerability to get a vulnerability.
Which is exactly how exploit chains work.
A single vulnerability usually doesn’t achieve something dangerous on its own. But remove it from the chain and you lose your exploit.
I asked that in a context of whether you can contain vulnerabilities in a sandbox. If something doesn't even require a vulnerability, then it doesn't fit.
Also please note the words "caused by". A few helper bytes sitting somewhere are not the cause.
> Which is exactly how exploit chains work.
> A single vulnerability usually doesn’t achieve something dangerous on its own. But remove it from the chain and you lose your exploit.
Being part of an exploit chain doesn't by itself make something qualify as a vulnerability. (Consider arbitrary gadgets already in the program. You can't remove all bytes.) And I've never seen "you can send it bytes" described as a vulnerability before. Not even if you know the bytes will be stored at the start of a page!
A totalitarian regime can have a different, plausible reason: no sufficient control over said devices.
Elaborating on this, the US banning Huawei doesn't help either.
I wonder what phone Z has been using all this time...
[0] https://support.apple.com/en-ca/HT212650
But this isn't a stable solution really. If Lockdown is popularized, NSO obviously will attack the things which are available in Lockdown. Apple shows no sign of only allowing it in Lockdown once it's actually safe - instead they've just arbitrarily decided what to allow and what not to allow.
There may be some zero days that NSO has exploited but it’s nothing like the cluster that is Android.
A lot of phone purchases anymore fall into the fashion side of consumerism. They don't actually care about X, Y or Z new features. They just want to show off that they have the new thing.
Most older devices are unable to run newer apps as the newer SDKs are not present.
2) EU politicians don't know about Android updates because they don't understand how SW works and most probably have iOS anyway. The only time they hear about tech is when some Joe Schmoe insults them on Facebook so they send the courts after Facebook to doxx that person and get Facebook to moderate and ban "hate speech" on their platform. All in a day's work.
Granted, US politicians don't understand how tech works either, judging by the senate hearing of TikTok CEO ("Mr. CEO, can TikTok access my WiFi?"), but they have a powerful local tech industry to tell politicians what they should lobby for, while the EU doesn't.
It's to do with whether Android as a platform is patching older devices.
If they aren't then it may be better for everyone that they are destroyed rather than allowing them to be compromised and exposing security risks to the user.
That wasn’t a bad or mock-worthy question at all. TikTok’s app requests access to devices on the user’s local network. Why does it do that? Officially in order to connect to TVs/speakers, but what else could it decide to do with the access it’s granted?
Of course an app that streams video over the internet can “access wifi”
Huh?
The problem there isn't commercial Android phones, it's open source projects that can't guarantee anything.
iOS 16.6.1 fixes two vulnerabilities known to be actively exploited in the wild - https://news.ycombinator.com/item?id=37423506 - Sept 2023 (7 comments)
What we really need is to just have radically lower bug density. Buffer overflows need to die. UAFs need to be made far less common. The "distance" between vulns needs to be greatly increased. Having design and validation issues sitting smushed between a dozen memory safety issues is just not something you can deal with through software mitigation techniques.
An app like iMessage is just too sensitive (ie: unauthenticated communication with many image parsers) to be built the way that it is. Fundamentally it just can't be safe without core components being rewritten with memory safety in mind. Grsecurity and other mitigations would be an awesome defense in depth and would be particularly helpful to avoid subsequent privescs, but I'm far more concerned with "anyone can text me an image and own me thanks to 1990s style bugs".
Maybe if it's a stack based overflow something like PAX_RANDUSTACK would have had some impact but it depends.
And in case this at all comes off as me thinking anything negative about Grsecurity, I assure you that's not the case. I proudly wear the "Grsecurity Cheerleader" badge that Spender threw my way over a decade ago.
For all the things Israel has done against the US's wishes (like West Bank settlement), the US has struggled to do just one thing Israel doesn't like: the Iran nuclear deal. But at least one of our major parties is somewhat willing to push it. I think they're also somewhat annoyed with our focus on Ukraine.
Israel attempted to maintain some level of neutrality wrt Russia bec when they show preferences, Russia punishes the local Jewish population… which they promptly did as soon as Israel showed any support for Ukraine.
Israel shares a ton of intel with the US regarding many of the local terrorist organizations in the ME. Not to mention they’re flying sorties into Syrian airspace almost nightly. (Infamously Syria AA shot down a russian spy plane, killing 11, thinking they finally caught an Israeli plane)
And Israel’s absence from that symbolic list was likely a precondition to get many of those Arab and African nations on the list. Israel has ISIS locally so there’s no doubt they’re fighting isis.
Finally wrt the Jordan’s west bank: they lost it years ago and it’s so odd you keep calling it that… maybe use the actual name for the area and suddenly Israel’s policy will make sense.
Israel has never fought in any battle involving ISIS or carried out any smaller strikes against them. Some others who aren't in the coalition, like Russia, have. https://en.wikipedia.org/wiki/List_of_wars_and_battles_invol... Their operations in Syria have been against regime forces, Hezbollah, and other targets unfriendly towards Israel, not ISIS.
Even if there's significant ISIS presence in Israel (which I've never heard of), it hasn't convinced them to help fight ISIS next door. Their stance is neutral, and they don't pretend otherwise.
> Israel attempted to maintain some level of neutrality wrt Russia bec when they show preferences, Russia punishes the local Jewish population… which they promptly did as soon as Israel showed any support for Ukraine.
I didn't say there was no reason, because obviously there would be, including trade. They have been allowed to stay mostly neutral.
> Finally wrt the Jordan’s west bank: they lost it years ago and it’s so odd you keep calling it that… maybe use the actual name for the area and suddenly Israel’s policy will make sense.
It's the common name for the region used in America, that's all. I truly don't know what other name you had in mind, but whatever you call it, the US has been unhappy with Israel's policy.
this is simply false. They help a ton and as I've said they've directly attacked them both within Israel's 1919 borders and assisted with attacks elsewhere in the region.
> I didn't say there was no reason, because obviously there would be, including trade. They have been allowed to stay mostly neutral.
so then why bring it up? but again, trade had nothing to do with it, its to protect the innocent people who cannot leave russia and who will be discriminated against due to their religion (much like you are doing right now).
> who will be discriminated against due to their religion (much like you are doing right now)
... and supposedly I'm a bigot if I show you otherwise. Not cool, I'm done here.
Most governments are paying for these services as spying is a recognized arm of statecraft that has actually prevented many wars/conflicts.
But you're right, we don't need that one at all any longer. Someone once told me that Israel would align more closely with Russia if we did that, which is a laughable come back, like, okay? have fun with that.
Retracking the various forms of funding and defense contractor slush funds would be a simple step.
Somewhere in a nondescript subterranean hangar north of vegas an unacknowledged aerial platform is getting an itchy nose
A getaway driver is involved after the crime is committed. To assign the same level of culpability to a tool-maker would imply that they have the ability to predict the future.
A better example would be a car or firearm manufacturer. How the tool is used is up to the user.
Software doesn't root people's phones, cops and spies do. Someone sent that iMessage, and it wasn't the author of the software.
this is a problem of all nation states wanting this kind of service, not of israel in particular.
I tip my hat to CitizenLab and the good work they do.
[1]: https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
Is it the FreeBSD boot message?
> Last week, while checking the device of an individual employed by a Washington DC-based civil society organization with international offices, Citizen Lab found an actively exploited zero-click vulnerability being used to deliver NSO Group’s Pegasus mercenary spyware.
Check out The Palestine Laboratory: How Israel Exports the Technology of Occupation Around the World
Regardless, sanctions don’t, and never have, actually solved anything. We just ignore the data because no one has a better idea.
NSO group will be its own worst enemy anyways as greed leads them into bed with the wrong people.
I'd hope they're at least targeting their own customers as part of state-sanctioned operations. Still, that doesn't justify the dissidents they indirectly facilitate being thrown under the bus. Or on the receiving end of a bone saw, as another commenter put it.
* I was going to say "sanctioned," but that word can mean two entirely opposite things, it's dumb
The regulatory capture resulted in a pathological operating module that put over 346 in an early grave because they couldn't be arsed to not cut corners; then on top of ot all, there's no substantive finding of liability or wrongdoing.
Laws that are ultimately unenforced due to 2B2F might as well not exist at all.
NSO Group is Israeli and (most likely) filled to the brim with former Unit 8200 staff. About the best of the best what the IDF has to offer - they've been said to match the NSA in quality.
> I don't see why Apple couldn't make those people an offer they can't refuse.
For all that can be guessed, they're a semi-private company, deeply connected with the Israeli government [1]. No one can pay these guys enough. If you want them to stop, you'll have to get the Israeli government to agree, and they won't give up any asset that gives them an edge over Iran or its numerous other enemies.
[1] https://en.wikipedia.org/wiki/NSO_Group#Relationship_with_th...
Someone has to crack open the phones of drug kingpins, terrorists etc. after all.
After the 500,000th Facebook post of tourists linking NSO to 'my holiday in Israel was spoiled and I won't be going back there' I'm pretty sure they'd get the message.
I'm ok with whitehat hackers but this shit has to stop. Mind you, I have an old Nokia so it's not as if I'm affected, the only thing I have to worry about is the baseband processor and my telco. But there are plenty of people who need a smartphone for their work and their opsec is pretty much as good as their phones' security.
Trying to hide a hardware device that's sold in billions is not going to happen.
But we're talking about one company here that simply should stop selling their crap to the highest bidder. I'm at some level ok with the Israeli's doing what they do, they're no different than any other nation state. But to allow this sort of entity to operate from your soil in a commercial manner, including selling those exploits on the open market where they will inevitably be used against the home country as well seems 'optional' to me and there is a lot of Israelis that like their smartphones.
Why would an entity the size of Apple risk their reputation and everything they stand for to avoid a run-in with a relatively tiny company in a relatively small part of the world that is causing an enormous amount of problems?
If we had made Iraq a powerful ally, it would have weakened support for Israel but that whole area of the world is too embroiled in conflict.
I mean what next, stop selling to the KSA because of their gay rights issues? Iran? Russia? Where does that end? Well, it won't even begin, and rightly so. This is a state matter and they should stay in their lane. They're doing all they can, and should.
BTW, I bet there's more than a few USA organisations who are quietly very annoyed about Apple's relentless bug-fixing. Organisations like NSO are tolerated for a reason.
Apple being a public company with many institutional portfolios holding their stock would not survive these portfolios dumping their shares due to pressure if they announced this. This could even be enough to force remove Tim Cook from his role. Why would he take such a drastic position?
This rot is at all layers of the western world(UK, Canada, AUS, NZ, France at least). All the way from state governments passing laws saying you cannot boycott Israel or else you'll be barred from contracts(Anti-BDS laws) to congress removing members from their committees if they criticize Israel(eg. Illhan Omar) and signing loyalty pledges to Israel. When ANY new resistance appears against Israel, multiple groups in all of these countries move at light speed to enact a response.
The downsides of having these exploits is clearly acceptable to all the people that make the decisions. And it's not like a regular person can use these exploits against members of congress to make them feel the pain. They'll just 'Julian Assange' you.
What you are proposing requires massive reform at ALL level of government and across the western world as this is not only a US problem. Good luck with that.
This requires changing fundamental beliefs of the majority of people who vote in these governments. They have a special "bond" with Israel and they wont willingly let go of that. You'll be better off just reverse engineering the complete iOS binary and finding every possible exploit.
[1]:https://en.wikipedia.org/wiki/Anti-BDS_laws
[2]:https://en.wikipedia.org/wiki/Ilhan_Omar#Remarks_on_AIPAC_an...
[3]:https://apnews.com/article/israel-republican-vote-pramila-ja...
The issue is dead because Elon's grievance is patently absurd. He's accusing the ADL of singlehandedly engineering a 60% drop in Twitter ad sales. It would be genuine comedy were it not for the fact he's handing a megaphone to the worst-of-the-worst groyper kindernazis.
[1]:https://en.wikipedia.org/wiki/Anti-Defamation_League#Recepti...
> Right-wing groups and pundits, including right-wing Jewish groups, have criticized ADL as having moved too far to the left under Jonathan Greenblatt, labeling it a "Democratic Party auxiliary"
> In August 2020, a coalition of progressive organizations launched the "Drop the ADL" campaign, arguing that "the ADL is not an ally" in social justice work. The campaign consisted of an open letter and a website, which were shared on social media with the hashtag "#DropTheADL". Notable signatories included the Democratic Socialists of America, Movement for Black Lives, Jewish Voice for Peace, Center for Constitutional Rights, and Council on American–Islamic Relations.[179] The open letter stated that the ADL "has a history and ongoing pattern of attacking social justice movements led by communities of color, queer people, immigrants, Muslims, Arabs, and other marginalized groups, while aligning itself with police, right-wing leaders, and perpetrators of state violence.
Always interesting to see entities criticized for being both too far left and too far right.
For what purpose? They would still procure iPhones through gray channels and hack them because that's what their victims use. Should Apple also stop selling phones in every other country, because that's where many of NSO's exploits are actually used?
What other purpose? Annoy the local population? Create a grey/black market where you're even more likely to be given a "pre-hacked" unit?
I’m sure there are a lot of committed patriots there but I doubt it’s the whole company. Tim Cook could drop 1% of their cash on hand and see how many of them would turn down a million or two as a signing bonus, and if that didn’t work he could escalate to 10% or toss in some stock. I find it unlikely that wouldn’t tempt a lot of people, especially since the U.S. is one of Israel’s staunchest allies so it’d be pretty easy to tell yourself that pile of cash isn’t selling out.
The real reason they don’t do that is trust: how could you ever be confident that someone wasn’t passing information back to Unit 8200 or even helping them out?
Unless they were already friends enough to not need to worry much about cost.
2) any company doing that would have to be insanely naive or reckless.
2. Indeed: that’s my second paragraph above.
Gerald Bull was annoying. Someone good leaving any of the APT groups in Israel to help Apple get better security or anyone else would be borderline treason.
The more devices that get exploited, the more exploits that get closed. That's how you lose your edge against your enemies.
Unless they're so confident in their stream of exploits that it's worth burning a few. Or these nation states are buying the devices to operate these exploits and operating them in their security labs...hrmmmmm...
To make this a bit more productive:
If Apple were liable for their defective products then they might decide not to ship them at all until they can be sure enough that the risk of the lawsuits putting them out of business is small enough that they can absorb it.
This worked wonders for other industries (notably: automotive, airlines, medicine). It may slow them down a bit, you may have a wait a bit longer for the next iteration of some gadget. But that's a small price to pay in my opinion.
As for the NSO group: I'm suggesting that Apple use their well filled cash coffers to buy these guys out, and failing that that they use some of that money to sue them for all of the damages that Apple incurs as a result of their actions as well as any criminal charges that they might get to stick. See 'Skylarov'.
It wouldn't be the first time that a US judge finds fault with a foreign company. At a minimum it would slow them and their employees down to the point that they will be in a US jail the next time they visit Disneyland. If it works against illegal gambling operations I see no reason why that sort of mechanism can't be brought to bear against state sponsored hacking groups and their employees.
> This worked wonders for other industries (notably: automotive, airlines, medicine). It may slow them down a bit, you may have a wait a bit longer for the next iteration of some gadget. But that's a small price to pay in my opinion.
That's quite a big price for non life-critical equipment that is a billion times more complex than a pacemaker or the safety-critical parts of an airplane or car.
I broke my phone once. I did not die in the next five minutes
If the goal posts are being moved to regulated in any form, phones already meet this criteria as there exists regulations they are subject to.
So what regulation precisely did you have in mind and would it prevent the issue being discussed?
I think this works best at that level, like if there’s a sliding scale based on your company’s importance to normal people’s security. I think a lot of developers are worried that their two person consulting team is suddenly liable for bugs but it’s totally reasonable to say that Tim Cook should shake the spare change out of his office couch, call Graydon Hoare into his office and say “here’s a billion dollars, who should we hire so I never hear the phrase ‘buffer overflow’ again?”
(It seems like you know me, are you someone I've met before?)
The vast majority of the NSO's work is stuff you would not object to, but that's boring and doesn't qualify as news.
https://support.apple.com/en-us/HT212650
This is a classic challenge for security: every feature expands the attack surface, but users often pick what to buy based on those features.
The reason people possess devices is to use functionality and therefore they have to make some tradeoffs in terms of security. The default state is what apple currently think is the best tradeoff in terms of risk vs functionality for most people. For people with an extremely unusual threat profile it stands to reason a different tradeoff might be appropriate.
That said, they do give a lot of granular control to the user to turn off individual functions if the user feels differently and wants to change their stance eg iMessage can be disabled with a switch in settings.
Amnesty International has a program on GitHub with Citizens Lab for those keeping an eye out for additional protections
https://github.com/mvt-project/mvt
MVT (Mobile Verification Toolkit) helps with conducting forensics of mobile devices in order to find signs of a potential compromise.
I wrote a patch to fix it that one of the jailbreaks used. I wasn't in the scene, but wanted to protect my ipod touch. So I figured out a patch and gave it to somebody named "pumpkin" on IRC. It's been a long time, but I remember it was fun to learn ARM assembly and figure out how to rewrite the code to get enough space to insert a test and return.
More employees than the smallest 60 countries.
https://www.mediaite.com/tv/tim-cook-silent-fox-reporter-con...
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.
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.
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.
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.
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.
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.
Don't get me wrong, I think JPEG-XL is a great idea, but to everyone saying "how can supporting another image format possibly do any harm", this is the answer.
That would seem to tackle the problem at its root rather than relying on an implementation's age as a proxy for safety, given that that clearly isn't a good measure.
Even so, it is more code, and somewhat more risk. Lack of safety elsewhere might end up using code that is otherwise safe in order to build an exploit (by sending it something invalid that breaks an invariant, or building gadgets out of it, etc.).
You also need potentially to audit all the crates and keep them up to date and so on… without crates you can't do so much.
RLBox is another interesting option that lets you sandbox C/C++ code.
I think the main reason is that security is one of those things that people don't care about until it is too late to change. They get to the point of having a fast PDF library in C++ that has all the features. Then they realise that they should have written it in a safer language but by that point it means a complete rewrite.
The same reason not enough people use Bazel. By the time most people realise they need it, you've already implemented a huge build system using Make or whatever.
Google has contributed lots of fuzzing time and security improvements to eg ffmpeg already.
Of course as the blog post says, just because memory safety bugs are overcome doesn't mean vulnerabilities have stopped; people find other kinds of vulnerability now.
I don't buy that being able to manually copy data into a memory buffer is critical for performance when implementing image codecs. Nor do I accept that, even if we do want to manually copy data into memory, a bounds check at runtime would degrade performance to a noticeable extent.
Though that one's for video; images are simpler but you also have to deploy the code to a lot more platforms.
I don't dispute that these optimizations may have been necessary on older hardware, but I think the current generation of Apple CPUs should have plenty of power to not need these micro optimizations (and the hardware video decoder would take care of this anyway).
The same codebase has to support that (since there's Intel Macs and Intel iOS Simulator), and in this case Apple didn't write the decoder (it's Google's libwebp). I was thinking of an example from ffmpeg in that case.
> and the hardware video decoder would take care of this anyway
…actually, considering that a hardware decoder has to do all the same memory accesses and is written in a combination of C and Verilog, I'm not at all sure it's more secure.
From where I sit, it also feels like the industry has really only coalesced around "the only real solution is safer languages" in the last 2-3 years. "Rewrite it in swift/rust" was way more controversial in 2019. So hopefully we'll see significant progress in the next several years.
If they could provide good sandboxes do you think the highest security certifications advertised on their website [1][2] would only certify protection against attackers with “basic attack potential”, the lowest possible level. Three whole levels below “moderate attack potential”. I mean, seriously, they certify their security sucks on their website, is it any wonder their security sucks.
[1] https://support.apple.com/guide/certifications/ios-security-...
[2] https://support.apple.com/library/APPLE/APPLECARE_ALLGEOS/CE...
Plus, it’s not really worth getting certified at a higher level than you need. Why expend extra effort?
The companies that develop easily hacked systems that are repeatedly hacked hundreds of times a year like Apple, Microsoft, Cisco, Amazon, Google, etc. can only achieve certification levels indicating they are easily hacked. They have never once succeeded at certifying meaningful security. The certification is pinpoint accurate, just the trillion dollar commercial IT companies do not like the results.
I agree it is largely not a useful differentiator, but that is because all of the commercial IT vendors are certified incompetent. The Common Criteria will not help you determine which fish in the barrel is hardest to shoot. Its job is to distinguish serious security by professionals.
Java would have similar issues as well. It'd be using a compiled C code as an external library in cases like these.
So for those keeping score, is Android now ahead of iOS in this aspect of security?
They have regular security releases that often patch critical vulnerabilities such as https://source.android.com/docs/security/bulletin/2023-08-01
The bigger issue with Android IMO is you might not get the patches right away depending on your device and it’s age.
[0] https://www.cvedetails.com/vulnerability-list/vendor_id-1224...
https://zerodium.com/program.html
If you flick through the fixes for Android CVEs, you'll notice that there are only a few remote code execution vulns and they're all in C code. The rest are bugs in the Java side but they're all logic bugs and yield exploits like local privilege escalation, or they're privacy issues.
So the Android strategy of using Java a lot definitely seems to have wiped out a lot of memory corruption and RCE bugs. The remainder are a mixed bag and it's hard to imagine any sort of systematic mitigation or fix.
You can't really compare Android and iOS by CVE because iOS isn't open source or distributed to vendors, so Apple fix a lot of security issues without a public CVE ever being created.
Not much confidence when you get an update with security patches from 2-3 months ago.
/s
For the moment, but only until other wankers reverse engineer the security flaws based on the updated 16.6.1 firmware from Apple. After that you too are vulnerable if you haven't updated.
Then there's the issue of privacy regarding Google devices.
I strongly suggest checking out the GrapheneOS project if Android security is of concern.
My dad used to say "Known devil is better than unknown angel."
Apple itself pays $1-million for bug bounties of this type.
https://security.apple.com/bounty/categories/
other 0-days for iphone up to around 2 million
[1] http://zerodium.com/program.html
I’m, in no way, a security savvy but the above achievement must be a lot of work by the NSO group!
Isn't it time we made first messages from all new contacts plain text only, and all other messages some very restricted subset rather than some crazy extensible system that isn't so different from ActiveX?
And on top of that, maybe the whole app should run in a sandbox.
And on top of that, perhaps it should all be a webview to give one more layer of protection.
iMessage has had a handful of exploits which are licensed out for extortionate amounts by people like NSO to a very small number of scummy nationstate threat actors in extremely targetted but very high-threat attacks on very high-profile targets.
It's definitely not the case that anyone can just throw together an iPhone zeroday, which is why the price of these exploits is so much higher.
Apple hired at least a few of the best jailbreakers.
EDIT: found it. For anyone who's interested:
> Turn off iMessage:
> On your iPhone, go to Settings.
> Tap Messages.
> Set iMessage to Off.
This a zero-click exploit, which means you don't even have to open the message to get hacked.
If that means sandboxing, fine. If it means having to rewrite all the image parsers from the ground up in a safe language or formally prove them correct, fine. Just get on with it. Apple is rich enough to be able to run their own space program ten times over, I think they could write provably correct imaging libs too.
(Worse, WebP is at least two completely different formats - the lossless mode has nothing to do with the lossy mode.)
a) Google should be doing that in a memory safe language, kinda nuts that they haven't started doing that already
b) Apple could definitely write their own? Unless I'm missing something crazy here, it seems like they could burn 8 figures and just have their own implementations that are safe
Though the same may happen to JPEG; it always had 10-bit and 12-bit modes but most decoders don't support them. (Not sure if they can decode it as 8-bit or not.)
It won't happen because these targeted attacks don't affect the bottom line whatsoever. Nobody is switching to Android just because a journalist or NGO employee occasionally gets pwned.
Which is a completely different problem than simply rewriting things in a safe language.
But for the last one, it's the difference between https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i... (parser vulnerability leading to not-really arbitrary code execution and memory corruption) and https://googleprojectzero.blogspot.com/2022/03/forcedentry-s... (logic errors leading to a sandbox escape) Notably, the sandbox escape itself did not use anything that would have been prevented by a memory safe language.
The security model of a sandboxed process is that even full arbitrary code execution cannot do anything the sandbox says the process cannot do, and the process the parsers run in is sandboxed to only be able to communicate to other processes through very limited interfaces that have no access to network or disk.
As of iOS 14, incoming messages are parsed in a tight sandbox [2]. It'll be interesting to hear how this attack got around that.
[1] https://en.wikipedia.org/wiki/JailbreakMe
[2] https://googleprojectzero.blogspot.com/2021/01/a-look-at-ime...
And there have definitely been UTF-8 parsing bugs before and likely will again.