I don't need to be able to accept iMessage messages from random numbers. I'd be happy to enable "Prevent messages from unknown numbers" for example. Is this possible?
Yeah, its starting to get weird that they refuse to implement this. Its almost like certain stakeholders need to be able to randomly text you with malware and refuse the notion of being silenced.
NSO group iPhone zero-click, zero-day exploit captured in the wild
811–820 of 886 posts
Re: NSO group iPhone zero-click, zero-day exploit captured in the wild
#812Earlier quoted context omitted.
It’s an attack vector because it’s convenient. If iMessage didn’t exist people would email you exploits.
Are there zero click exploits in email?
Re: NSO group iPhone zero-click, zero-day exploit captured in the wild
#813Earlier quoted context omitted.
It does if we grant the two the same assumptions. If we assume that serious, unjustified harm would occur by failing to act, and they are in a reasonable position to act… then I’d say a private company is equally justified in doing the same thing. However, you’re assuming the government is justified merely because it’s the government.
Do you think private companies should be allowed to, say, arrest people?
https://en.wikipedia.org/wiki/Citizen%27s_arrest#United_Stat...
Re: NSO group iPhone zero-click, zero-day exploit captured in the wild
#814Earlier quoted context omitted.
Adding something in rust into a browser means you now need to bundle all of the needed crates and that your browser now also needs rustc to build… at a minimum. You also need potentially to audit all the crates and keep them up to date and so on… without crates you can't do so much.
I can see that for components heavily interfacing with high surface area things like encryption, hardware interfacing etc., but why would that be true for a relatively “pure” computational problem like an image codec? Bytes in, bytes out.
Re: NSO group iPhone zero-click, zero-day exploit captured in the wild
#815Earlier quoted context omitted.
Your problem isn't the quality of your own code, it's that Google exists and is unable to stop their employees from doing stupid things like inventing WebP, because now you need to support WebP too which means using their code to do it. (Worse, WebP is at least two completely different formats - the lossless mode has nothing to do with the lossy mode.)
I think that: 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
Re: NSO group iPhone zero-click, zero-day exploit captured in the wild
#816Earlier 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…
https://www.api.org/news-policy-and-issues/blog/2018/06/14/w....
Re: NSO group iPhone zero-click, zero-day exploit captured in the wild
#817Earlier quoted context omitted.
Your problem isn't the quality of your own code, it's that Google exists and is unable to stop their employees from doing stupid things like inventing WebP, because now you need to support WebP too which means using their code to do it. (Worse, WebP is at least two completely different formats - the lossless mode has nothing to do with the lossy mode.)
As opposed to Apple’s formats, for which the parsers are definitely less buggy and likely to be hacked.
Re: NSO group iPhone zero-click, zero-day exploit captured in the wild
#818Earlier quoted context omitted.
The point is that those other apps don’t use email addresses as the handle to contact someone. If someone iMessages you, the iMessage might (appear to) come from their phone number, or it could (appear to) come from their email. If you have an iMessage contact that’s just an email and you iMessage them, it works fine. If you try to then add Android users to your group chat, everyone gets SMS and the iMessage user wit…
I'm fairly certain that "text to email" is a feature of MMS - I've used it a few times years before iPhones were around. 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.
Re: NSO group iPhone zero-click, zero-day exploit captured in the wild
#819Earlier quoted context omitted.
> Code to calculate size of preallocated array is incorrect. Size ends up too small or underflows. If you go outside the array you copied/mapped out of the sandbox, then that doesn't let the attacker code escape the sandbox, you just put some of your own data onto the screen. If you mean the sandbox isn't given enough memory, then that will make the sandbox exit when it hits unmapped addresses. And how did you screw…
> And how did you screw up length x width x 4? 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…
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.
Re: NSO group iPhone zero-click, zero-day exploit captured in the wild
#820Earlier quoted context omitted.
I think that: 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
If you reimplemented it they'd just change it. It's Google, they can't stop themselves.