148 lines
6.8 KiB
Markdown
148 lines
6.8 KiB
Markdown
|
Title: Comment Saurik a rooté les Google Glass
|
|||
|
Date: 2013-05-06 06:24
|
|||
|
Author: Wxcafe
|
|||
|
Category: Hacking
|
|||
|
Slug: comment-saurik-a-roote-les-google-glass
|
|||
|
|
|||
|
Comme vous avez pu le lire dans les médias, Saurik (Jay Freeman, connu
|
|||
|
pour avoir développé Cydia, un "app store" alternatif pour les iTrucs),
|
|||
|
après avoir reçu une paire de Google glass de la part de Google (de
|
|||
|
façon assez évidente...), a trouvé intéressant d'obtenir un accès root
|
|||
|
sur celles-ci, ce qu'il a accompli très rapidement. Des démentis de la
|
|||
|
part de Google et de certains autres sites sont vite arrivés, disant que
|
|||
|
les lunettes possédaient un bootloader débloqué et que de fait, le root
|
|||
|
était facile a obtenir : il suffisait de débloquer le bootloader,
|
|||
|
d'extraire l'OS, de le rooter hors-fonctionnement, puis de le
|
|||
|
réinstaller, rooté, sur les lunettes.
|
|||
|
|
|||
|
Le fait est que de débloquer le bootloader laisse une trace permanente
|
|||
|
sur les lunettes, et que Saurik n'a pas utilisé cette technique pour
|
|||
|
rooter sa paire. Voyons comment il a fait :
|
|||
|
|
|||
|
_Je tiens tout d'abord a préciser que toutes les informations qui vont
|
|||
|
suivre sont extraites de [cet article][], et plus précisément de la
|
|||
|
partie "How does this exploit work". Je tente d'apporter ma maigre
|
|||
|
contribution a cette explication._
|
|||
|
|
|||
|
Donc, d'après les témoignages des quelques utilisateurs de Glass dans le
|
|||
|
monde, il semblerait que ces dernières fonctionnent avec un système
|
|||
|
d'exploitation Android, avec une nouvelle interface, mais avec les mêmes
|
|||
|
outils internes: un kernel Linux, des outils userland GNU et une machine
|
|||
|
virtuelle Java Dalvik pour les applications.
|
|||
|
|
|||
|
Saurik a donc cherché un exploit connu pour cette version d'android, et
|
|||
|
l'a appliqué a son problème. L'exploit en question est relativement
|
|||
|
simple. Depuis la version 4.0 d'android, le système permet la sauvegarde
|
|||
|
des données des différentes applications, une a une, via ADB (Android
|
|||
|
Debug Bridge, un protocole USB permettant l'accès a de nombreuses
|
|||
|
fonctions avancées des machines fonctionnant sous android, dont, entre
|
|||
|
autre, un shell, un accès au logs de debugging, etc... Cette
|
|||
|
fonctionnalité est bien entendu désactivable.) Ce backup est très simple :
|
|||
|
il crée un fichier .tgz contenant le dossier de configuration de
|
|||
|
l'application. Lors de la restauration, le système supprime la
|
|||
|
configuration existante, puis la remplace par celle dans l'archive gzip.
|
|||
|
|
|||
|
Le problème de sécurité vient du fait que les applications android
|
|||
|
voient leurs données stockées dans /data/data/identifiant/, et que
|
|||
|
/data/ a pour permissions drwxrwx--x 27 system system, ce qui
|
|||
|
signifie que seul system et les membres du groupe system peuvent lire
|
|||
|
dessus. Or, le fichier /data/local.prop définit de nombreux paramètres
|
|||
|
au démarrage, et notamment un qui permet au système de déterminer s'il
|
|||
|
fonctionne dans une VM ou sur un véritable appareil. S'il fonctionne sur
|
|||
|
une machine virtuelle, il donne les droits root a tout utilisateur se
|
|||
|
connectant via ADB, ce qui est ce que l'on cherche pour l'instant. Le
|
|||
|
fait que /data/ appartienne a system veut dire que le programme de
|
|||
|
restauration doit être setuid pour accéder aux données a l’intérieur qui
|
|||
|
appartiennent a root (soit toutes les applications système d'android,
|
|||
|
dont l'application paramètres, et, dans ce cas précis, l'application de
|
|||
|
log système présente sur les google glass de test. Ainsi, nous avons un
|
|||
|
processus tournant en tant que root, qui va écrire sur une partition qui
|
|||
|
nous intéresse des données que nous possédons.
|
|||
|
|
|||
|
Cependant, un problème reste : le système de restauration d'Android
|
|||
|
vérifie les données avant de restaurer, et ne restaure pas les symlinks,
|
|||
|
ce qui nous empêche d'avoir accès directement a /data/local.prop, le
|
|||
|
fichier qu'on cherche a modifier. Cela dit, il nous reste une
|
|||
|
possiblité. Plaçons un dossier world-writable dans le fichier de backup,
|
|||
|
et nous pourrons écrire dedans pendant quelques secondes, le temps que
|
|||
|
la restauration se termine et que le système remette les permissions en
|
|||
|
place. Ainsi, nous pouvons créer le fichier
|
|||
|
/data/local/com.google.glass.logging/whatev/x, lien vers
|
|||
|
/data/local.prop, et nous avons un toujours un processus tournant en
|
|||
|
tant que root qui est en train d'écrire dans ce dossier.
|
|||
|
|
|||
|
Donc, nous allons lancer deux processus en même temps :
|
|||
|
|
|||
|
- Le premier tentera en boucle de créer le symlink. Il sera consitué de
|
|||
|
la commande suivante, depuis un shell sur les lunettes :
|
|||
|
|
|||
|
while ! ln -s /data/local.prop /data/data/com.google.glass.logging/whatev/x 2>/dev/null
|
|||
|
do :
|
|||
|
done
|
|||
|
|
|||
|
- Le deuxième sera le processus de restauration de notre exploit. Celui
|
|||
|
ci, pour une plus grande chance de réussite, devra être suffisamment
|
|||
|
lourd : au moins \~50Mo. Il devra contenir whatev/bigfile et whatev/x,
|
|||
|
pour qu'il crée whatev, prenne du temps a copier bigfile, puis écrive
|
|||
|
dans x après que le symlink soit effectif. La commande sera, depuis
|
|||
|
l'ordinateur host :
|
|||
|
|
|||
|
adb restore exploit.ab
|
|||
|
|
|||
|
Ces commandes vont fonctionner de concert pour nous donner un accès root :
|
|||
|
- Le processus de restauration va créer le dossier whatev, qui sera
|
|||
|
world-readable. Il va commencer a copier le fichier bigfile.
|
|||
|
- Le processus de symlink va créer le lien
|
|||
|
/data/data/com.google.glass.logging/whatev/x, pointant vers
|
|||
|
/data/local.prop, puis rendre l'âme proprement.
|
|||
|
- Le processus de restauration, ayant enfin fini de copier
|
|||
|
whatev/bigfile, copiera les contenus que nous voulons dans whatev/x, qui
|
|||
|
est lié a /data/local.prop. Comme le processus est setuid root, il ne se
|
|||
|
rendra compte de rien, et écrira tout dans /data/local.prop.
|
|||
|
|
|||
|
And voilà! On a écrit ce que l'on veut dans /data/local.prop, ce qui
|
|||
|
nous permet de faire croire a android qu'il tourne dans une machine
|
|||
|
virtuelle (ce que l'on veut, c'est en fait "ro.kernel.qemu=1", qui
|
|||
|
indique au noyau qu'il tourne dans qemu, un système de VM).
|
|||
|
|
|||
|
Il nous reste a rebooter, depuis l'ordinateur host :
|
|||
|
|
|||
|
adb reboot
|
|||
|
|
|||
|
Puis nous remontons la partitions système en lecture/écriture (r/w),
|
|||
|
depuis le host :
|
|||
|
|
|||
|
adb shell "mount -o remount,rw /system"
|
|||
|
|
|||
|
Nous copions le binaire [su][] vers l'appareil :
|
|||
|
|
|||
|
adb push su /system/xbin
|
|||
|
|
|||
|
Nous donnons les bonnes permissions a ce binaire, afin de pouvoir
|
|||
|
l’exécuter plus tard :
|
|||
|
|
|||
|
adb shell "chmod 6755 /system/xbin/su"
|
|||
|
|
|||
|
Ensuite, nous supprimons le fichier /data/local.prop, pour pouvoir
|
|||
|
redémarrer normalement :
|
|||
|
|
|||
|
adb shell "rm /data/local.prop"
|
|||
|
|
|||
|
Enfin, nous redemarrons a nouveau :
|
|||
|
|
|||
|
adb reboot
|
|||
|
|
|||
|
Et voila, une paire de google glass rootée!
|
|||
|
|
|||
|
Il est bon de préciser que cette manipulation n'est possible que parce
|
|||
|
que les lunettes tournent sous une ancienne version d'android, et que ce
|
|||
|
bug a été fixé depuis.
|
|||
|
|
|||
|
Il serait aussi interessant de couvrir les problèmes de vie privée
|
|||
|
qu'engendrent les Google Glass, et ce sera fait dans un autre billet.
|
|||
|
|
|||
|
A bientôt!
|
|||
|
|
|||
|
[cet article]: http://www.saurik.com/id/16
|
|||
|
[su]: https://data.wxcafe.net/uploads/android/glass/su
|