Falha em validação de caminhos no Windows permitiu contornar correção do RDP

O problema envolveu o uso de PathCchCanonicalize para bloquear travessia de diretórios, mas a função não tratava separadores com barra normal da mesma forma que as APIs de arquivo do Windows.

Componente	Clientes RDP da Microsoft, validação de caminhos baseada em PathCchCanonicalize, mstscax.dll e fluxos de área de transferência com FileGroupDescriptorW.
Vetor	Servidor RDP malicioso podia enviar nomes de arquivo manipulados no canal de área de transferência; a substituição de separadores de caminho por barra normal permitia escapar da validação criada para CVE-2019-0887.
Impacto	Travessia de diretórios com escrita fora da pasta prevista no cliente RDP e, no cenário anterior associado a CVE-2019-0887, risco de escape de convidado para host no Hyper-V Manager.
Prioridade	Aplicar a correção da Microsoft para CVE-2020-0655 e revisar aplicações próprias que dependem de PathCchCanonicalize como controle único contra travessia de diretórios.
Versões e artefatos	A correção analisada alterou lógica no cliente RDP, especialmente em mstscax.dll; KernelBase.dll, onde fica PathCchCanonicalize, não foi atualizado naquele ciclo.
Limite confirmado	O cliente RDP da Microsoft para macOS foi avaliado no fluxo descrito e não foi considerado vulnerável a CVE-2019-0887.

Resumo técnico

A pesquisa descreve uma falha de validação de caminhos que surgiu durante a reavaliação do ataque conhecido como Reverse RDP. O ponto central é a correção de CVE-2019-0887, uma vulnerabilidade de travessia de diretórios explorável por meio de dados recebidos pelo cliente RDP. A correção original adicionou uma checagem de normalização sobre nomes de arquivo contidos no formato de área de transferência FileGroupDescriptorW. A expectativa era simples: se o caminho recebido mudasse após a canonicalização, a entrada seria rejeitada como tentativa de escapar da pasta permitida. O problema é que a função usada para essa decisão, PathCchCanonicalize, tratava apenas separadores com barra invertida em sua lógica de divisão do caminho, enquanto as APIs comuns de arquivo do Windows aceitam tanto barra invertida quanto barra normal em operações de leitura, escrita, criação e remoção.

Esse descompasso entre a lógica de validação e a lógica de uso real do sistema de arquivos criou um bypass direto. Um caminho que seria barrado quando escrito com separadores tradicionais do Windows podia passar pela validação quando os mesmos níveis de diretório eram representados com barra normal. Depois disso, ao chegar às rotinas de arquivo do Windows, o caminho ainda seria interpretado como um caminho válido. A consequência não é um vazamento genérico de dados, mas um problema específico de controle de destino de escrita: software que acredita ter restringido um arquivo a uma pasta predefinida pode aceitar uma entrada que aponta para fora desse limite.

A Microsoft emitiu CVE-2020-0655 para tratar o cenário de bypass no RDP, mas a análise mostrou que a alteração observada estava no fluxo do cliente RDP, não na função de canonicalização hospedada em KernelBase.dll. Isso é relevante para engenharia defensiva porque o risco não se limita ao RDP quando outros projetos usam a mesma função como mecanismo principal de sanitização. O caso demonstra uma classe recorrente de falha: a validação tenta modelar a semântica de caminhos, mas não replica exatamente a interpretação feita pela camada que executa a ação protegida. Quando essas duas interpretações divergem, a proteção pode parecer correta em testes comuns e ainda assim falhar em entradas equivalentes aceitas pelo sistema operacional.

Fluxo técnico

O fluxo original de ataque em RDP parte de uma relação invertida de confiança. Em uma conexão remota tradicional, o operador do cliente confia que o servidor RDP é o ambiente remoto a ser acessado. No Reverse RDP, o servidor pode devolver conteúdo pela área de transferência ou por outros canais do protocolo e influenciar como o cliente local processa arquivos. No caso analisado, o campo de interesse era o conjunto de descritores de arquivos em FileGroupDescriptorW. Se o cliente aceita um nome de arquivo vindo do servidor e o grava em um local local sem validar corretamente o caminho, o servidor consegue tentar induzir escrita fora da pasta esperada.

A correção de CVE-2019-0887 adicionou uma etapa de canonicalização. A lógica comparava o caminho original com a forma normalizada calculada por PathCchCanonicalize. Em entradas com componentes como diretório atual ou diretório pai representados com separadores de barra invertida, a função produzia uma forma diferente e isso permitia bloquear a tentativa. No entanto, quando a mesma estrutura de travessia era escrita com barra normal, a função não reduzia corretamente os componentes, porque sua implementação separava partes do caminho procurando apenas a barra invertida. Assim, a entrada podia permanecer aparentemente equivalente ao original na validação, embora continuasse sendo interpretada como caminho traversável por chamadas posteriores do Windows.

A descoberta ocorreu durante testes que inicialmente buscavam verificar o cliente RDP da Microsoft para macOS. O cliente macOS acabou não sendo caracterizado como vulnerável a CVE-2019-0887, mas a preparação do ambiente levou à troca de separadores no teste. Essa mudança revelou que o cliente Windows corrigido ainda podia ser afetado pelo bypass. A análise posterior isolou o comportamento em um programa simples voltado apenas para PathCchCanonicalize e confirmou que a função não tratava barra normal como separador equivalente durante a canonicalização. A revisão de binários também indicou que a atualização para CVE-2020-0655 aplicou um contorno no cliente RDP, substituindo separadores antes da validação, em vez de corrigir a função de propósito geral no núcleo das APIs de caminho usadas por desenvolvedores.

O impacto técnico deve ser delimitado com precisão. A falha não prova, por si só, execução remota de código em qualquer aplicação que use PathCchCanonicalize. O que ela sustenta é bypass de uma checagem de travessia de diretórios quando a aplicação confia nessa função para garantir que uma escrita, criação ou acesso permaneça dentro de uma raiz controlada. Se a aplicação depois passa o caminho para APIs como CreateFile, DeleteFile ou criação de pastas, a interpretação com barra normal pode ser aceita e a proteção fica incompleta. Em RDP, esse erro era perigoso porque a entrada vinha de um servidor remoto não confiável e era processada no cliente. Em outros produtos, a gravidade depende de quem controla o nome do arquivo, qual operação é executada e quais permissões o processo possui.

Superfície afetada

A superfície diretamente discutida envolve clientes RDP da Microsoft e o tratamento de nomes de arquivo recebidos via área de transferência. A correção anterior de CVE-2019-0887 tinha relação com o cliente RDP do Windows e também com um cenário de escape de máquina virtual envolvendo Hyper-V Manager. A nova análise mostrou que o contorno aplicado para CVE-2020-0655 alterou a validação no componente RDP, mas não removeu o comportamento arriscado de PathCchCanonicalize como API geral de canonicalização de caminhos. Isso amplia a preocupação para softwares em C ou C++ no Windows que adotaram a recomendação de usar essa função para bloquear travessia de diretórios.

Aplicações expostas são aquelas que recebem caminhos de origem não confiável, normalizam o valor com PathCchCanonicalize, comparam a saída com a entrada ou verificam prefixos de diretório, e depois executam operações de arquivo assumindo que a entrada está confinada. Esse padrão pode aparecer em clientes que importam arquivos, agentes que recebem tarefas remotas, serviços que extraem anexos, módulos que aceitam nomes vindos de rede, componentes de virtualização, ferramentas de sincronização e qualquer recurso que grave conteúdo localmente com nome controlável por outra parte. O risco aumenta quando o processo roda com privilégios mais altos que o usuário que fornece a entrada ou quando a pasta de destino fica próxima de locais usados para carregamento automático, configuração ou execução posterior.

• Clientes RDP Windows que processavam descritores de arquivo antes da correção associada a CVE-2020-0655.
• Código que usa PathCchCanonicalize como barreira principal contra componentes de diretório pai em entradas não confiáveis.
• Fluxos que aceitam nomes de arquivo de rede, área de transferência, importação, sincronização ou automação remota.
• Aplicações que validam com uma semântica de caminho e executam a operação com APIs do Windows que aceitam barra normal e barra invertida.

Hunting e telemetria

A detecção deve partir do comportamento, não de uma sequência única de caracteres. Em ambientes Windows, equipes de defesa devem procurar operações de escrita, criação ou substituição de arquivo em que o nome lógico recebido por uma aplicação contenha padrões de travessia ou separadores incomuns para aquele fluxo. Para RDP, a telemetria relevante inclui sessões iniciadas contra servidores não confiáveis, uso de redirecionamento de área de transferência, criação de arquivos inesperados no host cliente durante ou logo após a conexão e falhas ou bloqueios no processo de exploração de arquivos associados a tentativas barradas. O objetivo é identificar escrita fora do diretório temporário ou da pasta de download esperada para objetos transferidos pelo canal de área de transferência.

Em engenharia de produto, hunting também significa auditoria de código. Projetos Windows devem localizar chamadas a PathCchCanonicalize, PathCchCanonicalizeEx ou funções equivalentes usadas para reduzir caminhos antes de operações de arquivo. A revisão deve verificar se a aplicação transforma separadores antes da normalização, se resolve o caminho final com uma API que reflita a mesma semântica do sistema de arquivos e se compara o destino final contra a raiz permitida depois de resolver componentes especiais. Comparações textuais simples, principalmente antes da abertura do arquivo, são frágeis quando o sistema aceita representações diferentes para o mesmo caminho.

Na telemetria de endpoint, sinais úteis incluem gravações em diretórios fora do esperado por processos de cliente remoto, criação de arquivos com nomes derivados de objetos transferidos, eventos de acesso a arquivos próximos de uma sessão RDP e discrepâncias entre o diretório declarado pela aplicação e o diretório real observado no evento do sistema. Em logs de desenvolvimento e testes de segurança, casos que passam com barra invertida e falham em cobrir barra normal são um indicador de suíte incompleta. Para times de AppSec, testes de regressão devem incluir equivalências de separador, componentes de diretório pai, diretório atual, caminhos relativos e destinos que tentem ultrapassar a raiz autorizada, sempre sem transformar o teste em PoC operacional de ataque.

• Criação de arquivo fora da pasta esperada por processos ligados a RDP, importação ou transferência de arquivos.
• Entradas de caminho contendo componentes de diretório pai com separadores diferentes dos usados normalmente pela aplicação.
• Uso de PathCchCanonicalize em código que recebe caminho controlado por usuário, servidor remoto ou arquivo importado.
• Diferença entre caminho validado em log de aplicação e caminho efetivamente acessado em eventos do sistema de arquivos.
• Sessões RDP contra servidores não confiáveis acompanhadas de redirecionamento de área de transferência e atividade de escrita local incomum.

Mitigação

A mitigação imediata para o cenário RDP é aplicar as atualizações da Microsoft que tratam CVE-2020-0655, pois o contorno descrito ajusta o processamento no cliente RDP afetado. Em paralelo, organizações devem limitar o uso de redirecionamento de área de transferência e transferência de arquivos em conexões RDP para servidores não administrados ou de confiança desconhecida. Essa redução de superfície é especialmente importante para estáções de administração, hosts usados por operadores privilegiados e ambientes de virtualização, onde a escrita local indevida pode ter consequência operacional maior.

Para desenvolvimento seguro no Windows, a recomendação principal é não tratar PathCchCanonicalize como garantia única de confinamento de caminho quando a entrada é não confiável. O código deve normalizar separadores de forma explícita, resolver o caminho final dentro de uma raiz controlada e validar o destino após a resolução. A comparação deve considerar a semântica do sistema de arquivos que executará a operação, não apenas a forma textual recebida. Também é necessário bloquear caminhos absolutos quando o fluxo espera caminhos relativos, rejeitar componentes de diretório pai quando não forem necessários e validar o resultado com testes para múltiplas representações equivalentes.

Times de segurança devem transformar essa falha em item de revisão para bibliotecas internas, SDKs e utilitários de manipulação de arquivos. Se uma organização possui uma função central para validar destinos de escrita, ela deve ser corrigida uma vez e reaproveitada, em vez de manter variações locais inconsistentes. Depois da correção, convém revisar chamadas sensíveis, executar testes de regressão com separadores alternativos e confirmar por telemetria que a aplicação não grava fora da pasta permitida. Para softwares já distribuídos, a comunicação técnica deve informar que o risco está ligado a travessia de diretórios por representação alternativa de separador, sem prometer impactos não demonstrados, como roubo de dados ou execução remota automática.

• Instalar a atualização da Microsoft associada a CVE-2020-0655 nos sistemas que usam clientes RDP afetados.
• Restringir redirecionamento de área de transferência e transferência de arquivos em conexões RDP com servidores não confiáveis.
• Auditar usos de PathCchCanonicalize em validações de caminho feitas antes de operações de arquivo.
• Normalizar separadores, resolver o destino final e validar que ele permanece dentro da raiz autorizada.
• Adicionar testes de regressão para barra normal, barra invertida, componentes de diretório atual e diretório pai em caminhos não confiáveis.