Kees Cook, eardere kernel.org CSO en lieder fan it Ubuntu Security Team, dy't no wurket foar Google om Android en ChromeOS te befeiligjen, spruts soargen út oer it hjoeddeistige proses fan it reparearjen fan bugs yn 'e stabile tûken fan' e kernel. Elke wike binne sa'n hûndert fixes opnommen yn stabile tûken, en nei it sluten fan it finster foar it akseptearjen fan wizigingen foar de folgjende release, komt it tûzen oan (ûnderhâlders hâlde reparaasjes oant it finster is sluten, en nei de formaasje fan "-rc1" se publisearje de sammele op ien kear), wat te folle is en in protte arbeid fereasket foar ûnderhâldsprodukten basearre op de Linux-kernel.
Neffens Keys wurdt it proses fan wurkjen mei flaters yn 'e kernel net genôch omtinken jûn en de kernel mist op syn minst 100 ekstra ûntwikkelders foar koördinearre wurk yn dit gebiet. De kearnkernel-ûntwikkelders reparearje bugs op in reguliere basis, mar d'r is gjin garânsje dat dizze fixes sille wurde porteare nei kernelfarianten brûkt troch tredden. Brûkers fan ferskate produkten basearre op de Linux kernel hawwe ek gjin manier om te kontrolearjen hokker bugs wurde reparearre en hokker kernel wurdt brûkt yn harren apparaten. Ferkeapers binne úteinlik ferantwurdlik foar de feiligens fan har produkten, mar mei in heul hege patchingskoers yn 'e stabile kernel-tûken, waarden se konfrontearre mei in kar tusken backporting fan alle patches, selektyf portearjen fan de wichtichste, of negearje alle patches.
De optimale oplossing soe wêze om allinich de wichtichste reparaasjes en kwetsberens te migrearjen, mar it isolearjen fan sokke flaters fan 'e algemiene stream is it haadprobleem. De measte problemen dy't opdûke binne troch it brûken fan 'e C-taal, dy't grutte soarch freget by it omgean mei ûnthâld en oanwizers. Om saken slimmer te meitsjen, wurde in protte potinsjele kwetsberensfixes net foarsjoen fan CVE-identifikaasjes, of ûntfange sa'n identifier in skoft nei't de patch is publisearre. Under sokke omstannichheden is it heul lestich foar fabrikanten om lytse reparaasjes te skieden fan grutte feiligensproblemen. Neffens statistiken binne mear as 40% fan kwetsberens fêst foardat in CVE wurdt tawiisd, en de gemiddelde fertraging tusken de frijlitting fan in patch en de tawizing fan in CVE is trije moannen (dat wol sizze, earst wurdt de patch as in mienskiplik waarnommen bug, mar pas nei in pear moannen wurdt it dúdlik dat de kwetsberens reparearre is).
As gefolch, sûnder in aparte tûke te hawwen mei fixes foar kwetsberens en sûnder ynformaasje te ûntfangen oer de befeiligingsferbining fan in bepaald probleem, wurde fabrikanten fan produkten basearre op 'e Linux-kernel oerlitten om kontinu alle fixes oer te bringen fan frisse stabile tûken. Mar dit wurk freget in soad arbeid en komt tsjin ferset yn bedriuwen troch eangst foar regressive feroarings dy't de normale wurking fan it produkt kinne fersteure.
Tink derom dat, neffens Linus Torvalds, alle flaters wichtich binne en kwetsberens moatte net skieden wurde fan oare soarten flaters en wurde tawiisd oan in aparte kategory mei hegere prioriteit. Dizze miening wurdt ferklearre troch it feit dat foar in gewoane ûntwikkelder dy't net spesjalisearre is yn feiligensproblemen, de ferbining tusken in fix en in potinsjele kwetsberens net dúdlik is (foar in protte reparaasjes lit allinich in aparte kontrôle jo begripe dat se relatearje oan feiligens ). Neffens Linus is it oan de befeiligingsteams op 'e teams dy't ferantwurdlik binne foar it behâld fan kernelpakketten op Linux-distribúsjes om potinsjele kwetsberens te isolearjen fan 'e algemiene patchstream.
Kees Cook is fan betinken dat de iennichste oplossing om de kernel feilich te hâlden op in ridlike lange termyn kosten is foar bedriuwen om de yngenieurs dy't belutsen binne by it portearjen fan patches nei lokale kernel builds te ferpleatsen om gearwurkjend en koördinearje te wurkjen om patches en kwetsberens yn 'e streamopkearn te behâlden. Yn syn hjoeddeistige foarm brûke in protte fabrikanten net de lêste kernelferzje yn har produkten en backport-fixes op har eigen, d.w.s. it docht bliken dat yngenieurs yn ferskate bedriuwen inoars wurk duplisearje en itselde probleem oplosse.
Bygelyks, as 10 bedriuwen, elk mei ien yngenieur dy't deselde reparaasjes stipet, dizze yngenieurs omliede om bugs streamop te reparearjen, ynstee fan in inkele reparaasje te portearjen, kinne se 10 ferskillende bugs reparearje foar it mienskiplik belang of meidwaan oan 'e resinsje fan foarstelde wizigingen. en foarkomme dat buggy-koade yn 'e kernel wurdt opnaam. Boarnen kinne ek wijd wurde oan it meitsjen fan nije ark foar testen en koade-analyze, wêrtroch yn in ier stadium automatysk typyske klassen fan flaters kinne identifisearje dy't hieltyd wer opkomme.
Kees Cook suggerearret ek mear aktyf gebrûk fan automatisearre en fuzzing testen direkt yn it kearnûntwikkelingsproses, it brûken fan trochgeande yntegraasjesystemen en it ferlitten fan argaysk ûntwikkelingsbehear fia e-post. Op it stuit wurdt effektive testen hindere troch it feit dat de wichtichste testprosessen wurde skieden fan ûntwikkeling en foarkomme nei de formaasje fan releases. Toetsen ek oan te rieden om feiliger talen te brûken, lykas Rust, om bugs te ferminderjen.
Boarne: opennet.ru