copyfail-deconstructed

Leicht verständliche Version von CVE-2026-31431, einer Privilegienausweitungstechnik, die es jedem ermöglicht, Root zu werden. Der ursprüngliche Proof-of-Concept befindet sich hier: https://github.com/theori-io/copy-fail-CVE-2026-31431, ist jedoch stark komprimiert und minimiert, um einen möglichst kleinen Fußabdruck zu haben. Dieses Repository versucht, diesen Code in einer lesbareren Weise aufzuschlüsseln, einschließlich der Erklärung, was der Code tut, wie die Nutzlast geladen wird und wie verschiedene Architekturen angesprochen werden können. Siehe die technischere Ausarbeitung hier: https://xint.io/blog/copy-fail-linux-distributions.

Verwendung

Standardmäßig führt python3 copyfail.py x64-Shellcode aus, der /usr/bin/su ausnutzt. Sie können Ihre eigene Nutzlast bereitstellen, indem Sie python3 copyfail.py [pfad/zu/eigener/nutzlast.elf] ausführen. Als Beispiel gibt es einen ARM64-Shellcode-Assembler in payloads/. Um also auf ARM64-Geräten zu testen, sollten Sie zuerst eine minimierte Nutzlast mit unserem benutzerdefinierten Linker-Skript erstellen:

as -o shellcode_aarch64.o payloads/shellcode_aarch64.S
ld -nostdlib -static -o shellcode_aarch64.elf shellcode_aarch64.o
strip -s shellcode_aarch64.elf

Dann können Sie den Hauptexploit mit python3 copyfail.py shellcode_aarch64.elf ausführen.

Für die Ausführung in C:

1. Build (siehe unten)
2. ./c_copyfail führt denselben Standardshellcode wie oben aus.

• Sie können auch hier Ihre eigene Nutzlast mit ./c_copyfail [pfad/zu/eigener/nutzlast.elf] bereitstellen.

Für den Build der C-Version:

cd c_port
make

Insbesondere wird die Ziel-.S-Datei in ein Raw-Binary kompiliert, das als C-unsigned-char-Array ausgegeben wird:

gcc -c payloads/[shellcode].S
objcopy -O binary [shellcode].o [payload].raw
xxd -i [payload].raw > payload.txt

oder für 32-Bit x86:

gcc -c -m32 payloads/[shellcode].S
objcopy -O binary [shellcode].o [payload].raw
xxd -i [payload].raw > payload.txt

Sie können dann den Inhalt dieser Datei in Ihren Quellcode kopieren, oder Sie führen direkt ./c_copyfail.exe [pfad/zu/nutzlast.elf] aus, wobei payload.elf mit as + ld erzeugt wird, NICHT mit gcc + objcopy.

Behebungen

Um einen Exploit zu vermeiden, führen Sie aus:

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead 2>/dev/null

Wenn bereits ausgenutzt, können Sie die Maschine neu starten oder ausführen: echo 3 | sudo tee /proc/sys/vm/drop_caches

Erklärung

1. Der Kernel erlaubt es dem Benutzer, über den Socket-Typ AF_ALG mit der Crypto-API zu kommunizieren.

• Im Jahr 2017 wurde dem algif_aead-Teil der Crypto-API die "In-Place-Optimierung" hinzugefügt.
• Wenn Daten mit dem Systemaufruf splice() durch den Socket gesendet werden, legt der Kernel die tatsächlichen Page-Cache-Seiten der Datei, die gespliced wurde, in den Crypto-Arbeitsbereich ab.
• Der Crypto-Algorithmus authencsn behandelt seinen Ausgabepuffer als Scratch-Space und schreibt 4 Bytes über die vorgesehene Stelle hinaus.

2. Was ein hypothetischer Angreifer tun kann:

• Wähle eine beliebige lesbare Datei (in diesem Fall z. B. /usr/bin/su)
• Wähle einen Offset innerhalb dieser Datei, an dem der 4-Byte-Schreibvorgang erfolgen soll.
• Wähle einen 4-Byte-Wert zum Schreiben (Teil der assoziierten Daten in der AEAD-Operation).
• Schreibe Shellcode, um die Datei im Speicher zu überschreiben.

3. Page-Cache-Überschreibung bis hin zu Root:

• Der Kernel markiert die korrumpierte Seite nie als "dirty", die Datei erscheint unverändert.
• Beim Ausführen von /usr/bin/su liest der Kernel die Datei aus dem Page-Cache und erhält modifizierte Bytes.
• Durch wiederholtes 4-Byte-Schreiben (ca. 40 Mal) kann der UID-Check in /usr/bin/su überschrieben werden, sodass UID = 0 (Root) ist.
• Root-Shell für jeden Benutzer erreicht.

4. Abhilfe:

• Leere den Page-Cache, um modifizierte Dateien aus dem Speicher zu entfernen, sodass beim nächsten Mal von der Festplatte gelesen wird.
• Lade das Kernelmodul aus.
• Setze es auf die Blacklist, damit es nicht geladen wird.
• Wenn es sich um ein eingebautes Modul handelt, muss der Systemaufruf mit seccomp oder eBPF blockiert werden. Oder entferne es aus der Initialisierung und starte die Maschine neu.

Die su-Binärdatei ist im Speicher korrumpiert, sodass eine Dateimodifikation nicht erkannt wird. Um von der Festplatte wiederherzustellen, können Sie den Page-Cache leeren.