zhuowei/apple-positional-audio-codec-invalid-headerCVE-2025-31200 - @Noahhw46 lo descubrió
Prueba de concepto para el parche de CoreAudio (CVE-2025-31200) en iOS 18.4.1. Artículo aquí https://blog.noahhw.dev/posts/cve-2025-31200/.
He logrado llevar esto a una escritura controlada, aunque no arbitraria. El artículo está por venir. Sin embargo, para comprobarlo por ti mismo, tendrás que compilar en una versión de macOS anterior al parche: < 15.4.1. Puedes reproducir el audio con el hook de lldb check-mismatch (usando un harness simple que solo reproduzca el audio) para ver la escritura. Aún no es una escritura arbitraria ideal, como mencioné antes por varias razones, principalmente porque todavía no estoy 100% seguro en qué etapa del pipeline de decodificación se encuentran estos valores del frame buffer cuando se reasignan. Sin embargo, me detengo aquí para trabajar en el artículo, por si alguien quiere continuar.
Yo (@noahhw46) (no podría haberlo logrado sin esta configuración @zhouwei) lo resolví (artículo próximamente). Sin embargo, aún queda mucho por entender. Agregué aquí la primera parte de los siguientes pasos de mi investigación para mostrar exactamente lo que hace el bug. check-mismatch es otro script de lldb que puede usarse con un PoC funcional para mostrar exactamente el desajuste creado entre mRemappingArray y el mapa de permutación en APACChannelRemapper::Process (realmente en APACHOADecoder::DecodeAPACFrame).
El tamaño de mRemappingArray se basa en los dos bytes inferiores de mChannelLayoutTag.
Al crear un desajuste entre ellos, se corrompe una etapa posterior del procesamiento en APACHOADecoder::DecodeAPACFrame.
Cuando APACHOADecoder procesa el frame APAC (permutándolo según el array de reasignación de canales), usa mRemappingArray como el mapa de permutación para realizar la reasignación de canales. Parece que los datos del frame que se están reasignando tienen un tamaño basado en mTotalComponenets.
Cuando reproduces el archivo de audio output.mp4 (por ejemplo, con AVAudioPlayer), APACChannelRemapper::Process leerá y luego escribirá fuera de los límites.
Puedes ver la primera lectura fuera de los límites si habilitas Guard Malloc en Xcode:
Sin Guard Malloc, APACHOADecoder::DecodeAPACFrame fallará más tarde con un memmove inválido:
El README anterior de @zhuowei está a continuación:
Intentando entender el parche de CoreAudio (CVE-2025-31200) en iOS 18.4.1.
Aún no lo he resuelto.
Actualmente, obtengo diferentes mensajes de error al decodificar output.mp4 en 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 el Simulador de Xcode para 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
así que estoy topando con la nueva comprobación, pero no sé cómo lograr que realmente sobrescriba algo.
La función modificada parece ser apac::hoa::CodecConfig::Deserialize en /System/Library/Frameworks/AudioToolbox.framework/AudioCodecs.
APAC es Apple Positional Audio Codec
HOA es Higher-order Ambisonics.
Si observas un archivo de ejemplo del rastreador de incidencias de 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)
Puedes convertir a APAC con afconvert -o sound440.m4a -d apac -f mp4f sound440hz.wav.
Usando bindiff en iOS 18.4.1 vs 18.4, parece que al leer mRemappingArray ahora se verifica el AudioChannelLayout* global en el offset 0x58 para el número de canales en lugar del AudioChannelLayout* de reasignación en el offset 0x78.
El archivo encodeme.mm codifica APAC, y un script de LLDB fuerza elementos adicionales en mRemappingArray y en el AudioChannelLayout de reasignación:
./build_encodeme.sh
./run_encodeme.sh