Linus Torvalds aceitou um documento que regula o processo de tratamento de erros relacionados à segurança no núcleo, que define o modelo de ameaças, esclarecendo quais erros no núcleo são considerados vulnerabilidades, e discute as ações a serem tomadas em relação aos erros identificados com a ajuda da IA. O documento foi preparado por Willy Tarreau, autor do HAProxy e desenvolvedor veterano do núcleo Linux, responsável pela manutenção de vários ramos estáveis do núcleo. As bases foram estabelecidas a partir de acordos alcançados durante a discussão de vulnerabilidades críticas recentemente identificadas no núcleo (1, 2, 3, 4), reveladas antes da publicação das correções e para as quais, graças à IA, foi possível criar exploits funcionais imediatamente.
A maioria dos erros relacionados à segurança deve ser tratada publicamente, a fim de atrair a maior audiência possível e encontrar a solução otimizada. Apenas mensagens de urgência sobre vulnerabilidades facilmente exploráveis, que representam uma ameaça para muitos usuários e permitem a obtenção de privilégios ou capacidades expandidas, são sugeridas para serem enviadas a uma lista de distribuição privada.
As vulnerabilidades identificadas com a ajuda de assistentes de IA devem sempre ser discutidas publicamente, pois esses problemas são frequentemente descobertos simultaneamente por vários pesquisadores. Contudo, não se deve revelar o exploit no relatório — é suficiente mencionar que ele está disponível e fornecê-lo de forma privada em resposta ao pedido do responsável.
Regras para a transmissão de relatórios gerados com a ajuda de assistentes de IA são descritas separadamente. Muitos relatórios desse tipo são enviados e, graças a eles, é possível identificar erros em partes do código que não foram bem revisadas, mas os responsáveis frequentemente os ignoram devido à baixa qualidade e imprecisões. Os principais requisitos para os relatórios gerados com assistentes de IA são:
- Breviedade, sem rodeios e com ênfase na essência e detalhes importantes logo no início.
- Apenas texto puro sem tags Markdown ou decoração.
- Compreensão do modelo de ameaças e indicação de fatos verificáveis (por exemplo, "o erro permite que qualquer usuário obtenha CAP_NET_ADMIN"), e não especulações teóricas e conjecturas sobre as consequências da vulnerabilidade.
- Antes de enviar o relatório, é essencial testar cuidadosamente a funcionalidade do exploit gerado pelo AI e garantir que o problema possa ser reproduzido.
- Utilizando AI para desenvolver e testar correções para o problema identificado.
Estatísticas de acompanhamentos indicam que a maioria dos relatórios de erros enviados como se fossem correções de vulnerabilidades não são, e devem ser tratados como erros comuns. Para diferenciar vulnerabilidades de erros comuns, um modelo de ameaça foi descrito no núcleo do Linux. Entre as possibilidades e garantias cuja violação pode ser considerada uma vulnerabilidade:
- Isolamento em nível de usuário: acesso a arquivos restrito ao proprietário, a memória do processo não acessível a outros usuários, ptrace proibido para processos de outros, e isolamento IPC e comunicações de rede.
- Proteção baseada em capacidades: sem CAP_SYS_ADMIN não é possível alterar a configuração do núcleo, a memória, ou o estado do sistema; sem CAP_NET_ADMIN não é permitido alterar configurações de rede ou interceptar tráfego; sem CAP_SYS_PTRACE não é possível monitorar processos de outros usuários.
- O namespace de identificadores de usuários (CONFIG_USER_NS) permite que usuários não privilegiados criem seus próprios ambientes isolados, que não podem impactar o espaço de nome global, por exemplo, mudando a hora, carregando módulos ou montando dispositivos blocos.
- Interfaces de depuração (/proc/kmsg, perf, debugfs), através das quais é possível acessar informações confidenciais, estão disponíveis apenas após a concessão explícita de acesso pelo administrador.
Capacidades que não são consideradas vulnerabilidades:
- Uso de versões desatualizadas do núcleo.
- Compilação com opções para desenvolvedores ou que diminuem a segurança (por exemplo, CONFIG_NOMMU).
- Definição de configurações sysctl inseguras, opções de linha de comando, permissões no sistema de arquivos, capacidades ou fornecimento de acesso a interfaces privilegiadas para usuários não privilegiados (por exemplo, acesso de gravação ao procfs e debugfs).
- Problemas em funções destinadas apenas para desenvolvimento e depuração do núcleo, como LOCKDEP, KASAN e FAULT_INJECTION, que não devem ser incluídas em configurações de produção.
- Problemas em drivers, módulos e subsystems que estão na seção STAGING ou marcados como experimentais, inseguros ou não funcionais.
- Uso de módulos de kernel de terceiros ou forks não oficiais do kernel.
- Exigência de privilégios excessivos, como a necessidade de executar ações com direitos de root ou de um usuário com direitos de CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_RAWIO e CAP_SYS_MODULE.
- Ataques teóricos que requerem condições de laboratório, bilhões de tentativas, emulação ou modificação de hardware, custos desproporcionais e configurações irreais (por exemplo, sistemas com dezenas de milhares de núcleos de CPU).
- Contornar mecanismos de proteção (por exemplo, ASLR) sem demonstração de exploit. Ausência de verificações de argumentos e códigos de erro retornados que não têm consequências claras.
- Vazamentos de informações acidentais, fora do controle dos atacantes, como dados remanescentes em mensagens de erro e vazamentos de endereços/pontadores para a memória do kernel sem uma possibilidade direta de exploração.
- Erros na montagem de imagens de disco corrompidas, se o driver não for declarado como apropriado para uso com mídias não confiáveis. Problemas com imagens de disco que são detectados e resolvidos através da execução da ferramenta fsck.
- Ataques que requerem acesso físico ao hardware, modificação de hardware ou conexão de dispositivos de hardware, como placas para ataque por DMA e analisadores lógicos, se o sistema não estiver especificamente configurado para proteção contra tais ataques (IOMMU).
- Regressões de funcionalidade e desempenho que podem ser corrigidas ajustando permissões e limites.
Fonte: opennet.ru
