Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NSO group iPhone zero-click, zero-day exploit captured in the wild

citizenlab.ca

Post reply on HN
Print view View original

841–850 of 886 posts

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#841

Post by Dylan16807 »

Hackbraten wrote: post #840
Dylan16807 wrote: post #838

Earlier quoted context omitted.

> The code doesn't have to be wrong for every input. It may be wrong just for pathological cases that don't occur in the field unless specifically crafted. I could argue this more but it doesn't matter, that was just a little tangent, getting the size wrong will not let anything out of the sandbox. > The assumption was that the code tries to clean up the buffer immediately after use. Cleaning up would be removing the…

> Cleaning up would be removing the mmap. How are you going to exploit that? Your scenario is not very clear. If a buffer is going to be reused across calls, then cleaning after use is not the same thing as unmapping. One example for cleaning up a buffer after use would be zeroing. If there's a bug in the calculation for the amount of zeroing needed, then leftover attacker-controlled data can bleed back from the sand…

It's hard to see why the buffer wouldn't be per image. There's no reason to reuse that.

> In other words, the attacker can now write arbitrary data into the unsandboxed process's memory at a semi-known location (known page offset) inside the mapped buffer.

But what is the arbitrary data going to be?

1. If it's gadgets with known lower bits, then you could put that into a plain-old image file, no decoder exploits needed. Also this requires the second dumb mistake of the coder going out of their way to mark the buffer as executable.

2. If it's data you want to exfiltrate, you could just gather that after you trigger your unrelated exploit. This is only useful if everything aligns to drop the private data you want in that specific section of memory, and then the buffer is reused, and then the private data is removed from everywhere else, and then you run an unrelated exploit to actually give you control. This is exceptionally niche.

> harmless on its own

Ha.

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#842

Post by npteljes »

Obscurity4340 wrote: post #822
npteljes wrote: post #84

Earlier quoted context omitted.

>no wonder China is banning government officials from using their devices A totalitarian regime can have a different, plausible reason: no sufficient control over said devices.

iPhones can be provisioned with pretty extensive profiles/MDM so I doubt that part. They probably see all the zero-days and decide game respects game. Just not secure enough for such an incredibly insular power structure as theirs, even without the US connections.

>decide game respects game

Elaborating on this, the US banning Huawei doesn't help either.

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#843

Post by Hackbraten »

Dylan16807 wrote: post #841
Hackbraten wrote: post #840

Earlier quoted context omitted.

> Cleaning up would be removing the mmap. How are you going to exploit that? Your scenario is not very clear. If a buffer is going to be reused across calls, then cleaning after use is not the same thing as unmapping. One example for cleaning up a buffer after use would be zeroing. If there's a bug in the calculation for the amount of zeroing needed, then leftover attacker-controlled data can bleed back from the sand…

It's hard to see why the buffer wouldn't be per image. There's no reason to reuse that. > In other words, the attacker can now write arbitrary data into the unsandboxed process's memory at a semi-known location (known page offset) inside the mapped buffer. But what is the arbitrary data going to be? 1. If it's gadgets with known lower bits, then you could put that into a plain-old image file, no decoder exploits need…

> It's hard to see why the buffer wouldn't be per image. There's no reason to reuse that.

Premature optimization is a thing. Most software developers are prone to it in one way or another. They may just assume a performance gain, design accordingly and move on. They may be working under a deadline tight enough so they never even consider checking their assumptions.

Or maybe the developer has actually run the experiment and found that reusing the buffer does yield a few percent of extra performance.

> But what is the arbitrary data going to be?

An internal struct whose purpose is to control the behavior of some unrelated aspect in the unsandboxed process. The struct contains a couple of pointers and, if attacker-controlled, ends up giving them an arbitrary process memory read/write primitive.

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#844

Post by Dylan16807 »

Hackbraten wrote: post #843
Dylan16807 wrote: post #841

Earlier quoted context omitted.

