Kees Cook do Google chamou por uma modernização no processo de correção de erros no núcleo do Linux

Kees Cook, ex-administrador do sistema principal do kernel.org e líder da Ubuntu Security Team, atualmente trabalhando no Google para garantir a segurança do Android e do ChromeOS, expressou preocupação com o atual processo de correção de erros nas versões estáveis do kernel. Semanalmente, cerca de cem correções são incluídas nas versões estáveis, e após o fechamento da janela de aceitação de alterações para o próximo lançamento, esse número se aproxima de mil (os mantenedores seguram as correções até o fechamento da janela, e após a formação do "-rc1", publicam tudo de uma só vez), o que é excessivo e exige grandes gastos de mão de obra para manter os produtos baseados no kernel Linux.

Na opinião de Kees, o processo de tratamento de erros no kernel não recebe a devida atenção e faltam ao menos 100 desenvolvedores adicionais para um trabalho coordenado nessa área. Os desenvolvedores principais do kernel corrigem erros regularmente, mas não há garantias de que essas correções sejam transferidas para as variantes do kernel usadas por fabricantes terceiros. Os usuários de diversos produtos baseados no kernel Linux também não têm a capacidade de verificar quais erros foram corrigidos e qual kernel está sendo utilizado em seus dispositivos. No final das contas, os fabricantes são responsáveis pela segurança de seus produtos, mas em um cenário de alta intensidade de publicação de correções nas versões estáveis do kernel, eles se deparam com a escolha de — transferir todas as correções, portar seletivamente as mais importantes ou ignorar todas as correções.

A solução ideal seria transferir apenas as correções e vulnerabilidades mais importantes, mas a principal dificuldade está em identificar esses erros em meio ao fluxo geral. O maior número de problemas pontuais é resultado do uso da linguagem C, que exige um grande cuidado ao lidar com memória e ponteiros. A situação se agrava pelo fato de que muitas possíveis correções de vulnerabilidades não são acompanhadas de identificadores CVE ou recebem um identificador semelhante algum tempo após a publicação da correção. Nessas condições, é muito difícil para os fabricantes distinguir as correções secundárias dos problemas importantes que impactam a segurança. Statísticas mostram que mais de 40% das vulnerabilidades são corrigidas antes de receber um CVE, e o atraso médio entre a liberação da correção e a atribuição do CVE é de três meses (ou seja, inicialmente a correção é percebida como um erro comum, mas apenas após alguns meses fica claro que se tratava da correção de uma vulnerabilidade).

Como resultado, sem um ramo separado para correções de vulnerabilidades e sem receber informações sobre a relação com a segurança de determinado problema, os fabricantes de produtos baseados no kernel Linux são forçados a transferir continuamente todas as correções das últimas versões estáveis. No entanto, esse trabalho exige um grande esforço e enfrenta resistência nas empresas devido ao receio de que ocorram mudanças regressivas que possam comprometer o funcionamento normal do produto.

Vale lembrar que, de acordo com Linus Torvalds, todos os bugs são importantes e as vulnerabilidades não devem ser separadas de outros tipos de bugs e destacadas como uma categoria de maior prioridade. Essa opinião se explica pelo fato de que, para um desenvolvedor comum, que não se especializa em segurança, a relação entre a correção e a potencial vulnerabilidade não é evidente (para muitas correções, apenas a realização de uma auditoria separada permite entender que elas estão relacionadas à segurança). Na visão de Linus, a responsabilidade de identificar as potenciais vulnerabilidades no fluxo geral de correções deve ser de especialistas em segurança das equipes responsáveis pelo suporte aos pacotes do kernel nas distribuições Linux.

Kees Cook acredita que a única solução para manter a segurança do núcleo com custos razoáveis de longo prazo é transferir engenheiros das empresas que portam correções para versões locais do núcleo, para um trabalho coordenado e conjunto na manutenção de correções e vulnerabilidades no núcleo principal (upstream). No estado atual, muitos fabricantes utilizam versões de núcleo não tão atualizadas em seus produtos e backportam correções por conta própria, ou seja, os engenheiros de diferentes empresas acabam duplicando o trabalho uns dos outros ao resolver o mesmo problema.

Por exemplo, se 10 empresas, cada uma com um engenheiro realizando o backport de correções semelhantes, redirecionassem esses engenheiros para corrigir falhas no upstream, em vez de realizar o porting de uma única correção, poderiam corrigir 10 falhas diferentes para o benefício comum ou se envolver em revisar as alterações propostas e prevenir que código com erros fosse incluído no núcleo. Os recursos também poderiam ser direcionados para a criação de novas ferramentas de teste e análise de código que permitem identificar automaticamente em uma fase inicial classes de erros recorrentes.

Kees Cook também sugere utilizar mais ativamente testes automatizados e fuzzing diretamente no processo de desenvolvimento do núcleo, aplicar sistemas de integração contínua e abandonar a gestão arcaica do desenvolvimento via e-mail. Atualmente, a eficácia do teste é prejudicada pelo fato de que os principais processos de teste estão separados do desenvolvimento e ocorrem apenas após a formação das versões. Kees também recomendou, para reduzir o número de erros, utilizar linguagens que proporcionam mais alto nível de segurança, como Rust.

Fonte: opennet.ru