ZendTo 6.15-8 / reproduction de la RCE ClamAV à profil exact et de la variante root

Ce répertoire est un ensemble autonome de reproduction en laboratoire autorisé pour la chaîne d'exécution de code ZendTo-vers-ClamAV sans compte et sa continuation séparée Smarty/cron root basée sur le profil par défaut. Il comprend :

• la fermeture complète des dépendances du PoC exécutable ;
• des scripts et la provenance pour construire la topologie cible Docker ;
• une définition Docker Compose correspondant au cycle de vie systemd/socket testé ;
• des vérifications fail-closed de l'image, des paquets, des binaires, de la configuration, des CVD, du DAC, de cron, de PHP, du MAC et de la sémantique du système de fichiers ; et
• des utilitaires pour la seule capacité de vérification réservée au laboratoire et pour le nettoyage.

Le PoC initial exécute une commande choisie par l'appelant sous le compte de service clamav standard. La variante optionnelle poursuit ce point d'appui sans compte jusqu'à une commande choisie par l'appelant exécutée en root. Les deux utilisent id par défaut, rejettent le chemin littéral /root/flag et renvoient une sortie liée à un nonce sur HTTPS.

Les relations vulnérables de groupe, de répertoire, de Smarty et de cron root sont les valeurs par défaut du paquet/installeur Debian ZendTo. L'atteignabilité de root reste néanmoins conditionnée à l'environnement : ce montage positif exact utilise un volume /var/zendto sur ext4, un PHP CLI fonctionnel avec FFI/POSIX/exec, et un processus clamd non confiné. L'application d'AppArmor/SELinux ou de sémantiques de système de fichiers incompatibles peut bloquer la continuation sur une autre installation par ailleurs standard.

Utilisez ceci uniquement sur le montage jetable inclus ou sur un autre système que vous êtes explicitement autorisé à tester.

Ce qui est épinglé

La cible exacte de référence est un artefact local, volontairement non versionné, situé à :

image/zendto-installer-systemd-debian12.tar.zst

Git ignore les archives d'images Docker. Avant une régression exacte, placez une copie locale autorisée à ce chemin ; scripts/setup.sh exige son SHA-256 et son identifiant d'image enregistrés. source-recipe/README.md documente comment l'image dérivée de l'installeur a été construite et capturée. Une nouvelle construction à partir des dépôts de paquets en direct est utile pour tester la topologie, mais n'est pas présumée identique octet pour octet à la cible épinglée.

Le script d'installation et le point d'entrée du conteneur rejettent toute divergence par rapport au profil suivant :

Composant	Valeur testée exacte
Identifiant d'image Docker	sha256:de6d2f06ca04943362a9bdec5026e808448953728f31bd926343a4ed2ca2ef7c
ZendTo	6.15-8
Paquet ClamAV/libclamav	1.4.3+dfsg-1~deb12u2
libclamav	libclamav.so.12.0.3, SHA-256 55e3cd94…027c
Build ID libclamav	e6427ab62146ee3001fe463d12e797e9d25bf81a
glibc	2.36-9+deb12u14, SHA-256 6b4a4535…421
Base de données principale	v63, SHA-256 0b2182d2…365
Base de données quotidienne	v28082, SHA-256 cddbcccf…906
Base de données bytecode	v339, SHA-256 6d4aa01f…ffb
clamd	MaxThreads 12, IdleTimeout 30, Restart=no
Cycle de vie	clamav-daemon.socket activée, systemd PID 1
Environnement d'exécution web	Apache 2.4.68, PHP 8.2.32
Posture MAC	montage Docker privilégié non confiné
Pont root	clamav standard dans www-data ; /var/zendto root:www-data 0775
Consommateur root	cron de nettoyage root standard, toutes les heures à la minute 25
Cache Smarty	compilation déterministe de zendto.conf par Smarty 4.5.4
Système de fichiers d'échange	volume nommé /var/zendto sur ext4

Les valeurs complètes figurent dans PROFILE.json.

C'est plus fort que d'épingler uniquement la version du paquet ClamAV. La construction de l'allocateur dépend également de glibc, du trafic d'analyse piloté par les CVD, des paramètres des workers et de la bibliothèque cible exacte. FreshClam est désactivé dans l'image capturée, et le démarrage échoue si daily.cvd a dérivé ou si un daily.cld est apparu.

Le conteneur de recherche qui tourne actuellement depuis longtemps dans l'espace de travail parent n'est pas le montage propre : des tests ultérieurs ont désactivé son formulaire d'expéditeur externe et mis à jour sa base de données quotidienne. Ces modifications sont volontairement exclues ici. Cet ensemble utilise la base de référence propre sur laquelle l'exécution native a été démontrée.

Prérequis hôte

• Linux x86-64 avec Docker Engine et Docker Compose v2
• autorisation d'exécuter des conteneurs privilégiés
• cgroup v2 et /sys/fs/cgroup
• zstd, Python 3 avec venv, un compilateur C, file et GNU readelf
• suffisamment de mémoire pour les analyseurs natifs de ClamAV sans limite de conteneur stricte
• au moins 1 GiB d'espace disque libre pour l'artefact d'image local et la cible en cours d'exécution

La cible partage le noyau hôte et l'implémentation ASLR. Le comportement de mappage dépendant du noyau reste donc une variable de portabilité.

Un seul montage systemd doit partager l'espace de noms cgroup de l'hôte à la fois. Sur la machine de recherche d'origine, arrêtez l'ancien montage sans le supprimer :

docker stop zendto-installer-systemd-native

Il peut ensuite être restauré avec docker start zendto-installer-systemd-native.

Démarrer la cible exacte

Depuis ce répertoire :

./scripts/verify-bundle.sh
./scripts/setup.sh

Le script d'installation :

1. vérifie le manifeste source immuable et le SHA-256 de l'image locale ;
2. charge et réétiquette l'image exacte sans contacter de registre ;
3. crée .venv avec les dépendances Python épinglées du PoC ;
4. reconstruit le petit utilitaire local PESpin pour la libc de l'opérateur ;
5. vérifie l'artefact libclamav local et toutes les fenêtres de gadgets cibles ;
6. valide le modèle Compose ;
7. crée un nouveau volume nommé /var/zendto et démarre systemd ; et
8. vérifie les versions des paquets, les hachages cibles, les CVD, Apache, clamd et l'activation par socket ; et
9. prouve les prérequis par défaut de la variante root, y compris une opération jetable renameat2(RENAME_EXCHANGE) effectuée en tant que clamav.

Les points de terminaison par défaut sont limités au loopback :

http://127.0.0.1:18084/
https://127.0.0.1:18447/

Le certificat est auto-signé. Le PoC utilise volontairement verify=False pour chaque requête HTTP. D'autres ports de loopback peuvent être sélectionnés avant l'installation :

export ZENDTO_HTTP_PORT=19084
export ZENDTO_HTTPS_PORT=19447
./scripts/setup.sh

Utilisez les mêmes variables d'environnement pour les commandes Compose/utilitaires ultérieures.

Vérifiez la cible à tout moment :

./scripts/verify-target.sh
docker compose ps

La frontière CAPTCHA/e-mail dans ce montage

La base de référence propre de l'installeur contient :

allowExternalUploads = TRUE
confirmExternalEmails = TRUE
captcha = google

Ses valeurs CAPTCHA et e-mail sont des espaces réservés de l'installeur, de sorte que l'archive non modifiée ne peut pas réellement délivrer l'e-mail de vérification public. Les tests de régression natifs n'ont représenté que cette étape applicative terminée, via une ligne AuthData équivalente d'expéditeur externe. Le code cible, les paquets, le scanner, les permissions et le chemin d'exploitation n'ont pas été corrigés.

Créez cette unique ligne de laboratoire et un fichier de jeton en mode 0600 avec :

./scripts/mint-lab-auth.py [email protected]

La valeur du jeton est masquée et stockée à :

.lab/upload-auth-token.txt