It's hard to see why the buffer wouldn't be per image. There's no reason to reuse that. > In other words, the attacker can now write arbitrary data into the unsandboxed process's memory at a semi-known location (known page offset) inside the mapped buffer. But what is the arbitrary data going to be? 1. If it's gadgets with known lower bits, then you could put that into a plain-old image file, no decoder exploits need…

> It's hard to see why the buffer wouldn't be per image. There's no reason to reuse that. Premature optimization is a thing. Most software developers are prone to it in one way or another. They may just assume a performance gain, design accordingly and move on. They may be working under a deadline tight enough so they never even consider checking their assumptions. Or maybe the developer has actually run the experime…

> An internal struct[...]

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.

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#845

Post by Hackbraten »

Dylan16807 wrote: post #844
Hackbraten wrote: post #843

Earlier quoted context omitted.

> It's hard to see why the buffer wouldn't be per image. There's no reason to reuse that. Premature optimization is a thing. Most software developers are prone to it in one way or another. They may just assume a performance gain, design accordingly and move on. They may be working under a deadline tight enough so they never even consider checking their assumptions. Or maybe the developer has actually run the experime…

> An internal struct[...] 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 vuln…

> you don't need to take control of the sandbox

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.

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#846

Post by zuhsetaqi »

computator wrote: post #414
Obscurity4340 wrote: post #336

Earlier quoted context omitted.

I would argue that iMessage is way to problematic to be used safetly, at all. By anyone. Full-stop. It also seems to be the primary attack vector of NSO related zero-days as well and its become known that phone country/area codes have relevance to its chance of succes in past exploits, which suggests a phone/messaging type attack vector.

That fact that Apple blended iMessages, SMS text messages, and email into an extremely confusing mess may also be the reason for so many security issues related to iMessage. Perhaps not directly responsible for this particular NGO exploit, but I find iMessage's logic and behavior bewildering at times. For example: If you stop using WhatsApp for example, nothing bad happens if you try to send messages another way. But…

> 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.

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

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#847

Post by forcedmaddie »

saagarjha wrote: post #286
jacquesm wrote: post #216

Earlier quoted context omitted.

At the risk of being boring: software liability would go a long way towards getting companies to do this work themselves. Even though Apple is the largest company on the planet an entity that has a small fraction of the budget is apparently able to do a better job. I don't see why Apple couldn't make those people an offer they can't refuse. That takes them off the market and has them doing something productive.

NSO Group is just one vendor; there are many more: Variston, Dataflow, Azimuth, Cytrox, …

Yet you forgot to mention that you entertain relationships with employees of those companies and go to their conferences. Hypocrisy much?

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#848

Post by philistine »

nojvek wrote: post #774
trogdor wrote: post #738

Earlier quoted context omitted.

>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...

The US is the largest oil producing country in the world. Mostly from Texas. https://www.eia.gov/tools/faqs/faq.php?id=709&t=6 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 o…

> [...] 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.

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.

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#849

Post by philistine »

hiatus wrote: post #809
hbt wrote: post #771

Earlier quoted context omitted.

or you know, publicly shot in the head for standing up against the deep state and keep delaying the release of secret files even after 50 years.

Who are you referring to?

I think they somehow think Kennedy was against the deep state the way Trump is supposedly against the deep state.

Re: NSO group iPhone zero-click, zero-day exploit captured in the wild

#850

Post by azernik »

mola wrote: post #761
azernik wrote: post #596

Earlier quoted context omitted.

They don't really leverage it for diplomacy. Israeli arms exports policy consistently prioritizes getting better R&D economies of scale over actually affecting foreign states' behavior.

Definitely part of diplomacy effort of netanyahu with the despots if the world. NSO CEO travelled with him to Saudi t among other places. It's software there's economics of scale by default.

Economies of scale only apply if you have scale, ie lots of (paying) users. If you're making this fancy thing for only the Israeli security services you won't be able to pay your developers.
Post reply on HN