CVE-2025-24893_Analysis

Lab Docker autonomo che riproduce CVE-2025-24893, una SSTI-to-RCE non autenticata in XWiki SolrSearch, e confronta il comportamento della versione vulnerabile rispetto a quella patchata.

2. Struttura

L'unica differenza tra i due stack è la versione di XWiki. Tutto il resto, inclusi l'immagine del database e il driver JDBC, è identico, quindi qualsiasi cambiamento nel comportamento è dovuto alla correzione e a nient'altro.

3. Riprodurre la vulnerabilità (15.10.10)

Build e avvio:

Il primo build scarica e decomprime XWiki, operazione che richiede alcuni minuti. Attendi che Tomcat riporti l'avvio:

Completa la configurazione una tantum del primo avvio: apri http://localhost:8080 e completa la Distribution Wizard (installa il flavor predefinito XWiki Standard). Questo provvede a configurare l'interfaccia SolrSearch che l'exploit prende di mira. L'endpoint è raggiungibile dagli ospiti, quindi l'attacco stesso non richiede login; questa configurazione iniziale è l'unico passaggio che lo richiede.

Lancia l'exploit (non autenticato):

Output atteso sullo stack vulnerabile:

Opzionalmente mostra che l'esecuzione arriva al sistema operativo con un comando di sola lettura:

La stessa richiesta come one-liner curl:

Cattura uno screenshot dell'output per il report, poi smonta:

4. Riprodurre la correzione (15.10.11)

Completa di nuovo la Distribution Wizard su http://localhost:8080, poi esegui l'exploit identico:

Output atteso sullo stack patchato:

Cattura anche questo screenshot, poi ripristina:

Perché la correzione funziona

In 15.10.10 il blocco di output del feed emette il feed come una nuda espressione Velocity ($xwiki.feed.getFeedOutput($feed, 'rss_2.0')), quindi il feed - che riflette il testo di ricerca dell'utente - viene ripassato attraverso la pipeline di rendering di XWiki, dove un macro {{groovy}} incorporato viene eseguito. In 15.10.11 quel blocco è sostituito da una chiamata a un nuovo macro rawResponse (SolrSearchMacros.xml riga 954; il macro è definito in templates/macros.vm). rawResponse imposta esplicitamente il content type (application/rss+xml), scrive i byte del feed direttamente nella risposta con $response.writer.print(...) e chiama $xcontext.setFinished(true) per fermare qualsiasi ulteriore rendering, quindi il feed viene inviato verbatim e il blocco {{groovy}} incorporato non viene mai valutato. Commit della patch 67021db9b8ed26c2236a653269302a86bf01ef40, advisory GHSA-rr6p-3pfg-562j. L'advisory fornisce anche una soluzione manuale: modificare Main.SolrSearchMacros per usare lo stesso schema rawResponse, che chiude il sink senza aggiornare.

5. Determinismo e ripristino

• Ancorati: le versioni di XWiki (15.10.10 e 15.10.11), i checksum SHA-256 di WAR e JDBC, l'immagine di base tomcat:9-jre17, il database mysql:8.4 e la porta 8080.
• Ripristina lo stato con docker compose -f <file> down -v; il successivo up reinizializza da zero.
• Le credenziali (xwiki/xwiki, root xwiki-root) sono solo per questo laboratorio locale.
• I due stack usano nomi di progetto Compose diversi, quindi i loro volumi non entrano mai in collisione. Non eseguirli entrambi contemporaneamente, poiché entrambi pubblicano la porta 8080.

6. Verifica tu stesso i checksum ancorati

Attribuzione

xwiki-build/ (Dockerfile, docker-entrypoint.sh, hibernate.cfg.xml, setenv.sh) e mysql/init.sql sono adattati o derivati dal build ufficiale di XWiki, https://github.com/xwiki-contrib/docker-xwiki (LGPL-2.1). Il Dockerfile differisce dall'immagine upstream in tre piccoli modi documentati: (1) la versione e il checksum di XWiki e JDBC sono passati come argomenti di build, così un unico file costruisce sia l'immagine vulnerabile sia quella patchata; (2) un esplicito chmod +x garantisce che l'entrypoint sia eseguibile anche se i permessi Unix vengono persi quando i file vengono decompressi o trasferiti; e (3) un commento upstream obsoleto che faceva riferimento a un file .env (non usato qui) è stato corretto. XWiki è di proprietà del XWiki Development Team.