abraxaslabs.tech  ·  github.com/abraxas  ·  @abraxas_null  ·  [email protected]  ·  vsftpd-cmds-denied-alias

Write-up: https://abraxaslabs.tech/research/vsftpd-cmds-denied-alias

vsftpd-cmds-denied-alias

Classe: Privilegio residuo Portata: Remota

vsftpd 3.0.5 - Chris Evans

Ho fissato il tarball ufficiale, non un mirror GitHub e non un fork della distro. SHA-256 26b602ae454b0ba6d99ef44a09b6b9e0dfa7f67228106736df1f278c70bc91d3. vsftpver.h VSF_VERSION "3.0.5".

cmds_denied è una corrispondenza esatta di token in maiuscolo in process_post_login (postlogin.c:140-184). Il dispatch poi applica in OR gli alias RFC 775 sugli stessi handler: RMD||XRMD (:263-264), anche CWD||XCWD, MKD||XMKD, PASV||P@SW, più EPSV / STOU / APPE separati. Un operatore che mette in denylist RMD (la ricetta comune DELE,RMD) consente comunque a XRMD di eseguire rmdir.

Questo residuo è un problema di integrità FTP autenticato sotto una denylist che l'operatore riteneva chiusa. Non è una vulnerabilità non autenticata, non è root, non è un escape dal chroot e non è RCE.

ID	nessuna CVE al momento
Classe	Privilegio residuo (token esatto cmds_denied)
Portata	Remota (FTP autenticato)
CWE	CWE-863
CVSS	Alto: 7.1 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
Prodotto	vsftpd (Chris Evans)
Affetto	vsftpd 3.0.5 tarball ufficiale
Auth	FTP USER/PASS (lab: anonymous ftp)
Licenza	GNU Affero GPL v3.0
Lab	solo 127.0.0.1:18720

Cosa può fare un attaccante

Chi: un utente FTP autenticato (anonimo o locale) su un daemon in cui l'operatore ha impostato cmds_denied. Il valore predefinito è non impostato. Le ricette per utenti virtuali citate nella man page condividono un uid guest, quindi la DAC Unix non può separarle. La sessione è già l'uid mappato all'interno del solito chroot. cmds_denied era il controllo aggiuntivo che avrebbe dovuto togliere il verbo.

Integrità (dimostrato in laboratorio)

Metodo + sink	Privilegio
XRMD labdir dopo cmds_denied=RMD	handle_rmd -> str_rmdir di una directory che l'uid della sessione può rimuovere con Unix-rmdir. Lab: RMD labdir 550, XRMD labdir 250, CWD labdir 550 (directory rimossa). Un secondo MKD labctrl restituisce ancora 550 su RMD.

Integrità (dedotto dallo stesso controllo a token esatto; non dal laboratorio)

Metodo + sink	Privilegio
XMKD dir dopo cmds_denied=MKD	handle_mkd -> mkdir come l'uid della sessione
XCWD path dopo cmds_denied=CWD	handle_cwd -> chdir. Poi RETR se download_enable
STOU / APPE dopo cmds_denied=STOR	handle_upload_common crea / accoda. Richiede write_enable
EPSV / P@SW dopo cmds_denied=PASV	handle_pasv apre un listener dati che la denylist avrebbe dovuto bloccare

Il laboratorio ha dimostrato solo XRMD dopo RMD. Gli altri alias condividono lo stesso controllo str_equal e lo stesso OR nel dispatch. Non li ho testati.

Ricognizione

Nessuna come residuo di prima classe. cmds_denied non è un nascondimento. XRMD non elenca nomi.

Disponibilità

Non rientra nella barra. Rimuovere una directory è un impatto sull'integrità. Un successivo CWD / RETR di quel nome restituisce 550 come effetto collaterale.

Cosa non concede questo residuo

• cmds_denied non autenticato (il pre-login lo ignora; USER/PASS/QUIT restano nella tabella pre-login)
• Root
• Fuga dalla chroot (allow_writeable_chroot disattivato per default; il lab scrive solo sotto /incoming, quindi il deny resta valido)
• cmds_allowed fail-closed: i verbi non elencati, incluso XRMD, restano 550
• write_enable=NO blocca comunque la famiglia di scrittura (STOR/MKD/RMD/DELE/RNFR/RNTO/SITE/APPE/STOU)
• DAC Unix quando gli utenti non condividono lo stesso uid
• Bypass di maiuscole/minuscole SITE vs site (ftpcmdio.c str_upper)
• cmds_denied=CHMOD non corrisponde mai; blocca chmod con chmod_enable=NO o cmds_denied=SITE

Come l'ho trovato

Ho cercato hide/deny/cmds_denied sulla versione ufficiale 3.0.5. Il controllo è una singola scansione dei token separati da virgola e un str_equal contro il verbo convertito in maiuscolo. Non c'è un secondo controllo dentro handle_rmd. RFC 775 continua a fornire XRMD come RMD. Il consiglio comune è cmds_denied=DELE,RMD. Quella stringa non nomina mai XRMD.

Strada sbagliata: considerare SITE vs site come un bypass. I verbi vengono convertiti in maiuscolo. Lo stesso vale per cmds_allowed: quella lista è fail-closed, quindi gli alias non elencati restano negati.

Lab

cd lab
./run.sh

Loopback 127.0.0.1:18720. Progetto Compose vsftpd-cmds-denied-alias. Tarball ufficiale 3.0.5 in lab/ (SHA-256 sopra). cmds_denied=RMD, write_enable=YES, anonimo, scritture solo sotto /incoming. Witness VSFTPD-CMDS-DENIED-ALIAS-WITNESS. Ultima riga:

SUCCESS vsftpd-cmds-denied-alias rmd=550 xrmd=250 dir-gone=yes VSFTPD-CMDS-DENIED-ALIAS-WITNESS

Correzione

Nega gli alias RFC quando neghi il verbo moderno, oppure abbina gli alias in cmds_denied (XCWD / XMKD / XRMD / XPWD / XCUP / P@SW / EPSV / STOU / APPE). Preferisci cmds_allowed (allowlist).

L'intake del fornitore è [email protected] (vsftpd). Non retribuito. Non aprire una issue pubblica su GitHub su nessun mirror di vsftpd.

Contatto

Abraxas Labs - abraxaslabs.tech - github.com/abraxas - @abraxas_null - [email protected]