Proof-of-concept für den CoreAudio-Patch (CVE-2025-31200) in iOS 18.4.1. Ausführliche Beschreibung hier: https://blog.noahhw.dev/posts/cve-2025-31200/.

Aktualisierung 05/27/2025

Ich habe es geschafft, dies zu einem kontrollierten, wenn nicht sogar beliebigen Schreibzugriff auszuweiten. Die ausführliche Beschreibung folgt bald. Um es selbst zu sehen, müsst ihr auf einer macOS-Version vor dem Patch bauen: < 15.4.1. Ihr könnt die Audiodatei mit dem check-mismatch-lldb-Hook abspielen (mithilfe eines einfachen Wrappers, der nur das Audio abspielt), um den Schreibzugriff zu beobachten. Es ist noch kein großartiger beliebiger Schreibzugriff, wie oben erwähnt, aus mehreren Gründen – hauptsächlich, weil ich mir immer noch nicht zu 100 % sicher bin, in welcher Phase der Dekodierungspipeline diese Werte aus dem Framebuffer beim Remapping vorliegen. Ich höre hier jedoch auf, um an der ausführlichen Beschreibung zu arbeiten, falls jemand das übernehmen möchte.

Aktualisierung 05/21/2025

Ich @noahhw46 (ohne dieses Setup @zhouwei hätte ich es nicht geschafft) habe es herausgefunden (ausführliche Beschreibung folgt). Es gibt jedoch noch viel mehr zu verstehen. Ich habe hier den ersten Teil der nächsten Schritte meiner Untersuchung hinzugefügt, um genau zu zeigen, was der Fehler tut. check-mismatch ist ein weiteres lldb-Skript, das mit einem funktionierenden PoC verwendet werden kann, um genau die Diskrepanz zu zeigen, die zwischen dem mRemappingArray und der Permutationskarte in APACChannelRemapper::Process (eigentlich in APACHOADecoder::DecodeAPACFrame) erzeugt wurde.

The mRemappingArray is sized based on the lower two bytes of mChannelLayoutTag.
By creating a mismatch between them, a later stage of processing in APACHOADecoder::DecodeAPACFrame is corrupted.
When the APACHOADecoder goes to process the APAC frame (permute it according to the channel remapping array), it uses the mRemappingArray as the permutation map to do the well, channel remapping. It seems like the frame data that is being remapped is sized based on mTotalComponenets.

Wenn du die Audiodatei output.mp4 abspielst (z. B. mit AVAudioPlayer), wird APACChannelRemapper::Process außerhalb der Grenzen lesen und dann schreiben.

Du kannst den ersten Lesevorgang außerhalb der Grenzen sehen, wenn du Guard Malloc in Xcode aktivierst:

Xcode zeigt Absturz in APACChannelRemapper::Process an

Ohne Guard Malloc wird APACHOADecoder::DecodeAPACFrame später mit einem ungültigen memmove abstürzen:

Xcode zeigt Absturz in _platform_memmove an

Nachfolgend die vorherige README von @zhuowei:

Trying to understand the CoreAudio patch (CVE-2025-31200) in iOS 18.4.1.

I haven't figure it out yet.

Currently, I get different error messages when decoding output.mp4 on 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 Xcode-Simulator für 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

also stoße ich auf die neue Prüfung, weiß aber nicht, wie ich sie dazu bringe, tatsächlich etwas zu überschreiben.

Informationen zur geänderten Funktion

Die geänderte Funktion scheint apac::hoa::CodecConfig::Deserialize in /System/Library/Frameworks/AudioToolbox.framework/AudioCodecs zu sein.

APAC ist Apple Positional Audio Codec.

HOA ist Higher-order Ambisonics.

Wenn du dir eine Beispieldatei aus dem ffmpeg-Issue-Tracker ansiehst:

$ 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)

Du kannst mit afconvert -o sound440.m4a -d apac -f mp4f sound440hz.wav in APAC konvertieren.

Mit bindiff unter iOS 18.4.1 vs. 18.4 scheint das Lesen von mRemappingArray nun die globale AudioChannelLayout* an Offset 0x58 auf die Anzahl der Kanäle zu überprüfen, anstatt der remappenden AudioChannelLayout* an Offset 0x78.

Die Datei encodeme.mm kodiert APAC, und ein LLDB-Skript erzwingt zusätzliche Elemente in mRemappingArray und das remappende AudioChannelLayout:

./build_encodeme.sh
./run_encodeme.sh

apple-positional-audio-codec-invalid-header

Beliebteste