Vulnerabilidade crítica no Kernel do Linux afeta Milhões de serviços

Vulnerabilidade crítica no Kernel do Linux afeta Milhões de serviços. A Netflix descobriu várias vulnerabilidades em como o Linux (e em alguns casos o FreeBSD) está processando a opção “Confirmação TCP seletiva (SACK)” . A mais crítica das vulnerabilidades pode levar a um pânico no kernel, tornando o sistema sem resposta. Corrigir esta vulnerabilidade é crítico. Uma vez que uma exploração é liberada, a vulnerabilidade pode ser usada para desligar servidores expostos, ou prováveis clientes conectando-se a serviços maliciosos.

Você estará vulnerável se estiver usando um sistema Linux atual, tiver reconhecimentos seletivos ativados (um padrão comum) e estiver usando uma placa de rede com o TCP Segment Offload (novamente, um padrão comum em servidores modernos).

Embora um patch foi disponibilizado, alternativamente, você pode desativar o SACK. O Netflix incluiu patches para o kernel Linux em seu alerta. As seguintes versões do kernel do Linux incluem o patch: 4.4.182, 4.9.182, 4.14.127, 4.19.52, 5.1.11.

**Vulnerability Overview**
CVE	Operating System Affected	Description/Impact
CVE-2019-11477	Linux > 2.6.29	SACK processing integer overflow. Leads to kernel panic.
CVE-2019-11478	Linux < 4.14.127	SACK Slowness or Excess Resource Usage
CVE-2019-5599	FreeBSD	RACK Send Map SACK Slowness
CVE-2019-11479	Linux (all versions)	Excess Resource Consumption Due to Low MSS Values

Segundo a Red Hat, três falhas relacionadas foram encontradas na manipulação de rede TCP do kernel do Linux. A vulnerabilidade mais grave pode permitir que um invasor remoto acione um pânico no kernel em sistemas que executam o software afetado e, como resultado, afeta a disponibilidade do sistema.

Os problemas foram atribuídos a vários CVEs: CVE-2019-11477 é considerado uma gravidade Importante , enquanto CVE-2019-11478 e CVE-2019-11479 são considerados uma gravidade Moderada .

Os dois primeiros estão relacionados aos pacotes de Confirmação Seletiva (SACK) combinados com Tamanho Máximo do Segmento (MSS), o terceiro somente com o Tamanho Máximo do Segmento (MSS).

Detalhes do problema e histórico

Três falhas relacionadas foram encontradas na manipulação do kernel Linux de pacotes de Confirmação Seletiva TCP (SACK) manipulando com baixo tamanho MSS. A extensão do impacto é entendida como limitada à negação de serviço neste momento. Nenhum escalonamento de privilégios ou vazamento de informações é suspeito no momento.

Embora ações de mitigações estejam disponíveis, elas podem afetar o tráfego de fontes legítimas que exigem valores de MSS inferiores para transmitir corretamente e desempenho do sistema. Por isto,a Red Hat recomenda que o usuário deve avaliar a mitigação que é apropriada para o ambiente do sistema antes de aplicar.

Como sempre procuramos fazer, consultamos outras fontes de informação sobre o assunto e consolidamos para o nosso leitor ter a melhor e mais completa informação sobre o assunto. Assim, para entendermos melhor e ajudar a todos, o Blog Minuto da Segurança foi buscar no SANS ISC InfoSec Forums maiores esclarecimentos sobre o SACK Panic e o que podemos fazer para evitá-lo, veja abaixo as explicações e referências que temos no site da Red Hat e as informações dadas por Johannes B. Ullrich, Ph.D., Dean of Research, SANS Technology Institute

O que é um reconhecimento seletivo?

A Confirmação Seletiva TCP (SACK) é um mecanismo em que o receptor de dados pode informar ao remetente sobre todos os segmentos que foram aceitos com sucesso. Isso permite que o remetente retransmita segmentos do fluxo que estão ausentes do conjunto “bom”. Quando o TCP SACK é desativado, um conjunto muito maior de retransmissões é necessário para retransmitir um fluxo completo.

O que é o MSS?

O tamanho máximo do segmento (MSS) é um parâmetro definido no cabeçalho TCP de um pacote que especifica a quantidade total de dados contidos em um segmento TCP reconstruído.
Como os pacotes podem se tornar fragmentados ao transmitir através de rotas diferentes, um host deve especificar o MSS como igual ao maior tamanho de carga útil do datagrama IP que um host pode manipular. Tamanhos muito grandes de MSS podem significar que um fluxo de pacotes acaba fragmentado em seu caminho para o destino, enquanto pacotes menores podem garantir menos fragmentação, mas acabam com sobrecarga não utilizada.

Sistemas operacionais e tipos de transporte podem especificar um tamanho padrão de MSS . Os atacantes com acesso privilegiado podem criar pacotes brutos com opções MSS criadas no pacote para criar esse ataque.

O que é o SACK?

Segundo o SANS, cada host conectado a uma rede pode enviar pacotes com um tamanho máximo específico (“MTU”). Esse tamanho depende da tecnologia de rede usada e, para Ethernet, um tamanho típico é de 1500 bytes. Mas pode ser tão grande quanto 9.000 para Ethernet. Algum deste espaço é usado para cabeçalhos. Com um cabeçalho IP padrão de 20 bytes e um cabeçalho TCP de 20 bytes, os pacotes TCP geralmente podem armazenar até 1.460 bytes de dados (o “Maximum Segment Size”).

