blog-source/output/feeds/feed.rss.hacking.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>&lt;p&gt;Comme vous avez pu le lire dans les médias, Saurik (Jay Freeman, connu
pour avoir développé Cydia, un &amp;ldquo;app store&amp;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&amp;hellip;), a trouvé intéressant d&amp;rsquo;obtenir un accès root
sur celles-ci, ce qu&amp;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&amp;rsquo;extraire l&amp;rsquo;OS, de le rooter hors-fonctionnement, puis de le
réinstaller, rooté, sur les lunettes.&lt;/p&gt;
&lt;p&gt;Le fait est que de débloquer le bootloader laisse une trace permanente
sur les lunettes, et que Saurik n&amp;rsquo;a pas utilisé cette technique pour
rooter sa paire. Voyons comment il a fait :&lt;/p&gt;
&lt;p&gt;&lt;em&gt;Je tiens tout d&amp;rsquo;abord a préciser que toutes les informations qui vont
suivre sont extraites de &lt;a href="http://www.saurik.com/id/16"&gt;cet article&lt;/a&gt;, et plus précisément de la
partie &amp;ldquo;How does this exploit work&amp;rdquo;.  Je tente d&amp;rsquo;apporter ma maigre
contribution a cette explication.&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;Donc, d&amp;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&amp;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.&lt;/p&gt;
&lt;p&gt;Saurik a donc cherché un exploit connu pour cette version d&amp;rsquo;android, et
l&amp;rsquo;a appliqué a son problème. L&amp;rsquo;exploit en question est relativement
simple. Depuis la version 4.0 d&amp;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&amp;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&amp;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&amp;rsquo;application. Lors de la restauration, le système supprime la
configuration existante, puis la remplace par celle dans l&amp;rsquo;archive gzip.&lt;/p&gt;
&lt;p&gt;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&amp;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&amp;rsquo;il
fonctionne dans une VM ou sur un véritable appareil. S&amp;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&amp;rsquo;on cherche pour l&amp;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&amp;rsquo;android,
dont l&amp;rsquo;application paramètres, et, dans ce cas précis, l&amp;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.&lt;/p&gt;
&lt;p&gt;Cependant, un problème reste : le système de restauration d&amp;rsquo;Android
vérifie les données avant de restaurer, et ne restaure pas les symlinks,
ce qui nous empêche d&amp;rsquo;avoir accès directement a /data/local.prop, le
fichier qu&amp;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&amp;rsquo;écrire dans ce dossier.&lt;/p&gt;
&lt;p&gt;Donc, nous allons lancer deux processus en même temps :  &lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;Le premier tentera en boucle de créer le symlink. Il sera consitué de
    la commande suivante, depuis un shell sur les lunettes :&lt;/p&gt;
&lt;div class="codehilite" style="background: #272822"&gt;&lt;pre style="line-height: 125%"&gt;while ! ln -s /data/local.prop /data/data/com.google.glass.logging/whatev/x 2&amp;gt;/dev/null
do :
done
&lt;/pre&gt;&lt;/div&gt;


&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;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&amp;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&amp;rsquo;ordinateur host :&lt;/p&gt;
&lt;div class="codehilite" style="background: #272822"&gt;&lt;pre style="line-height: 125%"&gt;adb restore exploit.ab
&lt;/pre&gt;&lt;/div&gt;


&lt;p&gt;Ces commandes vont fonctionner de concert pour nous donner un accès root :&lt;br /&gt;
- Le processus de restauration va créer le dossier whatev, qui sera
    world-readable. Il va commencer a copier le fichier bigfile.&lt;br /&gt;
- 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&amp;rsquo;âme proprement.&lt;br /&gt;
- 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.&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;And voilà! On a écrit ce que l&amp;rsquo;on veut dans /data/local.prop, ce qui
nous permet de faire croire a android qu&amp;rsquo;il tourne dans une machine
virtuelle (ce que l&amp;rsquo;on veut, c&amp;rsquo;est en fait &amp;ldquo;ro.kernel.qemu=1&amp;rdquo;, qui
indique au noyau qu&amp;rsquo;il tourne dans qemu, un système de VM).&lt;/p&gt;
&lt;p&gt;Il nous reste a rebooter, depuis l&amp;rsquo;ordinateur host :&lt;/p&gt;
&lt;div class="codehilite" style="background: #272822"&gt;&lt;pre style="line-height: 125%"&gt;adb reboot
&lt;/pre&gt;&lt;/div&gt;


&lt;p&gt;Puis nous remontons la partitions système en lecture/écriture (r/w),
depuis le host :&lt;/p&gt;
&lt;div class="codehilite" style="background: #272822"&gt;&lt;pre style="line-height: 125%"&gt;adb shell &amp;quot;mount -o remount,rw /system&amp;quot;
&lt;/pre&gt;&lt;/div&gt;


&lt;p&gt;Nous copions le binaire &lt;a href="https://data.wxcafe.net/uploads/android/glass/su"&gt;su&lt;/a&gt; vers l&amp;rsquo;appareil :&lt;/p&gt;
&lt;div class="codehilite" style="background: #272822"&gt;&lt;pre style="line-height: 125%"&gt;adb push su /system/xbin
&lt;/pre&gt;&lt;/div&gt;


&lt;p&gt;Nous donnons les bonnes permissions a ce binaire, afin de pouvoir
l’exécuter plus tard :&lt;/p&gt;
&lt;div class="codehilite" style="background: #272822"&gt;&lt;pre style="line-height: 125%"&gt;adb shell &amp;quot;chmod 6755 /system/xbin/su&amp;quot;
&lt;/pre&gt;&lt;/div&gt;


&lt;p&gt;Ensuite, nous supprimons le fichier /data/local.prop, pour pouvoir
redémarrer normalement :&lt;/p&gt;
&lt;div class="codehilite" style="background: #272822"&gt;&lt;pre style="line-height: 125%"&gt;adb shell &amp;quot;rm /data/local.prop&amp;quot;
&lt;/pre&gt;&lt;/div&gt;


&lt;p&gt;Enfin, nous redemarrons a nouveau :&lt;/p&gt;
&lt;div class="codehilite" style="background: #272822"&gt;&lt;pre style="line-height: 125%"&gt;adb reboot
&lt;/pre&gt;&lt;/div&gt;


&lt;p&gt;Et voila, une paire de google glass rootée!&lt;/p&gt;
&lt;p&gt;Il est bon de préciser que cette manipulation n&amp;rsquo;est possible que parce
que les lunettes tournent sous une ancienne version d&amp;rsquo;android, et que ce
bug a été fixé depuis.&lt;/p&gt;
&lt;p&gt;Il serait aussi interessant de couvrir les problèmes de vie privée
qu&amp;rsquo;engendrent les Google Glass, et ce sera fait dans un autre billet.&lt;/p&gt;
&lt;p&gt;A bientôt!&lt;/p&gt;</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>