zhuowei/apple-positional-audio-codec-invalid-headerCVE-2025-31200 - @Noahhw46 figured it out
Preuve de concept pour le correctif CoreAudio (CVE-2025-31200) dans iOS 18.4.1. Article ici https://blog.noahhw.dev/posts/cve-2025-31200/.
J’ai réussi à transformer cela en une écriture contrôlée, même si elle n’est pas encore arbitraire. L’article arrive bientôt. Pour le constater par vous-même, vous devrez compiler sur une version de macOS antérieure au correctif : < 15.4.1. Vous pouvez lire l'audio avec le hook lldb check-mismatch (en utilisant un simple harnais qui se contente de jouer l'audio) pour observer l’écriture. Ce n’est pas encore une écriture arbitraire parfaite, comme je l’ai mentionné plus haut pour plusieurs raisons – principalement parce que je ne suis pas encore sûr à 100 % à quel stade du pipeline de décodage ces valeurs du tampon d’images se trouvent lorsqu’elles sont remappées. Je m’arrête ici pour travailler sur l’article, si quelqu’un veut reprendre le dossier.
Moi, @noahhw46 (je n’y serais pas arrivé sans cette configuration @zhouwei), j’ai trouvé (article à venir). Cependant, il reste encore beaucoup à comprendre. J’ai ajouté ici les premières pistes des prochaines étapes de mon investigation pour montrer exactement ce que le bogue fait. check-mismatch est un autre script lldb qui peut être utilisé avec un poc fonctionnel pour montrer précisément l’incohérence créée entre mRemappingArray et la carte de permutation dans APACChannelRemapper::Process (en réalité dans APACHOADecoder::DecodeAPACFrame).
Le tableau mRemappingArray est dimensionné en fonction des deux octets inférieurs de mChannelLayoutTag.
En créant une incohérence entre eux, une étape ultérieure du traitement dans APACHOADecoder::DecodeAPACFrame est corrompue.
Lorsque APACHOADecoder traite l’image APAC (la permute selon le tableau de remappage des canaux), il utilise mRemappingArray comme carte de permutation pour effectuer le remappage des canaux. Il semble que les données de l’image en cours de remappage soient dimensionnées en fonction de mTotalComponenets.
Lorsque vous lisez le fichier audio output.mp4 (par exemple avec AVAudioPlayer), APACChannelRemapper::Process lira puis écrira hors limites.
Vous pouvez constater la première lecture hors limites si vous activez Guard Malloc dans Xcode :
Sans Guard Malloc, APACHOADecoder::DecodeAPACFrame plantera plus tard avec un memmove invalide :
L’ancien README de @zhuowei est ci-dessous :
J’essaie de comprendre le correctif CoreAudio (CVE-2025-31200) dans iOS 18.4.1.
Je n’ai pas encore trouvé.
Actuellement, j’obtiens différents messages d’erreur lors du décodage de output.mp4 sur macOS 15.4.1 :
error 01:10:26.743480-0400 getaudiolength <private>:548 Invalid mRemappingArray bitstream in hoa::CodecConfig::Deserialize()
error 01:10:26.743499-0400 getaudiolength <private>:860 Error in deserializing ASC components
vs le simulateur Xcode pour visionOS 2.2 :
error 01:09:21.841805-0400 VisionOSEvaluation APACProfile.cpp:424 ERROR: Wrong profile index in GlobalConfig
error 01:09:21.841914-0400 VisionOSEvaluation APACGlobalConfig.cpp:894 Profile and level data could not be validated
donc je tombe sur la nouvelle vérification, mais je ne sais pas comment faire pour qu’elle écrive effectivement quelque chose.
La fonction modifiée semble être apac::hoa::CodecConfig::Deserialize dans /System/Library/Frameworks/AudioToolbox.framework/AudioCodecs.
APAC est l’Apple Positional Audio Codec
HOA signifie Higher-order Ambisonics.
Si vous regardez un exemple de fichier du traqueur de problèmes ffmpeg :
$ avmediainfo ~/Downloads/clap.MOV
Asset: /Users/zhuowei/Downloads/clap.MOV
<...>
Track 3: Sound 'soun'
Enabled: No
Format Description 1:
Format: APAC 'apac'
Channel Layout: High-Order Ambisonics, ACN/SN3D
Sample rate: 48000.0
Bytes per packet: 0
Frames per packet: 1024
Bytes per frame: 0
Channels per frame: 4
Bits per channel: 0
System support for decoding this track: Yes
Data size: 43577 bytes
Media time scale: 48000
Duration: 0.898 seconds
Estimated data rate: 363.142 kbit/s
Extended language tag: und
1 segment present
Index Media Start Media Duration Track Start Track Duration
1 00:00:00.000 00:00:00.898 00:00:00.000 00:00:00.898
Member of alternate group 0: (2, 3)
Vous pouvez convertir en APAC avec afconvert -o sound440.m4a -d apac -f mp4f sound440hz.wav.
En utilisant bindiff sur iOS 18.4.1 vs 18.4, il semble que la lecture de mRemappingArray vérifie désormais le AudioChannelLayout* global à l’offset 0x58 pour le nombre de canaux au lieu du AudioChannelLayout* de remappage à l’offset 0x78.
Le fichier encodeme.mm encode l’APAC, et un script LLDB force des éléments supplémentaires dans mRemappingArray et le AudioChannelLayout de remappage :
./build_encodeme.sh
./run_encodeme.sh