140 lines
9.3 KiB
XML
140 lines
9.3 KiB
XML
<?xml version="1.0" encoding="utf-8"?>
|
||
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Wxcafé</title><link>//wxcafe.net/</link><description></description><atom:link href="//wxcafe.net/feeds/feed.rss.hacking.xml" rel="self"></atom:link><lastBuildDate>Mon, 06 May 2013 06:24:00 +0200</lastBuildDate><item><title>Comment Saurik a rooté les Google Glass</title><link>//wxcafe.net/posts/comment-saurik-a-roote-les-google-glass/</link><description><p>Comme vous avez pu le lire dans les médias, Saurik (Jay Freeman, connu
|
||
pour avoir développé Cydia, un &ldquo;app store&rdquo; alternatif pour les iTrucs),
|
||
après avoir reçu une paire de Google glass de la part de Google (de
|
||
façon assez évidente&hellip;), a trouvé intéressant d&rsquo;obtenir un accès root
|
||
sur celles-ci, ce qu&rsquo;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&rsquo;extraire l&rsquo;OS, de le rooter hors-fonctionnement, puis de le
|
||
réinstaller, rooté, sur les lunettes.</p>
|
||
<p>Le fait est que de débloquer le bootloader laisse une trace permanente
|
||
sur les lunettes, et que Saurik n&rsquo;a pas utilisé cette technique pour
|
||
rooter sa paire. Voyons comment il a fait :</p>
|
||
<p><em>Je tiens tout d&rsquo;abord a préciser que toutes les informations qui vont
|
||
suivre sont extraites de <a href="http://www.saurik.com/id/16">cet article</a>, et plus précisément de la
|
||
partie &ldquo;How does this exploit work&rdquo;. Je tente d&rsquo;apporter ma maigre
|
||
contribution a cette explication.</em></p>
|
||
<p>Donc, d&rsquo;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&rsquo;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.</p>
|
||
<p>Saurik a donc cherché un exploit connu pour cette version d&rsquo;android, et
|
||
l&rsquo;a appliqué a son problème. L&rsquo;exploit en question est relativement
|
||
simple. Depuis la version 4.0 d&rsquo;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&rsquo;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&hellip; 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&rsquo;application. Lors de la restauration, le système supprime la
|
||
configuration existante, puis la remplace par celle dans l&rsquo;archive gzip.</p>
|
||
<p>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&ndash;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&rsquo;il
|
||
fonctionne dans une VM ou sur un véritable appareil. S&rsquo;il fonctionne sur
|
||
une machine virtuelle, il donne les droits root a tout utilisateur se
|
||
connectant via ADB, ce qui est ce que l&rsquo;on cherche pour l&rsquo;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&rsquo;android,
|
||
dont l&rsquo;application paramètres, et, dans ce cas précis, l&rsquo;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.</p>
|
||
<p>Cependant, un problème reste : le système de restauration d&rsquo;Android
|
||
vérifie les données avant de restaurer, et ne restaure pas les symlinks,
|
||
ce qui nous empêche d&rsquo;avoir accès directement a /data/local.prop, le
|
||
fichier qu&rsquo;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&rsquo;écrire dans ce dossier.</p>
|
||
<p>Donc, nous allons lancer deux processus en même temps : </p>
|
||
<ul>
|
||
<li>
|
||
<p>Le premier tentera en boucle de créer le symlink. Il sera consitué de
|
||
la commande suivante, depuis un shell sur les lunettes :</p>
|
||
<div class="codehilite" style="background: #272822"><pre style="line-height: 125%">while ! ln -s /data/local.prop /data/data/com.google.glass.logging/whatev/x 2&gt;/dev/null
|
||
do :
|
||
done
|
||
</pre></div>
|
||
|
||
|
||
</li>
|
||
<li>
|
||
<p>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&rsquo;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&rsquo;ordinateur host :</p>
|
||
<div class="codehilite" style="background: #272822"><pre style="line-height: 125%">adb restore exploit.ab
|
||
</pre></div>
|
||
|
||
|
||
<p>Ces commandes vont fonctionner de concert pour nous donner un accès root :<br />
|
||
- Le processus de restauration va créer le dossier whatev, qui sera
|
||
world-readable. Il va commencer a copier le fichier bigfile.<br />
|
||
- 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&rsquo;âme proprement.<br />
|
||
- 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.</p>
|
||
</li>
|
||
</ul>
|
||
<p>And voilà! On a écrit ce que l&rsquo;on veut dans /data/local.prop, ce qui
|
||
nous permet de faire croire a android qu&rsquo;il tourne dans une machine
|
||
virtuelle (ce que l&rsquo;on veut, c&rsquo;est en fait &ldquo;ro.kernel.qemu=1&rdquo;, qui
|
||
indique au noyau qu&rsquo;il tourne dans qemu, un système de VM).</p>
|
||
<p>Il nous reste a rebooter, depuis l&rsquo;ordinateur host :</p>
|
||
<div class="codehilite" style="background: #272822"><pre style="line-height: 125%">adb reboot
|
||
</pre></div>
|
||
|
||
|
||
<p>Puis nous remontons la partitions système en lecture/écriture (r/w),
|
||
depuis le host :</p>
|
||
<div class="codehilite" style="background: #272822"><pre style="line-height: 125%">adb shell &quot;mount -o remount,rw /system&quot;
|
||
</pre></div>
|
||
|
||
|
||
<p>Nous copions le binaire <a href="https://data.wxcafe.net/uploads/android/glass/su">su</a> vers l&rsquo;appareil :</p>
|
||
<div class="codehilite" style="background: #272822"><pre style="line-height: 125%">adb push su /system/xbin
|
||
</pre></div>
|
||
|
||
|
||
<p>Nous donnons les bonnes permissions a ce binaire, afin de pouvoir
|
||
l’exécuter plus tard :</p>
|
||
<div class="codehilite" style="background: #272822"><pre style="line-height: 125%">adb shell &quot;chmod 6755 /system/xbin/su&quot;
|
||
</pre></div>
|
||
|
||
|
||
<p>Ensuite, nous supprimons le fichier /data/local.prop, pour pouvoir
|
||
redémarrer normalement :</p>
|
||
<div class="codehilite" style="background: #272822"><pre style="line-height: 125%">adb shell &quot;rm /data/local.prop&quot;
|
||
</pre></div>
|
||
|
||
|
||
<p>Enfin, nous redemarrons a nouveau :</p>
|
||
<div class="codehilite" style="background: #272822"><pre style="line-height: 125%">adb reboot
|
||
</pre></div>
|
||
|
||
|
||
<p>Et voila, une paire de google glass rootée!</p>
|
||
<p>Il est bon de préciser que cette manipulation n&rsquo;est possible que parce
|
||
que les lunettes tournent sous une ancienne version d&rsquo;android, et que ce
|
||
bug a été fixé depuis.</p>
|
||
<p>Il serait aussi interessant de couvrir les problèmes de vie privée
|
||
qu&rsquo;engendrent les Google Glass, et ce sera fait dans un autre billet.</p>
|
||
<p>A bientôt!</p></description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Wxcafe</dc:creator><pubDate>Mon, 06 May 2013 06:24:00 +0200</pubDate><guid>tag:wxcafe.net,2013-05-06:posts/comment-saurik-a-roote-les-google-glass/</guid></item></channel></rss> |