CVE-2017-7494

Falha de execução remota de código no Samba que permite a um cliente com permissão de escrita em um compartilhamento fazer o processo smbd carregar e executar uma biblioteca compartilhada (.so) arbitrária, geralmente com privilégios de root. Ficou conhecida como "SambaCry" por seu paralelo com o EternalBlue explorado pelo WannaCry, e afetou praticamente qualquer servidor Samba com um share gravável exposto — incluindo um número grande de NAS domésticos e corporativos que nunca recebem patch.

O smbd expõe pipes nomeados internos (a interface que implementa chamadas RPC sobre SMB). Um dos parâmetros dessa interface é usado para localizar e carregar, via dlopen(), um módulo compartilhado do próprio Samba. O problema é que o Samba não sanitizava adequadamente o caminho fornecido nesse parâmetro: um cliente podia enviar, através de uma requisição de pipe, um caminho arbitrário no sistema de arquivos do servidor, incluindo um caminho dentro de um compartilhamento SMB no qual ele mesmo tivesse acabado de escrever um arquivo.

O fluxo de ataque é conceitualmente simples: o cliente grava um arquivo de biblioteca compartilhada (.so) em qualquer compartilhamento onde tenha permissão de escrita, e então, através de uma chamada RPC específica, instrui o smbd a tratar aquele arquivo como um módulo interno e carregá-lo. Como o smbd normalmente roda como root (ou com privilégios elevados em várias distribuições e appliances), o código dentro da .so é executado com esses privilégios no momento do dlopen().

Classifica-se como CWE-427 (Uncontrolled Search Path Element) / neutralização insuficiente de entrada usada em caminho de carregamento de módulo. A causa raiz está na ausência de restrição do caminho a diretórios de módulos confiáveis do próprio Samba — o servidor confiava implicitamente no valor fornecido pelo cliente via protocolo.

A falha existe desde a versão 3.5.0, o que significa mais de sete anos de código exposto antes da correção pública em maio de 2017.

O pré-requisito real é acesso de escrita a algum compartilhamento SMB do servidor vulnerável. A Red Hat descreve o cenário como "cliente autenticado com acesso de escrita ao share", mas a exploração prática que tornou o CVE tão impactante independe de credenciais fortes: em muitas instalações — sobretudo dispositivos NAS e appliances com Samba embarcado — existem shares com acesso de convidado (guest) gravável, o que reduz o pré-requisito a simplesmente alcançar a porta SMB (445/139) na rede, sem senha alguma. Isso explica por que dispositivos de borda e storage doméstico foram os mais afetados na exploração em massa observada em 2017.

O ataque não exige interação do usuário nem bypass de autenticação — é uma cadeia de duas etapas (upload do arquivo + chamada RPC que aponta para ele), sem necessidade de heap grooming, bypass de ASLR ou técnicas de exploração de memória. Isso o torna trivial de automatizar, e de fato módulos Metasploit e PoCs públicas circularam dias após a divulgação.

A vulnerabilidade está no catálogo KEV da CISA como exploração confirmada, e o EPSS próximo de 1.0 reflete que praticamente qualquer scanner de internet ainda testa esse vetor. O resultado final da exploração é execução de código arbitrário no contexto do processo smbd, tipicamente root em sistemas Linux/Unix, o que equivale a comprometimento total do host.

A correção definitiva é atualizar para Samba 4.6.4, 4.5.10 ou 4.4.14 (ou versões de branches mais novos que os incorporam), dependendo do ramo em uso. Distribuições enterprise publicaram backports próprios (RHEL 5/6/7 via samba3x, samba4 e samba, conforme RHSA-2017:1270/1271/1272/1273/1390); usar o pacote da distro corrigido resolve sem precisar compilar upstream.

Quando a atualização não é viável de imediato, o paliativo reconhecido pelo próprio projeto Samba é adicionar `nt pipe support = no` à seção [global] do smb.conf e reiniciar o smbd — isso desativa o suporte a alguns pipes nomeados usados por clientes Windows para funções administrativas remotas, então quebra funcionalidades como alteração remota de senha via ferramentas administrativas Windows. É mitigação real, não cosmética, mas tem custo funcional que precisa ser avaliado. Outra camada eficaz e de baixo custo é garantir que nenhum compartilhamento aceite escrita anônima/guest e restringir acesso à porta 445/139 por firewall a hosts que realmente precisam de SMB.

O que não funciona como mitigação: apenas restringir permissões de leitura no share não resolve, porque o vetor depende de escrita, não de leitura — o controle tem que estar na permissão de escrita e no acesso de rede. Desabilitar SMBv1 também não mitiga essa falha, já que o problema está na camada de RPC sobre pipes nomeados, não na versão do protocolo SMB.

Em logs do smbd, procurar por conexões que gravam arquivos com extensão .so (ou nomes disfarçados) em compartilhamentos, seguidas por requisições de pipe nomeado incomuns apontando para o caminho desse arquivo — essa sequência escrita-seguida-de-chamada-RPC-para-o-mesmo-caminho é o padrão característico do ataque. Ferramentas de detecção de rede podem sinalizar tráfego SMB com nomes de pipe fora do conjunto padrão do Windows/Samba.

Não há assinatura de payload única confiável, porque a exploração é uma chamada de protocolo legítima usada de forma abusiva — qualquer detecção depende de correlacionar a escrita do arquivo com a chamada RPC subsequente, não de inspecionar conteúdo malicioso óbvio. Hosts sem atualização e com histórico de exposição da porta 445 à internet devem ser tratados como potencialmente comprometidos, dado o volume de exploração automatizada registrada desde 2017.