Minecraft Java : Faille de sécurité sur la 1.8

Le développeur Punkeel a publié sur son blog un article détaillant une faille de sécurité présente de la version 1.8 à la version 1.8.9 de Minecraft Java. Celle-ci consiste à détourner le fonctionnement du mécanisme permettant de charger un ressource pack serveur en allant chercher un fichier qui n'est pas forcément dans le dossier server-resource-packs et qui n'est pas forcément un zip.

Cette faille peut permettre à un serveur de deviner si vous exécutez Windows, mac OS ou linux, via les fichiers spécifiques à ces OS que vous auriez. Il peut également deviner votre nom d'utilisateur local et savoir si vous avez installé tel ou tel programme (ou tel ou tel mod). En revanche cette faille ne permet PAS au serveur attaquant de lire le contenu des fichiers de votre ordinateur.

Pour vous protéger de cette faille, vous avez 3 possibilités :

• Utiliser une version supérieure du jeu, au minimum la 1.9. Il faut savoir que vous serez protégé avec les versions supérieures même si le serveur accepte les clients 1.8
• Activer le chargement des ressource pack sur le serveur. En faisant ça, vous aurez un freeze de chargement de pack lorsqu'un serveur découvrira un fichier que vous possédez
• Utiliser le mod Resource Exploit Fix qui permet de refuser toute tentative d'exploitation de la faille et de vous alerter si un serveur souhaite le faire.

Pour comprendre la faille, il faut d'abord savoir comment fonctionne le système de ressource pack serveur dans Minecraft Java. Attention, cette partie sera très technique.

Le serveur va tout d'abord envoyer au client l'adresse de téléchargement du ressource pack, ainsi qu'un hash qui ne nous intéressera pas pour cet article.
En réponse, le client renverra le hash, ainsi que l'information si le pack a bien été téléchargé, si le téléchargement a échoué, ou si l'utilisateur a refusé le téléchargement de ressource pack (correspond aux réglages définis pas l'utilisateur sur le serveur.


Ci dessous un récapitulatif de ce mécanisme.


Néanmoins, ce qui est important, c'est le cas ou le pack est déjà téléchargé et qu'il a juste a être chargé par le client. La démarche est la même, sauf que l'URL ne commencera plus par http(s):// mais par level:// et que les résultats que peut émettre le client sont maintenant "accepted" ou "failed download". Par ailleurs, la signification des codes changent. Voici la comparaison entre le sens des différents code :



Ainsi, pour charger un pack, l'échange client-serveur sera de ce style :



C'est là ou se situe la faille. La faille est due à 2 problèmes :

• Il est possible de mettre "../" dans le champ "URL" afin de remonter plus haut que le dossier server-resource-packs et ainsi parcourir toute l'arborescence
• Les résultats accepted ou failed downloadne correspondent pas à si les ressources du pack ont bien été chargées dans le jeu. Ils correspondent au fait que le jeu a bien reconnu la ressource indiquée dans le champ URL comme étant un fichier. Ainsi, même un joueur qui a désactivé ses ressource pack pourrait renvoyer le code "accepted"!!

Voici un exemple d'échange ou je recherche si je dispose à la racine de mon disque dur un fichier appelé frm.txt. Voilà à quoi ressemblera l'échange :


Ainsi, on peut voir qu'il suffit de répéter cet échange en changeant juste l'URL pour savoir si un fichier existe sur le disque dur. J'ai ainsi créé un plugin minimaliste qui recherche les noms de fichiers .txt à 3 caractère se trouvant à la racine de mon disque (j'en ai créé un appelé frm.txt) lors de l'exécution de la commande /start.

On peut voir que le fichier est trouvé de cette manière :


A noter que avec la 1.9, ou avec le mod évoqué plus haut, le client vérifiera si l'adresse contient la chaine de caractère "..". La 1.9 renverra failed download, le mod ne renverra rien.