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

vsftpd-cmds-denied-alias

Класс: Остаточные привилегии Достижимость: Удалённая

vsftpd 3.0.5 - Chris Evans

Я зафиксировал официальный tarball, а не зеркало на GitHub и не форк дистрибутива. SHA-256 26b602ae454b0ba6d99ef44a09b6b9e0dfa7f67228106736df1f278c70bc91d3. vsftpver.h VSF_VERSION "3.0.5".

cmds_denied — это точное совпадение токена в верхнем регистре в process_post_login (postlogin.c:140-184). Затем диспетчеризация OR-ит алиасы RFC 775 на те же обработчики: RMD||XRMD (:263-264), а также CWD||XCWD, MKD||XMKD, PASV||P@SW, плюс отдельные EPSV / STOU / APPE. Оператор, который вносит RMD в denylist (распространённый рецепт DELE,RMD), всё равно позволяет XRMD удалять каталоги.

Это остаточная проблема целостности аутентифицированного FTP при denylist, который оператор считал закрытым. Это не unauth, не root, не побег из chroot и не RCE.

ID	пока нет CVE
Класс	Остаточные привилегии (точный токен cmds_denied)
Достижимость	Удалённая (аутентифицированный FTP)
CWE	CWE-863
CVSS	High: 7.1 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
Продукт	vsftpd (Chris Evans)
Затронуто	vsftpd 3.0.5 официальный tarball
Аутентификация	FTP USER/PASS (лаборатория: анонимный ftp)
Лицензия	GNU Affero GPL v3.0
Лаборатория	только 127.0.0.1:18720

Что может сделать атакующий

Кто: аутентифицированный FTP-пользователь (анонимный или локальный) на демоне, где оператор задал cmds_denied. По умолчанию не задано. Рецепты для виртуальных пользователей, упомянутые в man-странице, используют общий guest uid, поэтому Unix DAC не может их разделить. Сессия уже работает под сопоставленным uid внутри обычного chroot. cmds_denied был дополнительным контролем, который должен был отнять эту команду.

Целостность (доказано в лаборатории)

Метод + приёмник	Привилегия
XRMD labdir после cmds_denied=RMD	handle_rmd -> str_rmdir каталога, который uid сессии может удалить через Unix-rmdir. Лаборатория: RMD labdir 550, XRMD labdir 250, CWD labdir 550 (каталог исчез). Второй MKD labctrl всё ещё 550 на RMD.

Целостность (выведено из того же точного совпадения токена; не лаборатория)

Метод + приёмник	Привилегия
XMKD dir после cmds_denied=MKD	handle_mkd -> mkdir от имени uid сессии
XCWD path после cmds_denied=CWD	handle_cwd -> chdir. Затем RETR, если download_enable
STOU / APPE после cmds_denied=STOR	handle_upload_common создание / дозапись. Требуется write_enable
EPSV / P@SW после cmds_denied=PASV	handle_pasv открывает слушатель данных, который denylist должен был остановить

Лаборатория доказала только XRMD после RMD. Остальные алиасы используют тот же str_equal-гейт и тот же OR в диспетчеризации. Я их не проверял.

Разведка

Отсутствует как полноценная остаточная проблема. cmds_denied — это не сокрытие. XRMD не выдаёт имена.

Доступность

Не в баре. Удаление каталога — это удар по целостности. Последующий CWD / RETR по этому имени даёт 550 как побочный эффект.

Чего эта остаточная проблема не даёт

• Неаутентифицированный cmds_denied (до логина он игнорируется; USER/PASS/QUIT остаются в таблице предлогина)
• Root
• Побег из chroot (allow_writeable_chroot по умолчанию выключен; лаборатория пишет только под /incoming, поэтому запрет всё ещё действует)
• cmds_allowed fail-closed: не перечисленные команды, включая XRMD, остаются 550
• write_enable=NO всё ещё блокирует семейство записи (STOR/MKD/RMD/DELE/RNFR/RNTO/SITE/APPE/STOU)
• Unix DAC, когда пользователи не используют общий uid
• Обход через регистр SITE vs site (ftpcmdio.c str_upper)
• cmds_denied=CHMOD никогда не совпадает; убивайте chmod через chmod_enable=NO или cmds_denied=SITE

Как я это нашёл

Я искал hide/deny/cmds_denied в официальной 3.0.5. Гейт — это один проход по токенам, разделённым запятыми, и str_equal против команды в верхнем регистре. Внутри handle_rmd нет второй проверки. RFC 775 всё ещё поставляет XRMD как RMD. Обычный совет — cmds_denied=DELE,RMD. Эта строка никогда не называет XRMD.

Неверный путь: считать SITE vs site обходом. Команды приводятся к верхнему регистру. То же самое с cmds_allowed: этот список fail-closed, поэтому алиасы, которые не перечислены, остаются запрещёнными.

Лаборатория

cd lab
./run.sh

Loopback 127.0.0.1:18720. Compose-проект vsftpd-cmds-denied-alias. Официальный tarball 3.0.5 в lab/ (SHA-256 выше). cmds_denied=RMD, write_enable=YES, анонимный, запись только под /incoming. Свидетель VSFTPD-CMDS-DENIED-ALIAS-WITNESS. Последняя строка:

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

Исправление

Запрещайте алиасы RFC при запрете современной команды или сопоставляйте алиасы в cmds_denied (XCWD / XMKD / XRMD / XPWD / XCUP / P@SW / EPSV / STOU / APPE). Предпочитайте cmds_allowed (allowlist).

Приём обращений вендора — [email protected] (vsftpd). Неоплачиваемо. Не открывайте публичный issue на GitHub в любом зеркале vsftpd.

Контакты

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