O TCP dividirá um fluxo de dados em segmentos que são pequenos o suficiente para não exceder esse tamanho, e os hosts comunicarão seus respectivos tamanhos de segmento máximo entre si para reduzir a chance de fragmentação.

Para encomendar pacotes numa ligação TCP, cada byte transmitido é atribuído a um número de sequência e o cabeçalho TCP irá listar o número de sequência do primeiro byte contido no pacote. Um receptor confirmará qual número de sequência recebeu comunicando o próximo número de sequência que espera.

Apenas reconhecer segmentos completos leva a um pouco de ineficiência. Um receptor não pode comunicar a um remetente que ele já recebeu alguns dados fora de ordem. Em vez disso, continuará a reconhecer o último conjunto completo de segmentos que recebeu.

Para evitar essa ineficiência, o SACK foi introduzido. Permite que os receptores notifiquem o remetente que recebeu um segmento fora de ordem. “Recebi tudo até a sequência 10 e espero 11 depois, mas também recebi 20-30“. Dessa forma, o remetente sabe reenviar apenas 11-19 e continuar com o próximo 31.

O que é o TCP Segment Offload ?

O TCP Segment Offload é um recurso incluído na maioria das placas de rede atuais. Para reduzir o trabalho que as CPUs precisam fazer para armazenar em buffer e remontar os segmentos TCP, as placas de rede cuidarão de parte do processamento do TCP. Nesse caso, o sistema operacional receberá grandes “pacotes” excedendo a MTU da rede.

O que é o TCP “SACK Panic”?

Os sistemas operacionais precisam armazenar dados até que sejam transmitidos (e confirmados) ou recebidos. O Linux usa uma estrutura de dados chamada “Buffer de soquete” para fazer isso. No Linux, esse buffer de soquete pode conter até 17 segmentos. À medida que os pacotes são enviados e confirmados, os dados são removidos da estrutura ou alguns dos dados podem ser consolidados. Mover os dados pode, em alguns casos, levar a mais de 17 segmentos armazenados, o que, por sua vez, leva a um pânico no kernel.

O que posso fazer para evitar isso?

Segundo o site SANS ISC InfoSec Forums existem duas formas de evitar o problema.

1) Desabilite o SACK no Linux

Você pode desativar temporariamente o SACK sem reinicializar. Como root run:

setenforce 0
echo 0 > /proc/sys/net/ipv4/tcp_sack

A primeira linha só é necessária se você estiver usando o SELinux, pois ele pode bloquear a segunda instrução. Para tornar esta mudança permanente, adicione o seguinte ao /etc/sysctl.conf (ou provavelmente mais limpo como um novo arquivo em /etc/sysctl.d):

net.ipv4.tcp_sack = 0
net.ipv4.tcp_dsack = 0
net.ipv4.tcp_fack = 0

Execute “sysctl -p” para aplicar as mudanças sem uma reinicialização (e, novamente, você pode precisar desativar o SELinux).

2) Regras de firewall

A exploração requer configurações de tamanho de segmento máximo muito pequenas. Você pode bloquear pacotes anunciando um pequeno MSS no iptables:

iptables -t mangle -A PREROUTING -p tcp -m conntrack –ctstate NEW -m tcpmss ! –mss 536:65535 -j DROP

De acordo com a RFC 879, o TCP exige um MTU de pelo menos 576, levando a um MSS mínimo de 536.

Encontrando Sistemas Vulneráveis

Segundo o SANS, não há ferramenta de varredura disponível para encontrar sistemas vulneráveis. Até agora, também não há exploração PoC disponível que possa ser usada para encontrar sistemas vulneráveis. Como um teste rápido, você pode procurar por sistemas que suportem o SACK (e rodando o Linux). O seguinte comando tcpdump pode ajudar:

tcpdump -i eth0 -n ‘ip[8]<65 and tcp[13]&0x2f=2’ | grep ‘sackOK’

Esse comando ajudará a identificar sistemas com os flags SYN ou SYN-ACK definidos com um TTL menor que 65 (para ajudar a limitar isso aos sistemas Linux). Não existe um filtro simples para a opção SackOK, pois pode aparecer em posições diferentes, então o “grep” ajuda um pouco. Você pode usar o comando “ethtool” no Linux para ver se o descarregamento do TCP está ativado (ethtool -k interface_name).

Declarações dos Fabricantes / Patches

O SANS Fórum indica os seguintes links para maiores informações vindas dos fabricantes.

Redhat: https://access.redhat.com/security/vulnerabilities/tcpsack
Ubuntu: https://usn.ubuntu.com/4017-1/
Debian: https://www.debian.org/security/2019/dsa-4465
SUSE: https://www.suse.com/de-de/support/kb/doc/?id=7023928
Cloudflare: https://twitter.com/jgrahamc/status/1140724787242819585
Amazon: https://aws.amazon.com/security/security-bulletins/AWS-2019-005/

Autor das recomendações: Johannes B. Ullrich, Ph.D., Dean of Research, SANS Technology Institute

Fonte: Red Hat & SANS ISC InfoSec Forums

Veja também: