NSO group iPhone zero-click, zero-day exploit captured in the wild
citizenlab.ca
citizenlab.ca
I just want to add this: these people operate pretty much in the open. They're not ashamed of it either, or else they wouldn't put it on their CV:
https://www.linkedin.com/company/nso-group/people/
That right there tells me that we as "the tech community" are way too okay with this sort of application of the tech. The tech we're all so convinced will "make the world a better place." /s
But for Hungary - I've been there multiple times in the last few years, know a few people, and I have no trouble believing he won democratic elections.
"Any customer can have a car painted any color that he wants so long as it is black."
It was another country, we still don’t know which one it was but some think it was Morocco.
There's no reason to expect the world to disarm any time soon, so the best approach is to be aware and democratically influence policy, rooting out bad ideas and bad actors.
Israel is constantly trying to woo Saudi Arabia so that they can be allies during a potential war with Iran. Israel will definitely sacrifice some human rights activists just for the ability to cross the Saudi airspace. But it has not been going well for Israel lately.
That may be true, but these companies (NSO group is by no means worse than the rest of them, just more notorious) have been caught over and over again, selling these "weapons" to dictators, companies, etc, who in turn use them to spy on journalists and activists, not terrorists or anything of the sort. And that doesn't even go into keeping 0-days for the benefit of the few, keeping literally everyone on the planet less safe, which is arguably as big an issue, if more systemic.
These companies may exist in some form or another because the nation state & private surveillance systems that form their client base want them to exist.
But my point is that the individuals working at this company should be ashamed of themselves. I'm not appealing to their sense of morals, I'm talking purely about "us the tech community" making it abundantly clear that having one of these companies on your CV will make it very hard to find any decent job afterwards. It needs to be socially expensive to work there. To loan from Max Goldt's opinion on the BILD newspaper [1]:
> NSO Group and the like are an organ of infamy. It is wrong to use their products. Someone who contributes to these products is absolutely socially unacceptable. It would be remiss to be friendly or even polite to any of their developers or managers. One must be as unkind to them as the law will just allow. They are bad people who do wrong.
[1]: https://www.goodreads.com/quotes/6758128-die-bild-zeitung-is...
In short - you have a point, but it's not quite that simple.
However, those who develop the NSO spyware are middle class Israeli citizens who easily could get a well-paying job at a less repugnant company. There are no extenuating circumstances, no "had to put food on my table", no claims of being fooled/brainwashed. They 100% deserve to be punished and they 100% deserve our disgust.
The person saying that they're only staying to murder with their families because they care about them is not a redeeming quality, and they should definitely be held accountable and not excused for their crimes.
For the record, I consider any armed person outside their home country should be considered as a terrorist and a militia and treated as such. There is no reason someone from country A should be carrying a weapon in country B and attacking people there. This is 100 times even more valid when country B has not authorized this.
> I consider any armed person outside their home country should be considered as a terrorist and a militia
I mean, there are situations like hostage crises where foreign countries send in soldiers that I think are completely justified. But, I agree, in general. Our foreign policy has been fucked since the CIA started after WWII. I'm just grateful I never had to fight a war- chances are I would've being born in the last couple hundred years
There was a lot of media propaganda to make the war popular. It wasn't at first but it didn't even take half a year until people ate it up. Liberal, conservative, didn't even matter. It was scary to see how quickly people were manipulated. It had large support in the population. People should stop and reflect what made them support the war, which messages and by whom. That is the responsibility they can take here and it would be much more constructive than putting the blame on soldiers...
Israel citizens might have a better excuse to develop weapons than most other countries, so I don't see the point. Not an excuse, but at least an explanation.
The problem is that by walling off developers who participate in these activities, we essentially force them to continue these activities. I'm not sure that's net positive.
Meanwhile, a nice silent worm propagates among their network... I have 0-faith that the version they have sold to bad actors is clean when they probably are begging you to take their software into your internal network.
1. There's no compelling reason to think that this applies in NSO's case, since a lot of the bad actors are geopolitically aligned with "good" governments.
2. One needs only study the cold war briefly to see how the group-think in these unaccountable environments can become completely detached from reality.
Pardon me if I'm skeptical of unaccountable officials making those decisions, and orders of magnitude more skeptical of random people on the internet alluding to such actions as if we can all just assume abuses are justified by unspecified good ends.
They should be ashamed of themselves, but you are still barking at the wrong tree in the long run. You should demand your own government to outlaw this type of surveillance.
You have that reversed. Recent Iranian regimes have been especially hostile toward Israel, but that's nowhere near as longstanding an enmity as Saudi/Iran.
That was true 15 years ago … I don‘t hear this often anymore.
The same is true today. Eg LLMs have huge potential. What worries me are the sociopaths who draw the same conclusion.
The only concern I have is greed from landlords and medical practitioners.
The cost of resources has plummeted, the cost of scarce things (land and medical licenses) continue to go up.
(Although limited medical licensees is a US corruption thing, its not inherent)
It looks like NSO is backed up by the Israeli government. They say their software is only sold to governments which were previously vetted, but the reality is that most of the time they sell to authoritarian states which monitor and persecute people opposing the regime.
It generally continues to be immoral and illegal when governments do it. Except it also becomes more outrageous, because governments are supposed to protect us from this sort of thing.
The government is given power over people in order to protect us from other people and this is one tool to do it. They have cops with guns and soldiers with tanks, they can break in, search and seize, they can lock people in prison. All of these things are tools and it's they way they're used that decides what's immoral or outrageous.
The bigger problem here is that a private company has these tools and can use and sell then with no oversight.
However, they look very different. The major distinction is that when a private party requests an injunction allowing them to e.g. trespass on their neighbor’s land, the court will require notice and a hearing for the defendant. So, if a chemical plant needs to do earth works on a neighbor’s land to prevent a collapse, etc. the judiciary may well issue an order requiring the neighbor to let the company enter.
Frankly, notice and hearing should probably be required for some criminal warrants too. I can think of a few indictments and arrest warrants that have recently been issued where there is a genuine question as to probable cause and the alleged illegality of the conduct. It’s not fair for people who are not a flight risk to be arrested (and often imprisoned) with no opportunity to defend themselves.
Indeed, legally, private individuals and companies are allowed to act in emergencies. For example, I generally should not break into my neighbor’s home. However, I am legally allowed (and morally obligated) to forcibly enter their residence if their house is on fire, or they’re being attacked by a burglar, etc. and I am able to prevent some of the harm.
Of course, if we assume we’re talking about situations where the government needs a warrant, the legality becomes more complicated. At what point does something become an emergency? I would say it’s not an emergency if there is time to inform the government and to let the government prevent the injury. If we assume the government is unwilling or unable to act, then the window for action should expand by some measure.
Private companies having arrest rights is just a nonstarter of an idea (putting it kindly).
https://en.wikipedia.org/wiki/Citizen%27s_arrest#United_Stat...
How far do you really expect any tech outfit to vet the legitimacy of the warrants issued?
https://freedomhouse.org/countries/freedom-world/scores
My point being that there’s precedent for restrictions - we don’t sell nukes to anyone, and the companies which make advanced weapons systems have to get things like ITAR approvals. What would be especially powerful would be revocation: if a country is found abusing their access to this tool, they are blocked from purchases of any sort for a decade. Unfortunately, given Israel’s current politics it’s extremely unlikely that anything would happen since there’s no way to write a policy which would continue to allow their own usage.
This strategy mostly works because the major operating system suppliers refuse to implement requested lawful intercept solutions for their consumer products. Instead, we end up with companies that try to fill the gaps, making a business of exploiting security flaws. It's possible for the OS vendors to completely dry this swamp, by offering competing services to law enforcement using the interfaces they already have (automated software updates, for example). The reputable clients would migrate rather quickly. These companies would be left with just the shady clients, making it much more difficult to justify their continued existence.
That is a slippery slope though, because the OS vendors could offer Law Enforcement everything today, and there will be a special request made for a little something extra tomorrow.
os-vendors are predominiantly us-american and the rest of the world has to get their lawful interception on the free market, no?
No way any reputable OS vendor would agree to enable, for example, Dutch intelligence services spying on Russian citizens living in the UK.
I don't even need to invent a scenario for this: you can buy the TSA master keys off Amazon right now. The only reason why it's not a huge problem is that TSA locks are a special thing you buy and use solely for airline luggage that is already in TSA custody anyway. If you use TSA locks on anything else, however, you're just asking for it to be stolen because the locks don't actually provide any security.
The shady clients will get their hands on any intercept key provided by law enforcement, because it's legally unreasonable for Apple or Google to only provide intercept capability to some of the countries they operate in. e.g. if you give the US and UK a decryption key you also have to give it to Saudi Arabia[0]. Hell, in some countries the shady and legit clients are part of the same government - e.g. you can't give the key to just the FBI but not the NSA or CIA.
[0] The Saudis have one very big lever they can use to force the west to do what it wants: gas prices.
The United States gets most of its petroleum from Canada.
Saudi Arabia accounts for only 7% of U.S. petroleum and crude oil imports.
Source: https://www.eia.gov/energyexplained/oil-and-petroleum-produc...
2nd is Saudi Arabia then Russia. However it happens that US is also the largest consumer and their production doesn't meet the demand so they have to import from other countries like Canada and Saudi Arabia
So Saudi Arabia most definitely does have a lever, and so does Russia since the rest of the world including US allies like Japan, South Korea, Australia, NATO countries depend on their lovely black gold to have functioning economies.
https://www.api.org/news-policy-and-issues/blog/2018/06/14/w....
Have you been following the news for the past two years? Russia's sanctioned up the wazoo. No NATO country is buying Russian oil. India is now their number one costumer.
https://www.aljazeera.com/amp/news/2023/5/16/eu-to-curb-indi...
If the US was like Saudi Arabia where they exported half of their oil, and could supply most of the world at competitive prices, Russia would have really felt the Sanctions.
But right now Russia doesn’t feel the Sanctions. They’re more isolated and Putin’s propaganda has somewhat worked at making the general population anti-west and support the Ukraine invasion.
NSO Group is bad because they have been caught selling to oppressive regimes and allegedly actively supported (and potentially continue to support) the deployment of their software for oppressive regimes to harm innocent civilians. They should be (and iirc are) sanctioned for their bad behaviors, bad intentions, and mishandling of their responsibilities.
* There are plenty of caveats (e.g. the seller & buyer need to have good intentions and only plan to use the malware in accordance with the law). I am not a lawyer and this is not legal advice.
Just because you got a paycheck for it doesn't suddenly make the behavior ethical.
This calls for a larger discussion of individual choices of every one of us. It would not be an easy discussion, because things are far from simple, and yet every one of us should actively think, instead of falling into the whataboutism trap and doing nothing.
For example, there are probably thousands of tech people in Russia right now either breaking into Ukrainian systems or writing software for missiles, drones, targeting systems, etc. These systems do not write themselves. Each of those people should ask themselves if this is really what they should be doing. I am certainly asking myself if I want to ever work with people who were complicit in these crimes (and how will I know?).
I know some people who pledged to never work on any military systems. I was close to that point of view, until Russia started dropping bombs on my Ukrainian friends. Now I don't see it quite in the same light anymore.
Similarly, the NSO group is not an amorphous entity, PEOPLE work there and write these exploits. In each case, it is a conscious decision.
My point is that we can't abstract tech from moral choices. There is always right and wrong, there is always the right thing to do. It might not be universally applicable, and there will always be endless discussions on HN ("but what about..."), but each of us can and should think about how our work is applied.
I don't know if I would have courage to stop working in Russian military IT tech if I were a sole provider for a family of three.
We wear sun screen and maybe get pissed if the sun screen company is not doing a good job. But go ahead yell at the sun. Those dam UV rays!!!
Just like bad guys are always gonna be there, so will the bugs.
I wonder why you expect it to be like that.
In reality, "the tech community" is extremely diverse and not cohesive at all.
For one example, a large proportion of developers are barely making enough money to pay their most basic bills. They don't have enough mental space to even know what NSO is...
I really dislike this phrasing "the X community" which seems to be so popular nowadays. Lumping together many millions of people worldwide who have a single thing in common–how did people end up using the word "community" to describe that?
Top comment (+50 comments): Why do we talk about Apple so much and so little about NSO group.
The absurdly pro-Apple PR on HN is tough to bear. I have to say it's so overt it made me more hostile to Apple (NSO is obviously a worthy topic, but we do discuss it).
Plenty of these comments are about NSO. And that's fine! But trying to catch every blackhat won't solve our security problems. Ultimately, the only solution to these security holes is more secure software, and the only way to get that is to pressure Apple to invest more resources. The main question should be how come 'secure' Apple software keeps having 0-click exploits.
Pressuring Microsoft led them to adopt a much more secure culture compared to previously. Apple shouldn't be exempt from the same pressure.
Imagine you own a infosec company and an applicant with excellent skills applies. You look at the CV in detail before the interview and you see that they proudly declare their NSO background. Tell me what will you do? Cancel the interview? How comfortable would you be to deny the applicant a job for that reason alone?
I would wager the majority would consciously hire them out of fear of blowback and most of the remainder would unconsciously suppress their opinions on the NSO.
Imagine having a business handling privacy relevant data and when someone asks about your stance on data security you have to admit you hired people who are okay with keeping the whole planet insecure for their own benefit.
I know, I know, in my more cynical moments I see it your way as well. But that doesn't make it right.
For once, I am not okay with what they are doing, and I've started to fight them actively.
You're welcome to join.
If Snowden and Assange can be extradited to the US and tried for crimes, executives of NSO group absolutely should as well. Lock 'em up!
Apple could pay all these people and companies way more than they could ever hope to earn on the free world market to simply fuck off. They are notoriously stingy with bug bounties and constantly disillusion those who are helping to ostensibly make their platforms more secure. I view NSO in a similar light to Correllium, whom Apple has tried to shutdown (unsuccessfully).
Its like trying to blame a whistleblower rather than prosecuting the misconduct that comes to light. The energy and blame is misplaced and this lawsuit only distracts from the fact that iMessage is basically the skeleton key to access anything and everything on a modern iPhone, after all this time.
That is a law of nature and no amount of shaming will change it.
And everybody parrots the nonsense caveat that everyone shouldn't use it, only those special enough should like it was a zero-sum game or scarce resource. Everyone should use it because it disables a lot of nonsense that doesn't serve you and probably even saves battery power. Also, the more people use it, the less it can be used to fingerprint specific users.
I'd prefer a third mode that compromises between the two, perhaps letting you lower your security for a few minutes when you need the extra functionality. For example, Safari could detect when JavaScript is being slow and pop up an offer to re-enable JIT.
https://googleprojectzero.blogspot.com/2021/01/a-look-at-ime...
Upon re-reading this, it seems like crashes in BlastDoor are reported to Apple in real-time. I think this qualifies as "clientside scanning", tbh.
As I understand it this was a real problem with earlier versions of Windows where it kept asking for admin privileges all the time for simple things, and people got conditioned to just authorize it. They made a concerted effort to provide APIs that didn't require it for most actions to combat this.
iMessage should be assiduously avoided.
The drawback here is that the encryption key for your data never changes, even if you change your password (the private key is just re-encrypted with the new password).
If they’ve implemented it well then this is mostly academic but it does mean they must be escrowing encrypted keys for every account, and those with ADP enabled are just encrypted against their password rather than the Apple key. It also means if they’ve suffered an undetected breach in the past then changing your password doesn’t help protect your data going forward necessarily. That being said, if an attacker had ongoing access to iCloud data then it probably doesn’t matter (although the presumably-more-secure key vault wouldn’t need to be breached again).
I have no insight into Apple’s practices and this is all speculation, this is just the trade-off I would make to keep it usable.
The deviation function takes a while to run and depends on the secure enclave, but you still probably want to avoid 4-digit passcodes.
Mac iPad iPhone Recovery Key
Each of the above would have a separate uniquely encrypted device backup key as a result of the derivation function. I can change the password on any of those (or regenerate the recovery key) without a full iCloud re-encryption or duplication of my iCloud data - therefore Apple must be holding a key in escrow that is the actual decryption key. One would assume it's that key that is encrypted against the derivation function, as then it could still be credibly argued as end-to-end, but that's just an assumption I'm making.
[1]: https://help.apple.com/pdf/security/en_US/apple-platform-sec...
Unless BOTH ends of a conversation are using it, it's pointless.
This means that turning it on does nothing in terms of privacy, in practice, today. All of the iMessages you send and receive will be readable using the escrowed keys from the other users you are messaging with.
Perhaps at some point Apple will prompt or nudge people to migrate, but that's unlikely given the risks to data loss for people who forget their credentials (and have "nothing to hide").
Unfortunately, I can attest to this.
I probably spent 100+ hours doing everything possible to regain access to an iCloud account with advanced data protection.
I lost the password and the recovery key (with no 2nd apple device that was logged in). The only outcome in that scenario is losing your iCloud account completely.
Lesson: enable advanced security, but save your recovery key!
For example: If you stop using WhatsApp for example, nothing bad happens if you try to send messages another way. But if you stop using iMessage, then you can no longer send a normal SMS to someone with whom you've communicated before using iMessage. The Messages app will tell you, "You must enable iMessage to send this message", even if it's an SMS text message to a normal phone number! Why shouldn't that work?
To be able to again send SMS text messages to someone you used to talk with is to disable iMessage of course, then sign out of Facetime (who could imagine that as a necessary step?), sign out of iCloud, reboot the iPhone, and wait some minutes to hours to days until you are "deregistered" from iMessage. I'm talking about the same phone with the same SIM chip. The problem can become much worse if you've switched phones or SIM card.
The source code for iMessage must be a nightmare having integrated SMS and email and a new messaging system all together.
I don't remember if MMS is enabled by default in iOS but theres a toggle to disable it, and realistically there's very minimal real world use-case for MMS these days.
It's still not sending emails, though. The iPhone Messages app sends SMS, MMS, and iMessage; email is the responsibility of the Mail app.
In an MMS, it could be unclear, but only if you choose to put an email address in the “to” field. If you know it is an MMS, and you only use phone numbers, then it will not be an email.
Signal is a good recommendation, but you won’t be able to convince 100% of people you need to interact with over text to use Signal. You might convince friends and family, but not acquaintances or random people who might need to text with (like your electrician etc.)
Given the tradeoffs, iMessage is pretty good for day-to-day messaging.
I'm outside the US, so I don't even need to consider. Nobody here uses iMessage, even the people with iPhones.
What? How-so? I've never allowed it to do that and it works fine for me, across iOS/Mac/Windows.
Yeah, it seems iMessage in iPhone is like IE in Windows, a needlessly ingrained mess for market segmentation purposes
"Relax,” said the night man, “We are programmed to receive
You can check out any time you like but you can never leave"
[1] https://www.smoothradio.com/features/the-story-of/eagles-hot...
That’s simply not true. I just turned off iMessage and instantly switched to the Message app and sent a SMS to someone I have a iMessage chat with and it worked without any problems
I would really prefer to keep it text-only, and am fine with the goofy symbols. If they want to make photo exchange safe, they have the hardware to securely sign images taken on-device and only allow those.[1] (Although that would probably piss off regulators even more.)
[1] With some work, this could be a new feature, used to demonstrate images haven't been altered. With some lockdown of the clock, it could have secure timestamps. (Location could still be spoofed with a GPS hijack.)
Maybe I'm missing something but every single time the only part of iMessage (actually Messages.app) that is insecure is the bit that automatically unfurls attachments and the payload is exploiting a vulnerability elsewhere. So any other app unfurling the attachment thus triggering the payload would be equally vulnerable.
Imagine ping had a privilege escalation vulnerability and someone does ssh foomachine ping <payload> to get root, it'd be a bit weird to call out ssh as being unsafe because it can execute commands, one of them being able to privesc.
Disabling ssh would be a mitigation, and I do wish Messages would disallow unfurling for senders not in the recipient's contact list.
What you're missing is that iPhone's app sandboxing applies to other apps, not to iMessage.
Sure, imessage does have blastdoor and some sandboxing, but it also still has imagent: https://googleprojectzero.blogspot.com/2021/01/a-look-at-ime...
imagent runs as root and processes incoming messages. whatsapp or signal or whatever cannot ship an unsandboxed always on daemon like imagent.
signal/whatsapp/etc have to parse incoming messages inside the app sandbox. iMessage doesn't.
(I'm saying this all very confidently because the quickest way to get the right answer is to be confident about the wrong one and get corrected by a techbro)
does it?
IIUC (from a cursory look) according to the diagram it delegates all message processing to MessageBlastDoorService/IM{Transfer,Transcoder,Persistence}Agent, relying only on locally computed boolean-ish metadata replies from these services, and merely transparently forwarding actual data between those.
What are the odds that something like the NSO just happens to luck into being able to remotely initiate and sustain the building of an entire Turing-complete internal and unauthorized computer internally that also happens to be able to override all hardened protections to the contrary? It just seems so unlikely that there was not a hand in facillitating this internally at Apple. That's what happened with the GreyKey guy...
There probably still are and it’s possibly some three letter agencies or bad actors know about them.
I think the original poster made an attribution error: iMessage gets attacked because it’s popular. If it didn’t allow you to receive rich messages from anyone, people would switch to other apps which do and there’s a long history of those being exploitable, too. What makes iMessage special is that you can assume an iPhone user has it enabled without having to check whether they use WhatsApp, Telegram, Facebook Messenger, etc.
If you are using a phone, you have a phone number. Targeting the phone and SMS handling apps will always be the go-to vector for these sorts of attacks, because you don't want to tell your customer that they can only spy on targets that have Evernote installed and configured.
I don't care enough about JS performance or, more generally, the mobile web, to want to disable it on safari, or even parts of it.
Yeah but have you ever had someone ImportantTM's old phone number?
What about their IP?
Please bring that back (safely) if you can, Apple.
Then they should let us selectively disable all background processes
I'm in the same boat. I was a bit confused, since I'm pretty sure I read somewhere that you could selectively disable it for some "apps", but I've never found out how to disable it for photos specifically.
My requirements of my phone being otherwise slim, I didn't encounter any other issue with lockdown mode.
Lockdown mode only affects Safari. If you use another browser, it doesn't make any difference.
Here are some features that are disabled in Safari when lockdown mode is enabled:
- JIT
- Remote fonts
- WebAssembly
- WebGL
- WebRTC
- PDF Viewer
- MP3 Playback
- Gamepad API
- Web Audio API
- Speech Recognition API
- MathML
- JPEG 2000
- MediaDevices.getUserMedia()
You can configure most of those in Firefox and Chrome, but it has to be done manually and cannot be disabled easily on a per-site basis like in Safari.
I would rathe have a full app firewall with configurable profiles instead of lockdown mode.
Continuity seems to go right out the window for me for one, which is something I really rely on.
Airplay also seems to become really temperamental.
All of this could just be my network but it only seems to have been the case since switching to lockdown mode.
Also, screen time requests don’t work which is a real pain.
Realpolitik view: repressive regimes probably only allow Apple to release devices with this feature available, as long as they don't heavily push it / make it the default. If Lockdown Mode defaulted to "on" in China, and so was used by the majority of users, then Apple would be quickly booted out of China.
Lockdown mode acts as a natural ad block which is great (as a reader). But it also disables JIT. I assume this causes wasted CPU cycles and perhaps, on balance, worse battery life?
If they didn't want people to have all of the background stuff running, they wouldn't put it on there in the first place. It's not super surprising that they want people to use the features (whether "nonsense" or not) that they purposely put there.
Who? Apple? I can't find any statements from them begging us not to use it. It's also a dumb argument since they can just --not-- release the feature if they don't want us to use it.
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 do 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.
[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.
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
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.
Link for those curious: https://darknetdiaries.com/episode/100/
As part of Europe's DMA plan they have precisely 6 months to do that.
For example Settings > Messages > iMessage is literally a switch to turn off iMessage if you feel that it's problematic.
Settings > Safari > Privacy and security has various settings which allow you to have a 'more fine tuned lockdown' for safari.
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...
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)
https://support.apple.com/en-au/guide/iphone/iph203ab0be4/io...
lockdown mode also doesn't add server-side filtering for unknown imessage senders, so that doesn't seem as good for this purpose.
I've personally utilized the mvt-ios tool to investigate iPhone backups. Within these backups, there is a SQLite file that mvt-ios scans for potentially malicious process names. (I've examined all publicly available STIX2 IOCs and having tooling that simply reports the names of processes from mobile phone to a central SIEM would be adequate for identifying these attacks.) Unfortunately, this method cannot be used in real-time across all devices. To employ it, one must first create a complete backup of the phone and then scrutinize that backup. If we had a tool similar to the Endpoint Security Framework available for mobile devices, we could activate enterprise-level security monitoring systems and potentially establish secure communications in the current era, rather than waiting for everything to be rewritten in Rust (a bit of irony).
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."
But GOS takes more security precautions than stock Android, so by that metric there is a greater chance it is unaffected by an unreleased zero-day.
But like I said, there really is no way to know. That goes for Android, GOS, and iOS.
Kind of insane, the only higher you can get is finding the same on Android
You really have no way of knowing that a box is not owned as soon as it has connectivity (and possibly even before that).
I feel like many people have the idea that security is “these machines are good until we detect some intrusion”.
But it seems like the more sane default is “every machine is compromised and I should never trust anything ever” if you take security seriously.
Maybe the latter is gaining popularity, but I still feel like the former ideology is pretty prominent.
This is where I am already at.
However, you can't totally live like this in 2023. You need to take some risks.
I just can't believe how bad iPhone security is STILL. Capitalism prioritizes profits over all, it seems Apple has no problem cutting on security and spending on marketing the word "SECURITY" with black text and a white background.
For someone to send me a message on signal, they have to either social engineer me into adding a number I don't know, or they have to steal a device from one of my existing contacts, get it unlocked, and send from it.
There is no way for them to go from knowing my phone number to me receiving and processing an untrusted image without them first somehow becoming a contact.
iMessage has no option to require friending first, before receiving unsolicited messages.
That doesn't seem like a "slightly easier" thing, but a rather significant difference.
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.
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.
Is there a honeypot in a comment on this page? /paranoid
I tip my hat to CitizenLab and the good work they do.
Back in the dark ages, a "zero day exploit" was a piece of malware which would lay in wait, doing nothing, counting down the days, until it hit day zero, and then it would trigger and do naughty things. Some folks also referred to this as a time bomb, but that was a less `|33+ term for it. We used to see a lot of these available on sites such as asta... never mind.
Fast forward to the era of "cyber" being hugely popular, and the massive flood of people doing short Kali or "Ethical Hacking" courses and getting into IT security jobs, and I see various formal IT security publications describing a zero day exploit as "ANYTHING which is known and not yet patched". To me, there is absolutely nothing about that description which relates to the "zero" or the "day" or the "zero day". I suspect this new terminology is the result of that influx of people with no background in either computer science or hacking, latching on to a cool sounding term and misunderstanding it completely.
What is your take on this? Do you go with the ye olde terminology, or the currently accepted terminology in fancy publications? Do you believe the meaning changed, and if so, when and how and why?
I’m, in no way, a security savvy but the above achievement must be a lot of work by the NSO group!
How capable are the hackers vs solid engineers working on a basket of known threat models + some additional R&D as the platforms change?
What is the next iteration of these types of companies?
People who work there are amongst the most skilled hackers in the world. Security is very hard and that’s why even solid engineers fail a lot in tackling that. Especially because security is a cost center for vendors, while it’s a profit center for companies like NSO. So the resources invested are relatively more.
That said, Apple did an amazing job to improve security in the past years.
I’m trying to phrase this in a way that doesn’t come standoffish - in some way you clearly _weren’t_, since you did the work. But I’m wondering whether this ever entered the picture for you, and how you dealt with that.
I was concerned. Just as much as an average Facebook employee when it turned out someone built a psyop weapon on top of their data to manipulate elections’ outcomes.
The number of degrees of separation between average Facebook's engineer work and "direct harm to a human being" seems like it'd be orders of magnitudes higher than when working on exploits for companies with the client list like that of NSO's.
Or do you not think about it in those terms?
NSO is probably one of the worst offenders when it comes to screening their clients. This raises ethical issues. It was a factor for me and many of my former colleagues. However, for every abusive operation that gets exposed, there are many legitimate ones conducted by democratic governments. I think we are far from a mass-surveillance scenario, and those exploits are not as widely available as the media might portray.
https://cybernews.com/crypto/romance-scams-southeast-asian-t...
Apple itself pays $1-million for bug bounties of this type.
other 0-days for iphone up to around 2 million
Wasn't this captured in the wild?? Then why the "may"?
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...
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.
Just put an army of people on fuzzing the shit out of iMessage and all its possible file attachments.
You tried and failed? Fire the bozo who lead the effort. Try again.
You did not even try? Fire the c-level bozo who failed to see it coming and failed to approve such an effort.
But cynically, more and more it feels like some bugs have to stay unfixed, for NSA use, just that NSO is also getting on the game.
You need to understand "do fuzzing" is not a magic trick to find all bugs in software.
Similarly: definitionally you will only ever see the bugs that are not found prior to shipping - any bugs that are found prior to software shipping will have been fixed.
All these techniques have degrees of mastery, and if applied carefully, and in combination, can save you a lot of grief.
Dumb fuzzing will not get you anywhere, same as dumb unit testing, and dumb debugging.
In this case, iMessage is particularly well suited for some smart fuzzing because all the attack vectors seem to involve smallish malicious attachment files.
You are erroneously saying "one group of people found a bug that could be found by fuzzing therefore apple is not fuzzing".
LibJPEG is decades old at this point and is still getting around 10 CVEs a year, despite being one of the projects I believe google constantly fuzzes.
zlib is getting a few a year despite being a vastly more constrained format than anything else imaginable, and again being a heavily fuzzed library.
If "do lots of fuzzing" caught every bug, then you'd get a big release that fixed all of them, and you'd never see any more.
> In this case, iMessage is particularly well suited for some smart fuzzing because all the attack vectors seem to involve smallish malicious attachment files.
I chose to include libjpeg above specifically to rebut this comment. That there are still CVEs coming in for libjpeg this year, despite years of fuzzing should be sufficient to show that even small attachments aren't magically invulnerable due to fuzzing.
Fuzzing is a useful tool but pretending that some project or software is going to be secure because it's been fuzzed a lot is nonsense, and pretending that fuzzing will find all the bugs is complete fiction.
Even software written in memory safe languages benefits from fuzzing: a memory safe language simply means your code will not continue if doing so would result in a memory safety violation, but for most memory safe languages that means at best an exception, but in most cases it means termination - that's what you get in Rust, Swift, or even functional languages like Haskell - and program termination can mean user data loss, or at least a bad user experience, so fuzzing is helpful even if bugs don't cause "security" issues.
They also spend a ton of engineering resources to prevent customers from using their products as general computing devices with the pretense of hardening security. It works to an extent and the tradeoffs are debatable, at least among tech-savvy folks in HN.
NSO seems to be finding more and more bugs by poking a black-box alone, while Apple cannot seem to be able to fix by looking at the source code with all the fuzzing and verification tools, and much more $$$ at their disposal.
"Are you claiming NSO has access to iMessage and iOS source code?"
The last NSO zero-click was in an open-source library reachable from iMessage. This vulnerability is likely no different considering it was in an image decoding library.
NSO group hires many talented security researchers who specialize in reverse engineering and auditing source code. It is hard for people not familiar with security research to understand but there are a lot of very talented code auditors out there who have honed the skill of picking up a new codebase, understanding it better than the developer who wrote it within months, and then finding bugs in it. There are teams of researchers at certain exploit shops who spend their lives focusing on understanding a single target.
Fuzzing is a great tool for finding bugs, but code auditing will always be the best way to find amazing bugs and novel attack surfaces. Researchers who can do both code auditing and fuzzing extremely well (like lokihardt@astr) are even rarer and extremely good because they can both find interesting pieces of code to fuzz through auditing and find amazing bugs while fuzzing.
Apple is and should continue hiring these talented researchers. The point I am making is that they should hire these security researchers even more aggressively and other tech companies should follow. Most of them work at exploit shops like NSO group because they pay a lot better than big tech. One security researcher and one security engineer to every five developers for these critical pieces of code should be the industry standard not 1 security engineer to every 100-1000 devs...
Ehh…it’s complicated. Often this is not the case.
It takes a different mindset to find these type of bugs than it takes to develop software. I won't quite say they're orthogonal skill sets, but pretty close.
If the people finding these bugs don't want to work for Apple, Google Project Zero, etc. there's not really much Apple can do about it.
Programming mindset is about making sure what’s in the spec works.
Security mindset is about making sure that what isn’t in the spec doesn’t work.
How come NSO isn’t yet designated as a (cyber-)terrorist group worth hunting down and extinguishing?
If an air bag fails, you fault the manufacturer. They don’t escape responsibility by saying it’s the other drivers fault.
I’ll also add that Apple is not the victim here, the targeted end users are.
If in a car accident we knew one party intentionally caused the crash (and were paid for it handsomely), we’d hold them responsible, regardless what claims car companies make regarding safety.
If your air bag fails to deploy after a crash, the manufacture is responsible for the product defect. It doesn’t matter if the crash was an accident or someone intentionally and specifically crashing into you, the manufacturer is responsible for a defective air bag. The manufacturer is not responsible for the crash, only the defective product. The other driver is not less responsible for a death or injury resulting from the crash.
Responsibility for the crash and its consequence's rest on the driver at fault.
Responsibility for a defective air bag rests on the manufacturer.
They are two separate issues and not zero-sum.
If someone clips your airbag wires before the crash, that is not a product defect and the manufacturer is not liable, but that is not what happened here. There was no prior access or modification to the device or software. Apple claims to have a secure phone yet has a critical zero click vulnerability similar to an earlier vulnerability they previously fixed.
Pointing a finger at NSO could one day lead to some government’s action aimed at influencing another government’s actions toward a private organization. NSO doesn’t care if they’re unpopular online.
Highlighting Apple’s responsibility in this is how we incentivize better security in consumer products.
I don’t think companies should be responsible for every exploit all the time. Nobody is pointing fingers at ViaSat for being hacked by the Russians. There have been repeated iMeassage exploits that could be prevented with easy to implement defaults or simple opt-in settings (do not implicitly trust unknown numbers) which have been asked for after each exploit and ignored.
Should they have done something about this? I believe so, but they are not marketing themselves as secure against state actors. They have release lockdown mode, which may or may not have prevented this particular exploit.
It's important to keep the demographic of iPhone users in mind. The average user do not want to be inconvenienced for security measures irrelevant to them. And if a competitor (Android) is providing a better experience, then Apple, from a business point of view, have no choice but to make the most secure system they can, while still providing the same UX.
All that said, I do believe that they should implement zero trust on first contact, as a default, with the option to enable explicit trust for every attachment. I just do not believe that this will be any major impact on these actors capabilities.
Answering this would violate HN guidelines/moderation policy.
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...
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.
this is a problem of all nation states wanting this kind of service, not of israel in particular.
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.
It is good to know lockdown mode stopped this attach chain.
Given this has happened so many times, new security posture for a normal/regular security conscious person should be:
1. Disable iMessage.
2. Enable lockdown mode.
3. Disable iCloud. (If you choose to keep iCloud enabled, definitely enable Advanced Data Protection and disable iCloud Web, disable passcodes and keychain on iCloud. Disable iCloud mail – it uses 3rdparty proofpoint for scanning – more surface area for compromise).
4. Don't store password and 2FA together in the same system like 1password. Always use FIDO2 physical key based 2FA, if available.