CVE-2014-0196
Priorize a correção. Ela está sob exploração confirmada pelo CISA e tem prova de conceito pública.
The impacted product is end-of-life and should be disconnected if still in use.
Resumo
Race condition no line discipline N_TTY do kernel Linux (n_tty_write, drivers/tty/n_tty.c) permite que um usuário local sem privilégios corrompa memória do kernel e derrube o sistema, com potencial de escalada de privilégios. A falha existe desde a reescrita da camada pty introduzida no 2.6.31-rc3 e afeta todas as versões até 3.14.3; está confirmada como explorada ativamente (catálogo KEV da CISA) e tem PoC pública circulando.
Detalhamento técnico
O problema está na combinação dos flags de terminal LECHO (echo local ativado) e !OPOST (pós-processamento de saída desabilitado) — o chamado modo raw com echo. Nesse modo, o n_tty_write grava diretamente no buffer de saída sem passar pela via normal de processamento, e ao mesmo tempo o mecanismo de echo do line discipline também escreve nesse buffer. Quando dois processos ou threads escrevem simultaneamente no mesmo pty (uma operação de write do usuário concorrendo com a rotina de echo), não havia serialização adequada de acesso ao buffer do driver tty.
O resultado, segundo o próprio advisory da SUSE (que recebeu o relato de um cliente, a Ericsson), é um heap-based buffer overflow: o fim do buffer de escrita do pty pode ser sobrescrito, corrompendo memória de buffers adjacentes no heap do kernel. É uma race condition clássica (CWE-362) que degenera em corrupção de memória (CWE-787/CWE-119) — não uma falha de validação de entrada, mas de sincronização entre caminhos concorrentes de escrita/echo.
O desenvolvedor do kernel Jiri Slaby identificou que a falha foi introduzida pelo commit d945cb9cce20ac7143c2de8d88b187f62db99bdc ('pty: Rework the pty layer to use the normal buffering logic'), que entrou no 2.6.31-rc3. Antes disso, o pty escrevia diretamente na linha de disciplina sem usar esse buffer, e a race não existia.
O atacante controla o conteúdo e o timing das escritas no pty — strings longas aumentam a janela de corrupção, conforme a descrição oficial menciona 'triggering a race condition involving read and write operations with long strings'. Não há necessidade de manipular dados especiais além de abrir/usar um pty em modo raw com echo e gerar escritas concorrentes.
Como é explorada
Pré-requisito real: acesso local ao sistema, mesmo sem privilégios (PR:L no CVSS aqui reflete a necessidade de conseguir abrir e configurar um pseudo-terminal, algo que qualquer usuário comum consegue via chamadas padrão como openpty/ioctl TCSETS). Não é preciso configuração especial do administrador — o próprio atacante configura seu pty para LECHO ativado e OPOST desativado, condição alcançável por qualquer processo com um pty próprio (terminais interativos, sessões shell, containers com pty alocado).
A exploração consiste em disparar escritas concorrentes no mesmo pty — por exemplo, um processo escrevendo dados longos enquanto o line discipline processa echo desses mesmos dados — de forma a vencer a race e sobrescrever memória adjacente ao buffer do driver tty. O resultado determinístico documentado é crash do kernel (painc/oops); a escalada de privilégios é mencionada na descrição oficial e no CVSS original da NVD como possível, mas depende de conseguir controlar o que é sobrescrito no heap, o que é mais difícil e menos determinístico que apenas crashar a máquina — por isso o vetor mais citado na prática é DoS.
A presença no catálogo KEV da CISA confirma exploração real observada, e há PoC pública referenciada (pastebin). Em ambientes multiusuário, VPS compartilhadas e containers que expõem pty ao usuário não-root, o impacto é relevante porque a única barreira é 'ter uma sessão local' — não há rede envolvida, e a complexidade de disparo do PoC é baixa (AC:L).
Versões
Como se proteger
A correção definitiva é atualizar o kernel para uma versão com o patch 'n_tty: Fix n_tty_write crash when echoing in raw mode' (commit 4291086b1f081b869c6d79e5b7441633dc3ace00), que adiciona um mutex (ldata->output_lock) em torno da chamada tty->ops->write dentro de n_tty_write, serializando o acesso ao buffer que antes era concorrente. Distribuições empacotaram esse patch em atualizações específicas: Red Hat backportou para RHEL 6.3 EUS via kernel-2.6.32-279.43.2.el6 (RHSA-2014:0512); Oracle Linux via kernel-2.6.32-431.20.2 (ELSA-2014-0771); SUSE/openSUSE também lançaram avisos próprios. Não há um número de versão upstream único e confiável citado nas fontes disponíveis além de 'corrigido após o kernel 3.14.3' mencionado na descrição oficial — para confirmar se um kernel específico de terceiros já contém o fix, é preciso checar o changelog do pacote ou a presença do mutex em n_tty_write.
Não existe mitigação de configuração real que elimine o risco sem o patch: LECHO e OPOST são flags de terminal que qualquer usuário local pode setar em seu próprio pty via ioctl, então não há como bloquear a pré-condição por política de sistema sem quebrar funcionalidade legítima de terminais (screen, tmux, editores em modo raw, etc.). Restringir acesso local (menos usuários com shell, isolamento de containers) reduz a superfície mas não corrige a falha.
O que não funciona: acreditar que desabilitar echo em nível de aplicação do usuário protege o sistema — a configuração do terminal é definida pelo processo que o abre, e um atacante local simplesmente define os flags que quiser no pty que ele mesmo controla.
Como detectar
Não há assinatura de rede — a exploração é inteiramente local. O sinal mais confiável é um kernel oops/panic com corrupção de memória (heap/slab corruption, general protection fault) associado a n_tty_write, echo em pty, ou ao driver tty/pty nos logs do kernel (dmesg, /var/log/kern.log) sem causa aparente de hardware. Processos não-root gerando volume anômalo de escritas concorrentes longas no mesmo pty, especialmente em terminais configurados em modo raw com echo, é um comportamento suspeito a auditar, mas não há um indicador determinístico de tentativa de exploração distinto de um crash espontâneo — a ausência de logging padronizado para essa race torna a atribuição forense difícil sem análise post-mortem do core dump do kernel.