• JATth@lemmy.world
    link
    fedilink
    English
    arrow-up
    21
    ·
    11 months ago

    Shorter version: Operating systems set up hardware locks and protections to confine processes, and once set up, they cannot be undone. (the hardware + OS denies modifications to the security policy)

    • Attacker broke out from the app sandbox. (attacker can run code in the infected process)
    • Broke out of the process. (gained root access; attacker can run anything)
    • Broke into the kernel space (gained 100% control over the hardware)
    • Corrupted some kernel memory via a damm magic MMIO accesses nobody knows (hardware vulnerable)
    • Bypassed protections that kernel set up earlier such that it cannot accidentally modify itself.
    • Finally broke the kernel via hardware exploit thus the attacker got rootkit level access.

    Getting arbitrary code execution and root access is one thing, but breaking out from the damm kernel configured hardware protections is insane.

    They basically managed to flip a “read-only” switch to “modify-as-much-as-you-like”. The infected device at this point is broken beyond repair, as the firmware(s) may have been tampered with. End result is a terrestrial spy brick.

    • phx@lemmy.ca
      link
      fedilink
      English
      arrow-up
      9
      ·
      11 months ago

      Not only that, but using an initial exploit which could be remotely triggered with NO user interaction or visibility. That’s scary shit

    • archomrade [he/him]@midwest.social
      link
      fedilink
      English
      arrow-up
      7
      ·
      11 months ago

      This is a nightmare, but thank you for detailing this. Having only read a little bit of this and not understanding it, it seems like the exploit works even if the recipient does not open or interact with the malicious message? Is that what i’m understanding?

      • JATth@lemmy.world
        link
        fedilink
        English
        arrow-up
        7
        ·
        11 months ago

        The attack is spread via iMessage. A vulnerable device merely needs to receive a bad message with PDF attachment. --> A Remote code execution. No user interaction.

        Yikes. Indeed.

        The attack entry point is via bad TrueType font + PDF attachment that only needs to processed once. Once a process touches that, the attack vector begins and exploits are chained until they get kernel mode access. After getting kernel mode access all hope is lost, the attacker owns the device.

        Only sliver of hope is that fixing the attack entry point blocks the current attack. And that bug is:

        This attachment exploits the remote code execution vulnerability CVE-2023-41990 in the undocumented, Apple-only ADJUST TrueType font instruction. This instruction had existed since the early nineties before a patch removed it.

        But unless all the CVEs are patched, it is just matter of time a new attack entry point is found.