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 : Privilège résiduel Portée : Distante

vsftpd 3.0.5 - Chris Evans

J'ai épinglé l'archive officielle, pas un miroir GitHub ni un fork de distribution. SHA-256 26b602ae454b0ba6d99ef44a09b6b9e0dfa7f67228106736df1f278c70bc91d3. vsftpver.h VSF_VERSION "3.0.5".

cmds_denied est une correspondance exacte de jeton en majuscules dans process_post_login (postlogin.c:140-184). La répartition combine ensuite les alias RFC 775 sur les mêmes gestionnaires : RMD||XRMD (:263-264), ainsi que CWD||XCWD, MKD||XMKD, PASV||P@SW, plus EPSV / STOU / APPE séparés. Un opérateur qui met RMD sur liste de refus (la recette courante DELE,RMD) laisse toujours XRMD faire un rmdir.

Ce résidu est une atteinte à l'intégrité FTP authentifiée sous une liste de refus que l'opérateur croyait fermée. Ce n'est pas du non-authentifié, pas du root, pas une évasion de chroot, et pas du RCE.

ID	pas encore de CVE
Classe	Privilège résiduel (cmds_denied jeton exact)
Portée	Distante (FTP authentifié)
CWE	CWE-863
CVSS	Élevé : 7.1 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
Produit	vsftpd (Chris Evans)
Affecté	vsftpd 3.0.5 archive officielle
Auth	FTP USER/PASS (labo : anonyme ftp)
Licence	GNU Affero GPL v3.0
Labo	127.0.0.1:18720 uniquement

Ce qu'un attaquant peut faire

Qui : un utilisateur FTP authentifié (anonyme ou local) sur un démon où l'opérateur a défini cmds_denied. Par défaut, non défini. Les recettes d'utilisateurs virtuels citées dans la page de manuel partagent un uid invité, donc le DAC Unix ne peut pas les séparer. La session est déjà l'uid mappé à l'intérieur du chroot habituel. cmds_denied était le contrôle supplémentaire censé retirer le verbe.

Intégrité (prouvé en labo)

Méthode + cible	Privilège
XRMD labdir après cmds_denied=RMD	handle_rmd -> str_rmdir d'un répertoire que l'uid de session peut supprimer via Unix-rmdir. Labo : RMD labdir 550, XRMD labdir 250, CWD labdir 550 (répertoire disparu). Second MKD labctrl toujours 550 sur RMD.

Intégrité (déduit du même filtre à jeton exact ; pas le labo)

Méthode + cible	Privilège
XMKD dir après cmds_denied=MKD	handle_mkd -> mkdir en tant qu'uid de session
XCWD path après cmds_denied=CWD	handle_cwd -> chdir. Puis RETR si download_enable
STOU / APPE après cmds_denied=STOR	handle_upload_common création / ajout. Nécessite write_enable
EPSV / P@SW après cmds_denied=PASV	handle_pasv ouvre un écouteur de données que la liste de refus était censée bloquer

Le labo n'a prouvé que XRMD après RMD. Les autres alias partagent le même filtre str_equal et le même OR dans la répartition. Je ne les ai pas exercés.

Reconnaissance

Aucune en tant que résidu de premier ordre. cmds_denied n'est pas un masquage. XRMD ne liste pas les noms.

Disponibilité

Hors périmètre. La suppression d'un répertoire est une atteinte à l'intégrité. Un CWD / RETR ultérieur de ce nom renvoie 550 en effet de bord.

Ce que ce résidu n'accorde pas

• cmds_denied non authentifié (le pré-login l'ignore ; USER/PASS/QUIT restent la table de pré-login)
• Root
• Évasion de chroot (allow_writeable_chroot désactivé par défaut ; le lab n'écrit que sous /incoming, donc le refus tient toujours)
• cmds_allowed en fail-closed : les verbes non listés, y compris XRMD, restent en 550
• write_enable=NO bloque toujours la famille d'écriture (STOR/MKD/RMD/DELE/RNFR/RNTO/SITE/APPE/STOU)
• DAC Unix lorsque les utilisateurs ne partagent pas le même uid
• Contournement de casse SITE vs site (ftpcmdio.c str_upper)
• cmds_denied=CHMOD ne correspond jamais ; neutraliser chmod avec chmod_enable=NO ou cmds_denied=SITE

Comment je l'ai trouvé

J'ai cherché hide/deny/cmds_denied sur la version officielle 3.0.5. Le contrôle est un seul parcours de jetons séparés par des virgules et un str_equal contre le verbe mis en majuscules. Il n'y a pas de second contrôle dans handle_rmd. La RFC 775 livre toujours XRMD comme RMD. Le conseil courant est cmds_denied=DELE,RMD. Cette chaîne ne nomme jamais XRMD.

Fausse piste : considérer SITE vs site comme un contournement. Les verbes sont mis en majuscules. Il en va de même pour cmds_allowed : cette liste est en fail-closed, donc les alias qui n'y figurent pas restent refusés.

Lab

cd lab
./run.sh

Loopback 127.0.0.1:18720. Projet Compose vsftpd-cmds-denied-alias. Tarball officiel 3.0.5 dans lab/ (SHA-256 ci-dessus). cmds_denied=RMD, write_enable=YES, anonyme, écritures uniquement sous /incoming. Témoin VSFTPD-CMDS-DENIED-ALIAS-WITNESS. Dernière ligne :

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

Correction

Refusez les alias RFC lorsque vous refusez le verbe moderne, ou faites correspondre les alias dans cmds_denied (XCWD / XMKD / XRMD / XPWD / XCUP / P@SW / EPSV / STOU / APPE). Préférez cmds_allowed (liste d'autorisation).

La réception des signalements par le fournisseur se fait à [email protected] (vsftpd). Non rémunéré. N'ouvrez pas de ticket GitHub public sur un miroir de vsftpd.

Contact

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