Kees Cook solicită o mai bună organizare a muncii pe Linux în ceea ce privește remedierea erorilor

Kees gătește Fac o postare pe blog în care a ridicat îngrijorări cu privire la procesul de remediere a erorilor în desfășurare în ramurile stabile ale nucleului Linux și este că menționăm că săptămână de săptămână sunt incluse aproximativ o sută de corecții pe ramuri stabile, ceea ce este prea mult și necesită mult efort pentru a menține produsele bazate pe nucleul Linux.

Potrivit lui Kees, procesul de tratare a erorilor kernelului este ocolit și nucleului îi lipsesc cel puțin 100 de dezvoltatori suplimentari să lucreze în mod coordonat în acest domeniu. În plus față de menționarea faptului că dezvoltatorii majori de kernel remediază în mod regulat erorile, dar nu există nicio garanție că aceste remedieri vor fi transferate la variantele de kernel terțe.

Procedând astfel, el menționează că utilizatorii diferitelor produse bazate pe nucleul Linux nu au nici o modalitate de a controla ce bug-uri sunt remediate și ce nucleu este utilizat pe dispozitivele lor. În cele din urmă, vânzătorii sunt responsabili pentru securitatea produselor lor, dar confruntați cu o rată foarte mare de patch-uri pe ramuri stabile de miez, au fost confruntați cu alegerea migrării tuturor patch-urilor, migrarea selectivă a celor mai importante sau ignorarea tuturor patch-urilor. .

Dezvoltatorii de kernel din amonte pot remedia erorile, dar nu au control asupra a ceea ce un furnizor din aval alege să includă în produsele lor. Utilizatorii finali își pot alege produsele, dar în general nu au niciun control asupra bug-urilor care sunt remediate sau asupra nucleului utilizat (o problemă în sine). În cele din urmă, vânzătorii sunt responsabili pentru păstrarea nucleelor ​​de produse în siguranță.

Kees gătește sugerează că soluția optimă ar fi transferarea doar a celor mai importante remedieri și vulnerabilități, dar principala problemă este separarea acestor erori de fluxul general, deoarece majoritatea problemelor emergente sunt o consecință a utilizării limbajului C, care necesită multă grijă atunci când se lucrează cu memorie și indicatori.

Pentru a înrăutăți lucrurile, multe remedieri potențiale ale vulnerabilității nu sunt etichetate cu identificatori CVE sau nu primesc un identificator CVE la ceva timp după lansarea patch-ului.

Într-un astfel de mediu, este foarte dificil pentru producători să separe remedierile minore de problemele majore de securitate. Conform statisticilor, peste 40% din vulnerabilități sunt eliminate înainte de atribuirea CVE și, în medie, întârzierea dintre o versiune de corecție și o atribuire CVE este de trei luni (adică, la început, o soluție percepe o greșeală obișnuită,

Ca urmare, neavând o ramură separată cu remedieri pentru vulnerabilități și să nu primească informații despre conexiunea cu securitatea acestei sau acelei probleme, producătorii de produse pe bază de nucleu Linux trebuie să transfere continuu toate remedierile a noilor ramuri stabile. Însă această lucrare necesită multă muncă și se confruntă cu rezistență din partea companiilor din cauza temerilor de schimbări regresive care ar putea perturba funcționarea normală a produsului.

Chei Cook consideră că singura soluție pentru a menține nucleul sigur la un cost rezonabil pe termen lung este mutarea inginerilor de patch-uri la construirea kernelului nebunSă lucrăm împreună într-un mod coordonat pentru a menține patch-urile și vulnerabilitățile în nucleul din amonte. În starea actuală, mulți furnizori nu folosesc cele mai recente versiuni de kernel în produsele lor și remediile de backport pe cont propriu, adică se dovedește că inginerii din diferite companii își duplică munca reciprocă, rezolvând aceeași problemă.

De exemplu, dacă 10 companii, fiecare cu un inginer care susține aceleași remedieri, redirecționează acești ingineri pentru a remedia erorile în amonte, în loc să migreze o remediere, ar putea remedia 10 erori diferite pentru beneficiul general sau s-ar putea reuni pentru a revizui erorile. . Și evitați să includeți codul buggy în kernel. Resursele ar putea fi, de asemenea, utilizate pentru a crea noi instrumente de analiză și testare a codului care ar detecta automat într-un stadiu incipient clasele tipice de erori care apar din nou și din nou.

Chei Cook propune, de asemenea, utilizarea mai activă a testării și fuzzingului automat direct în procesul de dezvoltare a nucleului, utilizați sisteme de integrare continuă și abandonați managementul arhaic al dezvoltării prin e-mail.

Fuente: https://security.googleblog.com


Fii primul care comenteaza

Lasă comentariul tău

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *

*

*

  1. Responsabil pentru date: Miguel Ángel Gatón
  2. Scopul datelor: Control SPAM, gestionarea comentariilor.
  3. Legitimare: consimțământul dvs.
  4. Comunicarea datelor: datele nu vor fi comunicate terților decât prin obligație legală.
  5. Stocarea datelor: bază de date găzduită de Occentus Networks (UE)
  6. Drepturi: în orice moment vă puteți limita, recupera și șterge informațiile.