Kees Cook, antigo CSO de kernel.org e líder do equipo de seguridade de Ubuntu, que agora traballa para Google para protexer Android e ChromeOS, expresou a súa preocupación polo proceso actual de corrección de erros nas ramas estables do núcleo. Cada semana, inclúense preto de cen correccións en ramas estables e, despois de pechar a xanela para aceptar cambios na seguinte versión, achégase a mil (os mantedores manteñen correccións ata que se pecha a xanela e despois da formación de "-rc1" publicar os acumulados á vez), o que é demasiado e require moita man de obra para produtos de mantemento baseados no núcleo de Linux.
Segundo Keys, o proceso de traballar con erros no núcleo non recibe a debida atención e o núcleo carece de polo menos 100 desenvolvedores adicionais para o traballo coordinado nesta área. Os desenvolvedores do núcleo central corrixen erros de forma regular, pero non hai garantía de que estas correccións sexan portadas a variantes do núcleo utilizadas por terceiros. Os usuarios de varios produtos baseados no núcleo Linux tampouco teñen forma de controlar que erros se corrixen e que núcleo se usa nos seus dispositivos. Os provedores son os responsables en última instancia da seguridade dos seus produtos, pero cunha taxa de parches moi alta nas ramas estables do núcleo, enfrontáronse a elixir entre trasladar todos os parches, portar selectivamente os máis importantes ou ignorar todos os parches.
A solución óptima sería migrar só as correccións e vulnerabilidades máis importantes, pero illar tales erros do fluxo xeral é o principal problema. A maioría dos problemas que aparecen débense ao uso da linguaxe C, que require moito coidado ao tratar coa memoria e os punteiros. Para empeorar as cousas, moitas correccións de vulnerabilidades potenciais non se proporcionan cos identificadores CVE ou reciben ese identificador algún tempo despois de que se publique o parche. En tales condicións, é moi difícil para os fabricantes separar correccións menores dos principais problemas de seguridade. Segundo as estatísticas, máis do 40 % das vulnerabilidades están corrixidas antes de que se asignen un CVE e o atraso medio entre o lanzamento dun parche e a asignación dun CVE é de tres meses (é dicir, ao principio, o parche percíbese como algo común). erro, pero só despois duns meses queda claro que a vulnerabilidade foi corrixida).
Como resultado, sen ter unha rama separada con correccións de vulnerabilidades e sen recibir información sobre a conexión de seguranza dun problema en particular, os fabricantes de produtos baseados no núcleo de Linux deben transferir continuamente todas as correccións de ramas estables novas. Pero este traballo require moita man de obra e atopa resistencias nas empresas polo temor a cambios regresivos que poidan perturbar o normal funcionamento do produto.
Lembre que, segundo Linus Torvalds, todos os erros son importantes e as vulnerabilidades non deben separarse doutros tipos de erros e asignarse a unha categoría de prioridade superior separada. Esta opinión explícase polo feito de que para un desenvolvedor común que non se especializa en cuestións de seguridade, a conexión entre unha corrección e unha vulnerabilidade potencial non é obvia (para moitas correccións, só unha auditoría separada permite comprender que están relacionadas coa seguridade. ). Segundo Linus, correspóndelle aos equipos de seguridade dos equipos responsables do mantemento dos paquetes do núcleo nas distribucións de Linux illar as posibles vulnerabilidades do fluxo xeral de parches.
Kees Cook considera que a única solución para manter o núcleo seguro a un custo razoable a longo prazo é que as empresas trasladen aos enxeñeiros implicados na portación de parches ás compilacións do núcleo local para traballar de forma colaborativa e coordinada para manter parches e vulnerabilidades no núcleo anterior. Na súa forma actual, moitos fabricantes non usan a versión máis recente do núcleo nos seus produtos e correccións de backport por si mesmos, é dicir. resulta que enxeñeiros de distintas empresas duplican o traballo entre si, resolvendo o mesmo problema.
Por exemplo, se 10 empresas, cada unha cun enxeñeiro que respalda as mesmas correccións, redirixen a eses enxeñeiros para que corrixan erros cara arriba, entón, en lugar de trasladar unha corrección, poderían corrixir 10 erros diferentes para o ben común ou unirse á revisión dos cambios propostos. evitar que se inclúa código de erros no núcleo. Tamén se poderían dedicar recursos á creación de novas ferramentas de proba e análise de código, que permitirían identificar, nunha fase inicial, automaticamente as clases típicas de erros que aparecen unha e outra vez.
Kees Cook tamén suxire un uso máis activo das probas automatizadas e fuzzing directamente no proceso de desenvolvemento básico, o uso de sistemas de integración continua e o abandono da xestión arcaica do desenvolvemento por correo electrónico. Actualmente, as probas eficaces vense obstaculizadas polo feito de que os principais procesos de proba están separados do desenvolvemento e ocorren despois da formación de lanzamentos. Keys tamén recomenda usar linguaxes máis seguras, como Rust, para reducir erros.
Fonte: opennet.ru