Cozinheiro Kees Eu faço um post no blog no qual levantou preocupações sobre o processo de correção de bugs em curso nos ramos estáveis do kernel Linux e é que mencionar que semana a semana cerca de cem correções são incluídas em branches estáveis, o que é muito e requer muito esforço para manter produtos baseados no kernel do Linux.
De acordo com Kees, o processo de tratamento de erros do kernel é ignorado e o kernel carece de pelo menos 100 desenvolvedores adicionais trabalhar de forma coordenada nesta área. Mencionando também que os principais desenvolvedores do kernel corrigem bugs regularmente, mas não há garantia de que essas correções serão transportadas para variantes de kernel de terceiros.
Ao fazer isso, ele menciona que os usuários de vários produtos baseados no kernel do 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 fornecedores são responsáveis pela segurança de seus produtos, mas diante de uma taxa muito alta de patches em branches de kernel estáveis, eles tiveram que escolher entre migrar todos os patches, migrar seletivamente os mais importantes ou ignorar todos os patches. .
Os desenvolvedores do kernel upstream podem corrigir bugs, mas não têm controle sobre o que um fornecedor downstream escolhe incorporar em seus produtos. Os usuários finais podem escolher seus produtos, mas geralmente não têm controle sobre quais bugs são corrigidos ou qual kernel é usado (um problema por si só). Em última análise, os fornecedores são responsáveis por manter os núcleos de seus produtos seguros.
Cozinheiro Kees sugere que a solução ideal seria transferir apenas as correções e vulnerabilidades mais importantes, mas o principal problema é separar esses erros do fluxo geral, já que a maioria dos problemas emergentes são conseqüência do uso da linguagem C, que requer muito cuidado ao se trabalhar com memória e ponteiros.
Para piorar as coisas, muitas correções de vulnerabilidades em potencial não são marcadas com identificadores CVE ou não recebem um identificador CVE algum tempo após o lançamento do patch.
Em tal ambiente, é muito difícil para os fabricantes separar pequenas correções dos principais problemas de segurança. De acordo com as estatísticas, mais de 40% das vulnerabilidades são removidas antes da atribuição CVE e, em média, o atraso entre um lançamento de correção e uma atribuição CVE é de três meses (ou seja, no início, um percebe uma solução como um erro comum,
Como resultado, não ter uma filial separada com correções para as vulnerabilidades e não receber informações sobre a conexão com a segurança deste ou daquele problema, fabricantes de produtos baseados no kernel Linux têm que transferir continuamente todas as correções dos novos ramos estáveis. Mas esse trabalho é trabalhoso e enfrenta resistências das empresas por temores de mudanças regressivas que possam atrapalhar o funcionamento normal do produto.
Cozinheiro de Chaves acredita que a única solução para manter o kernel seguro a um custo razoável a longo prazo é portar os engenheiros de patch para compilações de kernel malucasl para trabalhar juntos de forma coordenada para manter patches e vulnerabilidades no kernel upstream. Do jeito que está, muitos fornecedores não usam as versões mais recentes do kernel em seus produtos e correções de backport por conta própria, 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 suportando as mesmas correções, redirecionassem esses engenheiros para corrigir bugs upstream, em vez de migrar uma correção, eles poderiam corrigir 10 bugs diferentes para o benefício geral ou se reunir para revisar os bugs. Alterações propostas . E evite incluir código com erros no kernel. Os recursos também poderiam ser usados para criar novas ferramentas de análise e teste de código que detectariam automaticamente em um estágio inicial as classes de erro típicas que aparecem repetidamente.
Cozinheiro de Chaves também propõe o uso mais ativo de testes automatizados e difusão diretamente no processo de desenvolvimento do kernel, use sistemas de integração contínua e abandone o gerenciamento arcaico de desenvolvimento por e-mail.
fonte: https://security.googleblog.com