kmfpl

Compiler can sometimes inline syscall wrappers, so not that easy to check statically. For the same reason searching for SVC instructions would yield tons of results. If you search for the exact syscall ID moved into X16 you’d find it immediately.

You also removed the giant pole stuck up your ass?

I agree, this looks extremely sketchy. Especially because the code is just writing a fully controlled byte in the buffer and incrementing its index.

This would give you a controlled relative write primitive if you can repeatedly call this function in a loop and going OOB.

Well, that’s 7 years of major updates with all the security fixes. Moreover, Apple continues to release minor versions for devices that are not supported anymore, in order to fix major flaws that are actively exploited ITW (see iOS from 12.4.2 to 12.5.6, those are a lot of minors released over the years to address 0d ITW, same thing happens with macOS)

This is simply how Apple does things. They provide software support for ~10 years and then they drop it.

Is it wrong? I’m not entirely sure. You can call that greedy, but take a few things into consideration. Firstly, Apple provides highly specialized software that runs extremely well and efficiently on their own hardware. Continuously providing support for old hardware while simultaneously maintaining the same level of performance is simply not feasible. I challenge any software developer to achieve a similar goal.

We are not talking about Linux here, where if you’re lucky, things work. Anyone’s that ever used macOS even once knows that things really work.

Now, I assume this window of time between a new hardware’s release and the software drop for that given piece of hardware will increase over time, given that new hardware released by Apple nowadays is incredibly performant, this would allow longer software support.

Frankly, my opinion is that 10 years of support is more than enough for anyone to consider renovating their hardware.

Recently, in the last XNU kernel release (corresponding to macOS 13/iOS 16) the 32-bit part of the kernel has been entirely removed, meaning that XNU won’t support any 32-bit device anymore. This is really exciting to me, as I see the technology moving forward, without getting stuck on prehistoric hardware support.

With lldb you can do that, basically you have the option of running commands when a given breakpoint is hit, so you can just make it place another breakpoint, and it will be placed only if the first breakpoint is hit. I assume you can do something like this on gdb as well.

People in this thread seem very confused about a lot of stuff so I’m going to try and make some clarifications:

1) This is an RCE, so what it does is achieving code execution in the browser, i.e. it can run arbitrary code from the attacker, it’s literally like running a compiled program inside the target’s browser. This doesn’t bypass Chrome’s sandbox, so a lot of OS operations are not reachable from within the browser (for example, a lot of syscalls can’t be called).

This is the first step in an exploit chain, the second one would be a sandbox escape to expand the attack surface and do nasty stuff, or maybe a kernel exploit to achieve even higher privileges (such as root)

2) WASM being RWX is really not a security flaw. W^X protections in modern times (even in JIT-like memory mappings) makes sense only when coupled with a strong CFI (control flow integrity) model, which basically tries to mitigate code reuse attacks (such as JOP or ROP). Without this kind of protection, which needs to be a system-wide effort as iOS has shown, W^X makes literally zero sense, since any attacker can easily bypass it by executing an incredibly small JOP/ROP chain that changes memory protections in the target area to run the shellcode, or can even mmap RWX memory directly.

You understand that having W^X protections on any JIT area is fairly useless without a strong CFI model in place right? Any attacker could easily execute a ROP/JOP chain to switch JIT protections to RX or even more simply allocate an RWX area where the shellcode can be copied and executed.

Normally bugs in these types of attacks target daemons that are always connected even if not logged onto iMessage or even if you disable iMessage. Or at least this was the case with previously known bugs.

>“Just reboot your phone, and you're good to go”

Doesn’t really work like that. First of all, when would you reboot your phone? Once per day? Once per hour? Every five minutes? Regardless, these attacks are incredibly advanced, remember they require zero interaction from the user.

Even if you rebooted constantly and the exploit lacked a persistence vector, they would still be able to exploit you whenever they want. There are literally no good defense mechanisms against zero-click attacks. The only effective one being turning off your phone forever.

Something like these exploits takes 1-2 minutes maximum to achieve full data exfiltration. This means you’re not safe even if you reboot every five minutes.

So preventing persistence vectors is not really useful against these types of attacks. Persistence is more of a “comfort feature” for attackers, is not really something essential.