Skip to content

checkm8: unpatchable Apple SecureROM/BootROM exploit (DFU USB)

Apple A5–A11 SoC'lerin salt-okunur SecureROM USB/DFU stack'inde, en erken boot aşamasında kimliği doğrulanmamış kod yürütmesi veren bir use-after-free; bug mask ROM'da yaşadığı için sahada yamanamaz.

Mechanism

Neden çalışır — root-of-trust ROM değiştirilemezdir, bu yüzden tek bir bug kalıcıdır

SecureROM (BootROM), bir Apple SoC'sinin güç verildiğinde çalıştırdığı ilk koddur. Salt-okunur mask ROM'a yazılmıştır, bu yüzden secure boot chain'ini sabitler ve güncellenemez — bir firmware yazma path'i yoktur. Platform invariant'ı, SecureROM'un yalnızca Apple imzalı image'ları başlatmasıdır; downstream'deki her şey (iBoot, kernel) ona örtük olarak güvenir.

checkm8 (CVE-2019-8900), bu invariant'ı Device Firmware Update (DFU) mode tarafından kullanılan USB stack'teki bir use-after-free ile kırar. DFU, herhangi bir image imzası kontrol edilmeden önce USB üzerinden erişilebilirdir. Bir DFU DNLOAD data transfer'i başlatılıp tamamlanmadan bırakıldığında ve ardından bir DFU_ABORT verildiğinde, USB stack usb_quiesce() → usb_dfu_exit() üzerinden yıkılır ve global I/O buffer'ı free'ler — ama in-flight usb_device_io_request yapılarındaki global pointer'lar hâlâ o free edilmiş allocation'a referans verir. DFU'ya yeniden girişte o bayat pointer'lar yeniden kullanılır ve free edilmiş heap'e bir write verir; bir request'in callback/next alanlarını bozarak SecureROM içindeki program counter'ın kontrolünü sağlar.

İkinci bir detay exploitation'ı güvenilir kılar: SecureROM heap'ini sıfırlamaz ve kontrol edilebilir bir memory leak (tam olarak 0x40 byte'ın katı olan transfer'ler için standard_device_request_cb() tarafından kuyruğa alınan zero-length-packet callback'leri), saldırganın heap'i groom etmesine izin verir ki sonraki allocation free edilmiş buffer'ı geri almasın. Hem dangling pointer hem de leak ROM'da yaşadığından, etkilenen silikonda hiçbir yazılım düzeltmesi mümkün değildir — A12 kullanılabilir leak'i kapattı ve sonraki parçalar UAF'in kendisini ele aldı.

Walkthrough

Public proof of concept, axi0mX'in ipwndfu'sudur. Zincir tamamen USB control transfer'leri ile sürülür; aşağıdaki adımlar açıklanmış akışı yansıtır ve örnekleyicidir — yeni silahlandırılmış bir exploit değil.

Temsili ipwndfu çalışması (public PoC, DFU'daki A5–A11 cihazı) 

$ python3 ipwndfu -p
Found: CPID:8010 CPRV:11 CPFM:03 SCEP:01 BDID:08 ...
Device is now in pwned DFU Mode.
Başarılı bir çalışma ayrıca USB serial string'ine bir marker ekler ki araçlar SoC'nin pwned DFU mode'da olduğunu doğrulayabilsin: 
$ system_profiler SPUSBDataType | grep -i serial
Serial Number: ... PWND:[checkm8]

Kavramsal trigger dizisi (public write-up'larla eşleşir):

  1. Heap grooming — device-to-host endpoint'i stall'la ve request'leri kuyruğa al ki free edilen allocation'lar "delik"ler bıraksın; böylece adım 3'te free edilen buffer hemen geri alınmasın.
  2. Bir DFU DNLOAD başlat (bmRequestType 0x21, wLength <= 0x800) ve data phase'ini transfer'in ortasında kasıtlı olarak terk et.
  3. DFU_ABORT gönder; bu, global request pointer'ları hâlâ ona dangle ederken usb_quiesce()'ı I/O buffer'ı usb_free() etmeye sürükler.
  4. DFU'ya yeniden gir; bayat usb_device_io_request işlenir, üzerine yazılmış callback/next alanları yürütmeyi saldırgan shellcode'una yönlendirir.
  5. Payload tipik olarak Image4 signature kontrolünü patch'ler (örn. validation sonucunu success'e zorlayarak) ki sonradan yüklenen, imzasız bir iBoot/image boot edebilsin.

Public reversing'den ilgili struct:

struct usb_device_io_request {
    uint32_t endpoint;
    volatile uint8_t *io_buffer;
    int status;
    uint32_t io_length;
    uint32_t return_count;
    void (*callback)(struct usb_device_io_request *); /* overwritten */
    struct usb_device_io_request *next;               /* overwritten */
};

Detection

  • Physical/possession check. Per CERT/CC VU#941987, exploitation requires physical access, a USB connection, and the device in DFU mode; the effect is non-persistent (a reboot reverts it). Detect tampering by looking for a PWND:[checkm8] marker in the USB serial string and for devices unexpectedly held in DFU.
  • Endpoint/MDM posture. Enterprises should treat A5–A11 iOS/iPadOS devices as physically jailbreakable; monitor for unexpected DFU entry, supervision/MDM check-in anomalies, and configuration drift on managed devices.
  • No firmware telemetry. Because the bug executes in ROM before the OS, there is no on-device log of the exploit itself — detection is environmental (physical custody, kiosk camera, USB lockdown), not log-based.

Mitigation

There is no patch for affected silicon

CERT/CC states the only guaranteed remedy is replacing the device with one whose SoC is not vulnerable (A12 and later are not exploitable via this chain). For A5–A11 devices:

  • Maintain physical control; the attacker needs the device in hand and in DFU mode.
  • Set a strong alphanumeric passcode — checkm8 does not bypass the Secure Enclave or Data Protection, so user data and Touch ID/Face ID secrets remain protected without the passcode.
  • Use Supervision + MDM and Activation Lock so a wiped/jailbroken device is detectable and unusable as a clean device.
  • For high-assurance use, retire A5–A11 hardware from sensitive roles.

References