abraxaslabs.tech  ·  github.com/abraxas  ·  @abraxas_null  ·  [email protected]  ·  vsftpd-deny-file-brace-child

vsftpd-deny-file-brace-child

Classe: Privilégio remanescente Alcance: Remoto

vsftpd 3.0.5 - Chris Evans

O exemplo da página de manual (vsftpd.conf.5) é deny_file={*.mp3,*.mov,.private}. Nomes correspondentes "não devem ser acessíveis de forma alguma", incluindo "download, entrar no diretório, afetar algo dentro do diretório". vsf_access_check_file (access.c:16-43) chama vsf_filename_passes_filter no caminho do cliente como fornecido, depois str_locate_str do tunable de chaves inteiro. O filtro corresponde ao último componente / prefixo; o remanescente /secret falha; a substring de {*.mp3,*.mov,.private} não encontra.

CWD .private é negado (o basename corresponde). RETR .private/secret e RETR dir/.private têm sucesso. Esse "dentro do diretório" é o que este remanescente quebra.

CVE-2015-1419 é um patch público de distro para realpath/basename. O 3.0.5 oficial nunca o adotou. O branch de chaves do Debian ainda corresponde ao caminho completo, então este percurso de filho permanece também em pacotes de distro corrigidos. Não reabra o 2015-1419.

Este remanescente é uma falha de deny-list condicionada por configuração. Não é RCE não autenticado, não é escape de chroot, e não é leitura de /etc do host.

ID	ainda sem CVE
Classe	Privilégio remanescente
Alcance	Remoto (FTP autenticado)
CWE	CWE-863, CWE-22
CVSS	Alto: 7.5 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Produto	vsftpd (Chris Evans)
Afetado	vsftpd 3.0.5 tarball oficial SHA-256 26b602ae454b0ba6d99ef44a09b6b9e0dfa7f67228106736df1f278c70bc91d3
Autenticação	FTP autenticado USER/PASS (anônimo no laboratório). deny_file definido como uma lista de chaves (padrão não definido)
Licença	GNU Affero GPL v3.0
Laboratório	apenas 127.0.0.1. Anônimo somente leitura. Arquivo testemunha.

O que um atacante pode fazer

Quem: um usuário FTP autenticado (anônimo ftp no laboratório). UID da sessão após o drop habitual do vsftpd. deny_file é a política extra que deveria retirar capacidades desse UID. Receitas de usuário virtual que a página de manual nomeia compartilham guest_username, então o DAC do Unix não os separa. O 3.0.5 padrão com tunable_deny_file NULL não é este remanescente.

Confidencialidade (comprovada em laboratório)

Método + sink	Privilégio
RETR .private/secret com a chave documentada deny_file={*.mp3,*.mov,.private}	handle_retr str_open de um arquivo cujo nome de diretório está na deny list, como o uid da sessão. Laboratório: 150/226, 37 bytes, corpo VSFTPD-DENY-FILE-BRACE-CHILD-WITNESS
RETR dir/.private	mesmo sink. Um arquivo chamado .private sob outro diretório (must_match_at_current_pos rejeita uma correspondência no índice > 0). Laboratório: 150/226, corpo DIRDOT-VSFTPD-DENY-FILE-BRACE-CHILD-WITNESS

Integridade (inferida do mesmo gate vsf_access_check_file; o laboratório era somente leitura)

Método + sink	Privilégio
STOR / APPE no mesmo caminho quando write_enable=YES	handle_upload_common cria / sobrescreve como o uid da sessão
DELE / RNTO no mesmo caminho	str_unlink / rename de um nome que a denylist deveria impedir

Recon (inferido)

Método + sink	Privilégio
LIST .private/x (ou LIST dentro da árvore negada)	handle_dir_common verifica o acesso ao argumento completo (não encontra), depois str_opendir do prefixo .private após a divisão pela barra. Apenas nomes. O DAC do Unix ainda se aplica

Negativos comprovados em laboratório (mesma execução)

Método + sink	Resultado
CWD .private	550 Permission denied. O basename .private corresponde à chave
RETR song.mp3	550. *.mp3 é um padrão de último componente e corresponde

O que este remanescente não concede

• Arquivos que o uid da sessão não consegue abrir no Unix
• O próprio CWD .private (o basename corresponde)
• Ocultação de dirent no LIST via hide_file (basename de readdir; RETR de um nome oculto é documentadamente intencional)
• /etc do host a partir de um chroot
• HTTP não autenticado (http_enable desativado por padrão; GET em modo FTP encerra a sessão)
• deny_file=.private sem chaves é salvo pelo fallback de substring (str_locate_str de .private em .private/secret)
• Ignorar login não autenticado, PORT bounce, root, escape de chroot

Como eu encontrei

Fixeio o vsftpd oficial 3.0.5 (SHA-256 26b602ae...c91d3) em vez de um espelho do GitHub ou uma árvore Debian/Fedora. Dezenove buscas no código-fonte. O daemon compilado padrão não tem remanescente Crítico/Alto não publicado. Este exige que o operador copie o exemplo de chaves da página de manual.

vsf_filename_passes_filter (ls.c) corresponde a * / ? / {,} não aninhados e só faz trabalho útil em um padrão de último componente. Para o nome .private/secret contra {*.mp3,*.mov,.private}:

1. As alternativas de chave *.mp3, *.mov, .private são correspondidas no início de .private/secret. O remanescente /secret falha a menos que o token fosse *.
2. O fallback de substring procura pelo literal {*.mp3,*.mov,.private} e não encontra.

Caminho errado já público: CVE-2015-1419 é realpath apenas de distro. O Changelog oficial não tem tal correção. Até o branch de chaves do Debian copia o caminho normalizado completo, então os filhos ainda percorrem.

Laboratório

cd lab
./run.sh

Controle em loopback 127.0.0.1:18710, PASV 18711-18718. Projeto Compose vsftpd-deny-file-brace-child. Tarball oficial 3.0.5, anônimo somente leitura, deny_file={*.mp3,*.mov,.private}. Testemunha VSFTPD-DENY-FILE-BRACE-CHILD-WITNESS. Última linha:

SUCCESS vsftpd-deny-file-brace-child cwd-dotprivate=550 retr-child=yes retr-dir-dotprivate=yes mp3=550 VSFTPD-DENY-FILE-BRACE-CHILD-WITNESS

Correção

Corresponda as alternativas de chave contra cada componente do caminho, ou realpath / basename antes do filtro (com as ressalvas habituais de symlink). O exemplo documentado deveria de fato negar os filhos.

O canal de recebimento do fornecedor é [email protected] (vsftpd). Não abra uma issue pública no GitHub em nenhum espelho do vsftpd.

Contato

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