CVE-2010-1871

Falha de sanitização de entrada no JBoss Seam 2 (framework de aplicação Java), presente no jboss-seam2 como distribuído no JBoss Enterprise Application Platform 4.3.0 para Red Hat Linux. Um parâmetro de URL malicioso é interpretado como uma expressão JBoss EL (Expression Language) e processado pelo servidor sem validação, permitindo execução remota de código. A falha só é explorável quando o Java Security Manager não está corretamente configurado — uma condição que, segundo o próprio Red Hat, é comum em ambientes reais, o que explica por que está no catálogo KEV da CISA mais de dez anos depois da publicação.

O Seam expõe determinados parâmetros HTTP que são resolvidos via JBoss Unified Expression Language (EL) — o mecanismo usado internamente pelo framework para navegação entre páginas e binding de dados. O bug é uma falha de sanitização de entrada (o CVE não é atribuído oficialmente a um CWE pelo NVD legado; a CISA classifica como CWE-20, Improper Input Validation; a natureza do problema é consistente com injeção de EL/CWE-917): o valor do parâmetro, controlado inteiramente pelo atacante via query string, chega ao avaliador de EL sem que caracteres ou construções de expressão sejam filtrados antes do processamento.

Como o avaliador de EL do Seam permite invocação de métodos Java e resolução de propriedades em tempo de execução, uma expressão parametrizada e forjada dentro da URL pode acionar chamadas arbitrárias — na prática, execução de código no contexto do processo da aplicação. O relatório original (Meder Kydyraliev, Google Security Team, via Red Hat Bugzilla) descreve isso como 'execute arbitrary code via a URL, containing appended, specially-crafted expression language parameters'.

A correção descrita pelos mantenedores foi ajustar a forma como a expressão EL é sanitizada antes de o servidor processá-la, e não uma reescrita do motor de EL em si — ou seja, o vetor de entrada foi filtrado, não o poder de execução do EL removido.

Um detalhe pouco divulgado: a versão do Seam empacotada no JBEAP 4.2 não foi afetada; o problema é específico da versão empacotada a partir do JBEAP 4.3.0, segundo confirmação da equipe de segurança do Red Hat na thread do bug.

O vetor é uma requisição HTTP simples e não autenticada: o atacante anexa à URL um parâmetro cujo valor contém uma expressão EL forjada, direcionado a uma aplicação Java construída sobre o JBoss Seam 2 e hospedada em JBEAP 4.3.0. Não é necessária autenticação prévia (PR:N no CVSS), nem interação além de o servidor processar a requisição — embora o vetor CVSS marque UI:R, o que sugere alguma forma de indução (por exemplo, convencer a vítima a acessar um link) em certos cenários de exploração refletida.

O pré-requisito decisivo, e que a manchete do CVE já adianta mas que costuma ser ignorado, é a configuração do Java Security Manager: se ele estiver ausente ou mal configurado (cenário comum, já que habilitá-lo corretamente exige políticas de segurança específicas e nem sempre é padrão em deploys de produção), a expressão EL maliciosa tem liberdade para invocar classes e métodos Java sem restrição de sandbox, viabilizando execução arbitrária de código no contexto do processo do servidor de aplicação.

Existe módulo Metasploit público e PoC divulgada, o que reduz a complexidade prática de exploração a praticamente copiar/colar contra um alvo vulnerável identificado. A presença no catálogo KEV da CISA (adicionada em 2021-12-10, apesar da publicação original em 2010) confirma exploração ativa observada muito depois da divulgação original — reflexo de quão longeva é a base de instalações legadas de JBEAP/Seam ainda expostas e sem Security Manager configurado.

A correção primária é aplicar a atualização do fornecedor: para JBoss EAP 4.3.0 em RHEL 4 e RHEL 5, o pacote corrigido foi distribuído via RHSA-2010:0564. No lado do projeto upstream, o Seam corrigiu o problema na sanitização da expressão EL a partir da versão 2.2.1.CR2 (anunciada pela comunidade Seam em setembro de 2010).

Se a atualização não for viável no curto prazo, o próprio fornecedor aponta o controle compensatório real: configurar e habilitar corretamente o Java Security Manager. Segundo o Red Hat, isso impede a exploração mesmo em versões vulneráveis, pois restringe o que o código invocado via EL pode fazer no sistema. Não há, nas fontes oficiais, indicação de que desabilitar funcionalidades específicas do Seam ou aplicar apenas regras de WAF genéricas seja suficiente — expressões EL maliciosas podem ser codificadas de várias formas, e um filtro de padrão de string é frágil contra variações de sintaxe EL.

Vale notar que a simples presença de uma versão 'não vulnerável' do JBEAP (4.2, por exemplo) não garante segurança se a aplicação usa uma versão standalone do Seam vulnerável — o escopo oficial do CVE é o pacote jboss-seam2 como usado no JBEAP 4.3.0, mas o mecanismo de fundo (sanitização de EL) é relevante para qualquer deploy Seam 2.x anterior à correção upstream.

Procure em logs de acesso web por requisições com parâmetros de URL contendo sintaxe de expressão EL (padrões como '#{' ou '${') anexados a nomes de parâmetro não usuais, direcionadas a aplicações baseadas em JBoss Seam. Assinaturas de IDS/WAF para o módulo Metasploit associado a este CVE ('jboss_seam_exploit') também são um indicador direto de tentativa. Como não há um campo ou endpoint fixo documentado publicamente pelas fontes oficiais, um sinal indireto mais confiável em ambientes comprometidos é a criação anômala de processos filho (shell, comandos de sistema) a partir do processo Java do servidor de aplicação — comportamento característico de execução de código bem-sucedida via EL.