CVE-2010-3904

Falha de validação de ponteiros no subsistema RDS (Reliable Datagram Sockets) do kernel Linux permite que um usuário local sem privilégios escale para root através de chamadas sendmsg/recvmsg manipuladas. O CVSS de 7.8 é justificado, mas a exploração prática depende de o atacante conseguir vazar um endereço de memória do kernel (kallsyms/System.map) e de o sistema não ter confinamento SELinux ativo — condições que reduzem bastante o alcance real da falha em produção hoje, mesmo estando ela no catálogo KEV da CISA por exploração histórica confirmada.

A função rds_page_copy_user, em net/rds/page.c, foi introduzida no commit 7875e18e (v2.6.30-rc1) para copiar dados de/para buffers de usuário durante operações de socket RDS. O problema é que ela chama diretamente __copy_to_user_inatomic() e __copy_from_user_inatomic() sem antes validar, via access_ok() ou verificação de faixa de endereço, que o ponteiro fornecido pelo usuário (o endereço base de um iovec passado em sendmsg/recvmsg) realmente pertence ao espaço de endereçamento de usuário. Isso é uma falha clássica de validação de entrada (a Red Hat descreve como ausência de checagem de acesso; o NVD/CISA classificam como CWE-20, Improper Input Validation).

Como o kernel confia no endereço fornecido, um atacante local pode montar um struct iovec cujo campo base apunte para um endereço de memória do kernel, em vez de um buffer de usuário legítimo. Dependendo da direção da operação (sendmsg copia dados do usuário para o kernel; recvmsg copia do kernel para o usuário), isso se traduz em leitura ou escrita arbitrária de memória do kernel a partir de um processo sem privilégios.

O vetor de escalonamento típico é sobrescrever uma estrutura de credenciais do processo (struct cred) ou um ponteiro de função no espaço do kernel, elevando o UID do processo atacante para 0. Para isso o atacante precisa conhecer o endereço-alvo, o que normalmente exige leitura de /proc/kallsyms ou /boot/System.map — arquivos que, em configurações restritivas, não são acessíveis a usuários comuns.

O pré-requisito mínimo é acesso local a um shell sem privilégios elevados e a capacidade de abrir um socket AF_RDS (família de protocolo 21) via socket(2) — isso não exige capacidade especial além da criação normal de sockets. O atacante então monta chamadas sendmsg/recvmsg com um iovec cujo endereço base é um ponteiro de kernel previamente descoberto, geralmente lendo símbolos do kernel expostos por /proc/kallsyms ou por um mapa de símbolos (System.map) legível.

Red Hat documentou que a exploração é bloqueada na prática pela maioria dos domínios confinados por SELinux (incluindo staff_t e user_t), porque esses perfis normalmente não concedem acesso de leitura ao mapa de símbolos nem permissão "create" em sockets AF_RDS. Isso significa que sistemas com SELinux enforcing e políticas padrão de distribuição têm risco efetivo bem menor do que a nota indica isoladamente.

A falha foi divulgada publicamente por Dan Rosenberg (Virtual Security Research) em 19/10/2010, com PoC e módulo Metasploit disponíveis desde então, o que a tornou trivial de operacionalizar assim que as condições (RDS carregado, kallsyms legível, sem confinamento efetivo) estivessem presentes. A CISA incluiu a CVE no catálogo KEV em maio de 2023 confirmando exploração no mundo real, mas como o kernel afetado é de 2010-2011 e está fora de suporte há anos, a orientação da própria CISA é desconectar/substituir qualquer sistema que ainda rode essas versões, não apenas aplicar patch.

A correção definitiva é atualizar para kernel 2.6.36 ou posterior, onde o commit upstream 799c10559d60f159ab2232203f222f18fa3c4a5f adiciona a validação de endereço ausente. Distribuições empacotaram backports específicos: Red Hat Enterprise Linux 5 via RHSA-2010:0792 e RHEL 6 via RHSA-2010:0842; openSUSE publicou avisos equivalentes em outubro/2010, novembro/2010 e fevereiro/2011 para seus respectivos kernels.

Se a atualização não for possível de imediato, o paliativo real e documentado pelo fornecedor é impedir o carregamento do módulo RDS: adicionar 'blacklist rds' em /etc/modprobe.d/blacklist (ou 'alias net-pf-21 off' em um arquivo de modprobe.d), garantindo depois que o módulo não esteja já carregado (lsmod | grep rds). Como reforço, remover CAP_SYS_MODULE do conjunto de capacidades global (via /proc/sys/kernel/cap-bound) impede que o módulo seja carregado sob demanda por um usuário local. Nenhuma dessas medidas corrige a falha de validação em si — apenas eliminam a superfície de ataque enquanto o RDS não for necessário.

Restringir a leitura de /proc/kallsyms (kptr_restrict=2) e manter SELinux/AppArmor enforcing com políticas que neguem criação de sockets AF_RDS a usuários não confiáveis reduz a probabilidade de exploração bem-sucedida, mas não é mitigação garantida — é redução de superfície, não correção de root cause. Como o CVE afeta apenas versões de kernel de 2010-2011, hoje o cenário mais provável não é patch pendente e sim sistema legado fora de suporte; nesse caso, a única ação recomendada pela CISA é desconectar ou substituir o sistema.

Não há assinatura de rede confiável, pois a exploração é inteiramente local — não trafega em interface de rede monitorável por IDS/NIDS convencional. Em nível de host, os sinais úteis são: criação de sockets da família AF_RDS (protocolo 21) por processos não privilegiados (rastreável via auditd com regra em socket(2) e filtro de família de protocolo), leitura de /proc/kallsyms ou /boot/System.map por usuários comuns, carregamento inesperado do módulo rds.ko (lsmod | grep rds) em hosts onde RDS não é usado por aplicações legítimas, e elevação súbita de UID/GID em processos que antes rodavam sem privilégios — sinal característico de exploração de escalonamento via corrupção de struct cred.