Kees Cook pide unha mellor organización do traballo en Linux en canto a corrección de erros

Kees cociña Fago unha publicación no blogue na que suscitou preocupacións sobre o proceso de corrección de erros en curso nas ramas estables do núcleo de Linux e é iso mencionar que semana a semana inclúense preto de cen correccións en ramas estables, que é demasiado e require moito esforzo para manter os produtos baseados en núcleo de Linux.

Segundo Kees, omítese o proceso de tratamento de erros do núcleo e o núcleo carece de polo menos 100 desenvolvedores adicionais para traballar de xeito coordinado nesta área. Mencionando tamén que os principais desenvolvedores do kernel corrixen regularmente erros, pero non hai ningunha garantía de que estas correccións se trasladen a variantes do kernel de terceiros.

Ao facelo, menciona que os usuarios de varios produtos baseados no núcleo de Linux tampouco teñen forma de controlar que erros se corrixen e que núcleo se usa nos seus dispositivos. En última instancia, os vendedores son responsables da seguridade dos seus produtos, pero ante unha taxa moi alta de parches nas ramas do núcleo estables, atopáronse coa opción de migrar todos os parches, migrar selectivamente os máis importantes ou ignorar todos os parches. .

Os desenvolvedores do núcleo upstream poden solucionar erros, pero non teñen control sobre o que un provedor downstream elixe incorporar aos seus produtos. Os usuarios finais poden escoller os seus produtos, pero xeralmente non teñen control sobre que erros se corrixen ou que núcleo se usa (un problema por si só). En definitiva, os vendedores son responsables de manter seguros os seus núcleos de produtos.

Kees cociña suxire que a solución óptima sería transferir só as correccións e vulnerabilidades máis importantes, pero o principal problema é separar estes erros do fluxo xeral, xa que a maioría dos problemas emerxentes son consecuencia do uso da linguaxe C, que require moito coidado ao traballar con memoria e punteiros.

Para empeorar as cousas, moitas correccións de vulnerabilidade potenciais non están etiquetadas con identificadores CVE ou non reciben un identificador CVE algún tempo despois da liberación do parche.

Nun ambiente así, é moi difícil para os fabricantes separar pequenas correccións dos principais problemas de seguridade. Segundo as estatísticas, máis do 40% das vulnerabilidades son eliminadas antes da asignación de CVE e, de media, o atraso entre unha versión de corrección e unha asignación de CVE é de tres meses (é dicir, ao principio, unha solución percibe unha solución como un erro común,

Como resultado, non ter unha rama separada con correccións para as vulnerabilidades e non recibir información sobre a conexión coa seguridade de tal ou cal problema, os fabricantes de produtos baseados en kernel de Linux teñen que transferir continuamente todas as correccións das novas ramas estables. Pero este traballo require moita man de obra e enfróntase á resistencia das empresas debido ao medo a cambios regresivos que poidan perturbar o funcionamento normal do produto.

Chaves Cociñar cre que a única solución para manter o núcleo seguro a un custo razoable a longo prazo é levar aos enxeñeiros do parche ás construcións de núcleos tolosTraballar xuntos de xeito coordinado para manter parches e vulnerabilidades no núcleo ascendente. Tal e como está, moitos vendedores non usan as últimas versións do núcleo nos seus produtos e as correccións de backport por si mesmas, é dicir, resulta que enxeñeiros de distintas empresas duplican o traballo do outro, resolvendo o mesmo problema.

Por exemplo, se 10 empresas, cada unha con un enxeñeiro que soporta as mesmas correccións, redirixen estes enxeñeiros para corrixir erros augas arriba, en vez de migrar unha corrección, poderían corrixir 10 erros diferentes para o beneficio xeral ou xuntarse para revisar os erros. . E evite incluír o código buggy no núcleo. Os recursos tamén se poderían usar para crear novas ferramentas de análise e proba de código que detectasen automaticamente nunha fase inicial as clases de erro típicas que xorden unha e outra vez.

Chaves Cociñar tamén propón usar de forma máis activa probas e difusións automatizadas directamente no proceso de desenvolvemento do núcleo, use sistemas de integración continua e abandone a xestión arcaica do desenvolvemento a través do correo electrónico.

Fuente: https://security.googleblog.com


O contido do artigo adhírese aos nosos principios de ética editorial. Para informar dun erro faga clic en aquí.

Sexa o primeiro en opinar sobre

Deixa o teu comentario

Enderezo de correo electrónico non será publicado. Os campos obrigatorios están marcados con *

*

*

  1. Responsable dos datos: Miguel Ángel Gatón
  2. Finalidade dos datos: controlar SPAM, xestión de comentarios.
  3. Lexitimación: o seu consentimento
  4. Comunicación dos datos: os datos non serán comunicados a terceiros salvo obrigación legal.
  5. Almacenamento de datos: base de datos aloxada por Occentus Networks (UE)
  6. Dereitos: en calquera momento pode limitar, recuperar e eliminar a súa información.