Kees Cook, ex-administrador-chefe de sistema do kernel.org e líder da equipe de segurança do Ubuntu que agora trabalha no Google para proteger o Android e o ChromeOS, expressou preocupação com o processo atual de correção de bugs nas ramificações estáveis do kernel. Toda semana, cerca de cem correções são incluídas nas ramificações estáveis, e após o fechamento da janela para aceitação de alterações na próxima versão, ela se aproxima de mil (os mantenedores mantêm as correções até que a janela seja fechada e após a formação de “ -rc1” publicam os acumulados de uma só vez), o que é demais e exige muita mão de obra para produtos de manutenção baseados no kernel Linux.
Segundo Keys, o processo de trabalhar com erros no kernel não recebe a devida atenção e o kernel carece de pelo menos 100 desenvolvedores adicionais para um trabalho coordenado nesta área. Os principais desenvolvedores do kernel corrigem bugs regularmente, mas não há garantia de que essas correções serão transferidas para variantes do kernel usadas por terceiros. Os usuários de vários produtos baseados no kernel Linux também não têm como controlar quais bugs são corrigidos e qual kernel é usado em seus dispositivos. Em última análise, os fabricantes são responsáveis pela segurança de seus produtos, mas com a alta intensidade de publicação de correções em ramos estáveis do kernel, eles se depararam com uma escolha: portar todas as correções, portar seletivamente as mais importantes ou ignorar todas as correções .
A solução ideal seria migrar apenas as correções e vulnerabilidades mais importantes, mas isolar esses erros do fluxo geral é o principal problema. O maior número de problemas que surgem são consequência do uso da linguagem C, que exige muito cuidado ao trabalhar com memória e ponteiros. Para piorar a situação, muitos patches de vulnerabilidade em potencial não são fornecidos com um identificador CVE ou recebem um identificador CVE algum tempo após a publicação do patch. Nesse ambiente, é muito difícil para os fabricantes separar pequenas correções de questões importantes de segurança. De acordo com as estatísticas, mais de 40% das vulnerabilidades são corrigidas antes da atribuição de um CVE e, em média, o atraso entre o lançamento de uma correção e a atribuição de um CVE é de três meses (ou seja, a princípio a correção é percebida como um bug normal, mas somente depois de vários meses fica claro que a vulnerabilidade foi corrigida).
Como resultado, sem uma ramificação separada com correções para vulnerabilidades e sem receber informações sobre a conexão segura de um problema específico, os fabricantes de produtos baseados no kernel Linux têm que transferir continuamente todas as correções das ramificações estáveis mais recentes. Mas esse trabalho exige muita mão de obra e enfrenta resistência nas empresas pelo medo do surgimento de mudanças regressivas que possam atrapalhar o funcionamento normal do produto.
Recordemos que, de acordo com Linus Torvalds, todos os erros são importantes e as vulnerabilidades não devem ser separadas de outros tipos de erros e alocadas numa categoria separada de prioridade mais elevada. Esta opinião é explicada pelo fato de que para um desenvolvedor comum que não é especializado em questões de segurança, a conexão entre uma correção e uma vulnerabilidade potencial não é óbvia (para muitas correções, apenas uma auditoria separada permite entender que elas dizem respeito à segurança ). De acordo com Linus, especialistas em segurança das equipes responsáveis pela manutenção de pacotes de kernel em distribuições Linux devem estar envolvidos na identificação de possíveis vulnerabilidades no fluxo geral de patches.
Kees Cook acredita que a única solução para manter a segurança do kernel a um custo razoável a longo prazo é as empresas transferirem os engenheiros envolvidos na portabilidade de correções para compilações locais do kernel em um esforço conjunto e coordenado para manter correções e vulnerabilidades no kernel principal (upstream ). Em sua forma atual, muitos fabricantes não usam as versões mais recentes do kernel em seus produtos e fazem backport das correções internamente, ou seja, Acontece que engenheiros de empresas diferentes duplicam o trabalho uns dos outros, resolvendo o mesmo problema.
Por exemplo, se 10 empresas, cada uma com um engenheiro portando as mesmas correções, reatribuíssem esses engenheiros para corrigir bugs no upstream, então, em vez de fazerem backport de uma correção, elas poderiam corrigir 10 bugs diferentes para o benefício comum ou participar da revisão das propostas. alterações e evitar que códigos com erros sejam incluídos no kernel. Os recursos também poderiam ser dedicados à criação de novas ferramentas para testar e analisar código que permitiriam a detecção precoce de classes comuns de erros que surgem repetidamente.
Kees Cook também sugere o uso mais ativo de testes automatizados e difusos diretamente no processo de desenvolvimento do kernel, usando sistemas de integração contínua e abandonando o gerenciamento arcaico de desenvolvimento por e-mail. Atualmente, os testes eficazes são dificultados pelo fato de que os principais processos de teste são separados do desenvolvimento e ocorrem após a formação dos lançamentos. Keys também recomendou o uso de linguagens que oferecem maior nível de segurança, como Rust, no desenvolvimento para reduzir o número de erros.
Fonte: opennet.ru