Keesas virėjas Kuriu tinklaraščio įrašą, kuriame išreiškė susirūpinimą dėl klaidų taisymo proceso vyksta stabiliose „Linux“ branduolio šakose ir yra paminėti, kad kiekvieną savaitę įtraukiama apie šimtą taisymų stabilių šakų, o tai yra per daug ir reikalauja daug pastangų išlaikyti „Linux“ branduolio pagrindu pagamintus produktus.
Pasak Keeso, branduolio klaidų tvarkymo procesas apeinamas ir branduolyje trūksta mažiausiai 100 papildomų kūrėjų dirbti koordinuotai šioje srityje. Be to, kad paminėti, kad pagrindiniai branduolio kūrėjai reguliariai taiso klaidas, tačiau nėra garantijos, kad šie pataisymai bus perkelti į trečiųjų šalių branduolio variantus.
Tai darydamas jis pamini, kad įvairių „Linux“ branduolio pagrindu pagamintų produktų vartotojai taip pat neturi galimybės kontroliuoti, kurios klaidos yra ištaisytos ir kuris branduolys naudojamas jų įrenginiuose. Galiausiai pardavėjai yra atsakingi už savo produktų saugumą, tačiau susidūrę su labai dideliu pataisų skaičiumi ant stabilių branduolio šakų, jie turėjo pasirinkti perkelti visus pleistrus, pasirinktinai perkelti svarbiausius arba nepaisyti visų pataisų. .
Pradinio branduolio kūrėjai gali ištaisyti klaidas, tačiau jie nekontroliuoja to, ką tolesnis tiekėjas nusprendžia įtraukti į savo produktus. Galutiniai vartotojai gali pasirinkti savo produktus, tačiau jie paprastai nekontroliuoja, kurios klaidos yra ištaisytos ar koks branduolys yra naudojamas (pati problema). Galiausiai pardavėjai yra atsakingi už savo produktų branduolių saugumą.
Keesas virėjas siūlo, kad optimalus sprendimas būtų perduoti tik svarbiausius pataisymus ir pažeidžiamumus, tačiau pagrindinė problema yra atskirti šias klaidas nuo bendro srauto, nes dauguma iškylančių problemų yra C kalbos vartojimo pasekmė, kuri reikalauja daug atsargumo dirbant su atmintimi ir rodyklėmis.
Dar blogiau, daugelis galimų pažeidžiamumo pataisų nėra pažymėtos CVE identifikatoriais arba negauna CVE identifikatoriaus praėjus kuriam laikui po pataisos išleidimo.
Tokioje aplinkoje gamintojams labai sunku atskirti smulkius pataisymus nuo pagrindinių saugumo problemų. Remiantis statistika, daugiau nei 40% pažeidžiamumų pašalinami prieš CVE priskyrimą, o vidutiniškai vėlavimas tarp pataisos išleidimo ir CVE priskyrimo yra trys mėnesiai (tai yra, pradžioje sprendimas suvokiamas kaip dažna klaida,
Kaip rezultatas, neturėti atskiros šakos su pažeidimų taisymais ir negauna informacijos apie ryšį su tos ar kitos problemos saugumu, „Linux“ branduolio pagrindu pagamintų produktų gamintojai turi nuolat perduoti visus pataisymus naujų stabilių šakų. Tačiau šis darbas reikalauja daug darbo ir susiduria su įmonių pasipriešinimu, nes baiminamasi dėl regresyvių pokyčių, galinčių sutrikdyti normalų gaminio veikimą.
Raktai Kuko mano, kad vienintelis sprendimas, leidžiantis branduolį apsaugoti už priimtiną kainą ilgainiui, yra perkelti pataisų inžinierius į beprotiškus branduolio kūrimusl Dirbti kartu koordinuotai išlaikyti pataisas ir pažeidžiamumą branduolio aukščiau. Dabartinėje situacijoje daugelis pardavėjų savo produktuose ir „backport“ pataisose nenaudoja naujausių branduolio versijų, tai yra, paaiškėja, kad skirtingų kompanijų inžinieriai dubliuoja vienas kito darbą ir išsprendžia tą pačią problemą.
Pvz., Jei 10 įmonių, kurių kiekviena turi inžinierių, palaikančią tuos pačius pataisymus, nukreipia šiuos inžinierius, kad ištaisytų klaidas, o ne perkeltų vieną pataisą, galėtų ištaisyti 10 skirtingų klaidų bendrai naudai arba susiburtų peržiūrėti klaidų. Siūlomi pakeitimai . Ir venkite klaidingo kodo įtraukimo į branduolį. Ištekliai taip pat galėtų būti naudojami kuriant naujas kodo analizės ir testavimo priemones, kurios ankstyvame etape automatiškai aptiktų tipiškas klaidų klases, kurios atsiranda vis iš naujo.
Raktai Kuko taip pat siūlo aktyviau naudoti automatizuotą testavimą ir neryškumą tiesiogiai branduolio kūrimo procese, naudokite nuolatinės integracijos sistemas ir atsisakykite archajiško kūrimo valdymo el. paštu.
Fuente: https://security.googleblog.com