Se exploradas, essas falhas podem permitir que invasores obtenham acesso não autorizado a informações confidenciais ou geralmente causem problemas
Há poucos dias foi anunciada a notícia de que seria uma vulnerabilidade detectada no subsistema de rede do kernel Linux que permite, sobrescrevendo o conteúdo da memória do kernel, manipulando soquetes de rede no espaço do usuário.
É mencionado que a vulnerabilidade (já catalogada em CVE-2023-42752) é classificado como crítico e pode ser usado para permitir acesso de usuário sem privilégios para executar seu código no nível do kernel.
Sobre a vulnerabilidade CVE-2023-42752
Assim, a falha detectada É causado por uma mudança introduzida no kernel Linux versão 6.2, mas é mencionado que esta mudança também foi introduzida em todas as ramificações LTS suportadas, portanto a vulnerabilidade Ele também aparece em versões mais antigas de ramificações estáveis suportadas do kernel.
Olá,
Recentemente encontrei um estouro de número inteiro no kernel do Linux, o que leva para o kernel alocando `skb_shared_info` no espaço do usuário, que é explorável em sistemas sem proteção SMAP de `skb_shared_info` contém referências a ponteiros de função.
Verifiquei a existência da vulnerabilidade tanto na filial principal e v6.1.y, mais versões podem ser afetadas (potencialmente todas as versões estáveis)
Quanto às causas do problema, menciona-se estouro de inteiro ainda é devido na função "alloc_skb" do kernel Linux, o cue é usado para fornecer a alocação de memória para a estrutura sk_buff (buffer de soquete), que é usada para armazenar pacotes de rede.
A vulnerabilidade pode ser explorada porque ocorre um problema que causa estouro devido à falta de validação adequada dos parâmetros recebidos do usuário usados para calcular o tamanho do buffer. Um ataque por um usuário sem privilégios requer acesso para criar namespaces de usuário, que pode ser fornecido, por exemplo, em recipientes isolados.
Captura de tela do código
É mencionado que: A função `kmalloc_reserve` arredonda o tamanho em `PAGE_SIZE << get_order(size);` em `kmalloc_size_roundup`. Como 'tamanho' é 'unsigned int', a lógica de arredondamento o tornará 0 se o valor original for maior, por exemplo, algo como 0xffffded0. Como resultado, "dados" se tornarão na verdade `ZERO_SIZE_PTR`, que é 0x10 em vez de 0. Como a verificação não considera o caso, o kernel continuará processando "dados" como se fossem um ponteiro para o kernel válido.
Mais tarde, quando o kernel tenta finalizar o objeto skb em `__finalize_skb_around`, ele tem o código: `shinfo = skb_shinfo(skb);`, que é `skb->head+skb->end` onde `skb->head `é 0x10 e `skb->end`
é um tamanho grande como 0xffffmed0. Como resultado, `shinfo` aponta para um ponteiro de espaço do usuário.
Vale ressaltar que a vulnerabilidade CVE-2023-42752 é local e não pode ser explorado remotamente pela rede, pois, como mencionamos acima, um invasor requer acesso para criar namespaces de usuário.
Em 2010, eu não sabia que usuários mal-intencionados poderiam definir dev->mtu com valores arbitrários. Desde então, esse mtu foi limitado a 0x7fffffff, mas independentemente do tamanho do dev-> mtu, não faz sentido para igmpv3_newpack() alocar mais do que IP_MAX_MTU e correr o risco de transbordar vários campos skb
Como solução temporária Recomenda-se que o mecanismo de proteção SMAP esteja habilitado (Prevenção de acesso ao modo Supervisor) no kernel, o que bloqueia o problema.
Quanto à solução para o problema como tal, isso já foi corrigido e distribuídas nas correções que bloqueiam a vulnerabilidade nas diferentes versões com suporte ao kernel, é mencionado que as alterações foram aceitas nas ramificações estáveis do kernel no dia 5 de setembro.
Finalmente, para o interessado em rastrear a correção da vulnerabilidade, você pode fazê-lo nas páginas das diferentes distribuições: Debian, Ubuntu, Gentoo, RHEL,fedora e SUSE/openSUSE.Você pode verificar os detalhes da vulnerabilidade no link a seguir