ZendTo 6.15-8 / RCE ClamAV con profilo esatto e riproduzione della variante root

Questa directory è un bundle autonomo di riproduzione per laboratorio autorizzato della catena di esecuzione di codice senza account da ZendTo a ClamAV e della sua continuazione separata Smarty/cron-root con profilo predefinito. Include:

• la chiusura completa ed eseguibile delle dipendenze del PoC;
• script e provenienza per costruire la topologia Docker di destinazione;
• una definizione Docker Compose corrispondente al ciclo di vita systemd/socket testato;
• controlli fail-closed su immagine, pacchetti, binari, configurazione, CVD, DAC, cron, PHP, MAC e semantica del filesystem; e
• helper per l'unica capacità di verifica solo-laboratorio e per la pulizia.

Il PoC iniziale esegue un comando scelto dal chiamante con l'account di servizio standard clamav. La variante opzionale estende quel punto d'appoggio senza account fino a un comando scelto dal chiamante come root. Entrambi usano id come predefinito, rifiutano il percorso letterale /root/flag e restituiscono output vincolato a un nonce su HTTPS.

Le relazioni vulnerabili tra gruppo, directory, Smarty e cron-root sono i valori predefiniti del pacchetto/installer Debian di ZendTo. La raggiungibilità di root è comunque condizionata dall'ambiente: questo esatto fixture positivo usa un volume /var/zendto su ext4, PHP CLI funzionante con FFI/POSIX/exec e un processo clamd senza confinamento. L'applicazione di AppArmor/SELinux o di semantiche del filesystem incompatibili può bloccare la continuazione su un'altra installazione altrimenti standard.

Usalo solo sul fixture usa-e-getta incluso o su un altro sistema che sei esplicitamente autorizzato a testare.

Cosa viene fissato

Il target esatto di riferimento è un artefatto locale, volutamente senza versione, al percorso:

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

Git ignora gli archivi delle immagini Docker. Prima della regressione esatta, inserisci una copia locale autorizzata in quel percorso; scripts/setup.sh richiede lo SHA-256 e l'ID immagine registrati. source-recipe/README.md documenta come l'immagine derivata dall'installer è stata costruita e acquisita. Una nuova build dai repository di pacchetti live è utile per testare la topologia, ma non è considerata byte-identica al target fissato.

Lo script di setup e l'entrypoint del container rifiutano qualsiasi discrepanza rispetto al seguente profilo:

Componente	Valore esatto testato
Docker image ID	sha256:de6d2f06ca04943362a9bdec5026e808448953728f31bd926343a4ed2ca2ef7c
ZendTo	6.15-8
ClamAV/libclamav package	1.4.3+dfsg-1~deb12u2
libclamav	libclamav.so.12.0.3, SHA-256 55e3cd94…027c
libclamav Build ID	e6427ab62146ee3001fe463d12e797e9d25bf81a
glibc	2.36-9+deb12u14, SHA-256 6b4a4535…421
main database	v63, SHA-256 0b2182d2…365
daily database	v28082, SHA-256 cddbcccf…906
bytecode database	v339, SHA-256 6d4aa01f…ffb
clamd	MaxThreads 12, IdleTimeout 30, Restart=no
ciclo di vita	clamav-daemon.socket abilitato, systemd PID 1
web runtime	Apache 2.4.68, PHP 8.2.32
postura MAC	fixture Docker privilegiato e non confinato
ponte root	clamav standard in www-data; /var/zendto root:www-data 0775
consumatore root	cron di pulizia root standard, ogni ora al minuto 25
cache Smarty	zendto.conf compilato deterministico Smarty 4.5.4
filesystem di scambio	volume nominato /var/zendto su ext4

I valori completi sono in PROFILE.json.

Questo è un vincolo più forte del fissare solo la versione del pacchetto ClamAV. La costruzione dell'allocator dipende anche da glibc, dal traffico del parser guidato dai CVD, dalle impostazioni dei worker e dalla libreria target esatta. FreshClam è disabilitato nell'immagine acquisita e l'avvio fallisce se daily.cvd è cambiato o se è comparso un daily.cld.

Il container di ricerca attualmente in esecuzione da molto tempo nel workspace padre non è il fixture pulito: i test successivi hanno disabilitato il suo modulo per i mittenti esterni e aggiornato il suo database daily. Queste modifiche sono volutamente escluse qui. Questo bundle usa la baseline pulita contro cui è stata dimostrata l'esecuzione nativa.

Requisiti dell'host

• Linux x86-64 con Docker Engine e Docker Compose v2
• permesso di eseguire container privilegiati
• cgroup v2 e /sys/fs/cgroup
• zstd, Python 3 con venv, un compilatore C, file e GNU readelf
• memoria sufficiente per i parser nativi di ClamAV senza un limite di container restrittivo
• almeno 1 GiB di spazio disco libero per l'artefatto immagine locale e per il target in esecuzione

Il target condivide il kernel dell'host e l'implementazione di ASLR. Il comportamento dei mapping dipendente dal kernel rimane quindi una variabile di portabilità.

Un solo fixture systemd dovrebbe condividere il namespace cgroup dell'host alla volta. Sulla macchina di ricerca originale, ferma il fixture più vecchio senza eliminarlo:

docker stop zendto-installer-systemd-native

Può essere ripristinato in seguito con docker start zendto-installer-systemd-native.

Avvia il target esatto

Da questa directory:

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

Lo script di setup:

1. verifica il manifest immutabile delle sorgenti e lo SHA-256 dell'immagine locale;
2. carica e ri-taggia l'immagine esatta senza contattare un registry;
3. crea .venv con le dipendenze Python del PoC fissate;
4. ricompila il piccolo helper PESpin locale per la libc dell'operatore;
5. verifica l'artefatto libclamav locale e tutte le finestre di gadget del target;
6. valida il modello Compose;
7. crea un nuovo volume nominato /var/zendto e avvia systemd; e
8. verifica versioni dei pacchetti, hash del target, CVD, Apache, clamd e attivazione via socket; e
9. dimostra i prerequisiti predefiniti della variante root, inclusa un'operazione usa-e-getta renameat2(RENAME_EXCHANGE) eseguita come clamav.

Gli endpoint predefiniti sono solo loopback:

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

Il certificato è autofirmato. Il PoC usa deliberatamente verify=False per ogni richiesta HTTP. È possibile selezionare porte loopback diverse prima del setup:

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

Usa le stesse variabili d'ambiente per i successivi comandi Compose/helper.

Controlla il target in qualsiasi momento:

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

Il confine CAPTCHA/email in questo fixture

La baseline pulita dell'installer ha:

allowExternalUploads = TRUE
confirmExternalEmails = TRUE
captcha = google

I suoi valori CAPTCHA e mail sono segnaposto dell'installer, quindi l'archivio non modificato non può realmente consegnare l'email di verifica pubblica. Il test di regressione nativo ha rappresentato solo quel passaggio applicativo completato con una riga AuthData equivalente per mittente esterno. Il codice target, i pacchetti, lo scanner, i permessi e il percorso di exploit non sono stati patchati.

Crea quella singola riga di laboratorio e un file token con modalità 0600 con:

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

Il valore del token è soppresso e salvato in:

.lab/upload-auth-token.txt

Questo helper locale non è un'affermazione che una distribuzione con upload esterni disabilitati possa essere sfruttata da remoto. Se il modulo pubblico per mittenti esterni è disabilitato, il PoC si ferma correttamente prima di ClamAV anche quando viene fornito un file token.

Su una distribuzione autorizzata configurata normalmente, ometti --external-auth-token-file: apri manualmente la pagina di verifica, risolvi il CAPTCHA, ricevi il messaggio generato dal target su una casella di posta controllata dall'attaccante e incolla il suo URL/token al prompt nascosto.