Kees Cook Teen blogipostituse, milles on tekitanud muret vigade parandamise protsessi pärast jätkub Linuxi kerneli stabiilsetes harudes ja see on see mainige, et iga nädal lisatakse umbes sada parandust stabiilsetel harudel, mis on liiga palju ja nõuab palju pingutusi Linuxi kernelipõhiste toodete hooldamiseks.
Keesi sõnul, tuumavigade käsitlemise protsess möödub ja kernelil puudub vähemalt 100 täiendavat arendajat töötada selles valdkonnas kooskõlastatult. Lisaks mainimisele, et suured tuumaarendajad parandavad regulaarselt vigu, kuid pole garantiid, et need parandused kanduvad üle ka kolmanda osapoole kerneli variantidele.
Seda tehes mainib ta, et ka erinevate Linuxi kernelipõhiste toodete kasutajatel puudub võimalus kontrollida, millised vead on parandatud ja millist tuuma nende seadmetes kasutatakse. Lõppkokkuvõttes vastutavad müüjad oma toodete turvalisuse eest, kuid silmitsi stabiilsete tuumaharude plaastrite väga suure määraga, seisid nad silmitsi valikuga, kas migreerida kõik plaastrid, migreerida valikuliselt kõige olulisemad või ignoreerida kõiki plaastreid. .
Ülesvoolu kerneli arendajad saavad vigu parandada, kuid neil puudub kontroll selle üle, mida allkasutaja otsustab oma toodetesse lisada. Lõppkasutajad saavad oma tooteid valida, kuid üldiselt ei saa nad kontrollida, millised vead on parandatud või millist tuuma kasutatakse (probleem iseenesest). Lõppkokkuvõttes vastutavad müüjad oma tootesüdamike ohutuse eest.
Kees Cook soovitab, et optimaalne lahendus oleks ainult kõige olulisemate paranduste ja nõrkade kohtade ülekandmine, kuid põhiprobleem on nende vigade eraldamine üldisest voolust, kuna enamik esilekerkivaid probleeme on C -keele kasutamise tagajärg, mis nõuab mälu ja viitadega töötamisel palju hoolt.
Asja teeb veelgi hullemaks, et paljud võimalikud haavatavuse parandused ei ole märgistatud CVE identifikaatoritega või ei saa mõnda aega pärast plaastri vabastamist CVE identifikaatorit.
Sellises keskkonnas on tootjatel väga raske eraldada väiksemaid parandusi suurematest turvaprobleemidest. Statistika kohaselt eemaldatakse enne CVE määramist üle 40% haavatavustest ja keskmiselt on viivitus paranduse väljalaske ja CVE määramise vahel kolm kuud (see tähendab, et alguses tajub lahendus tavalise veana,
Selle tulemusena puudub eraldi haru, kus on parandused haavatavustele ja ei saa teavet selle või selle probleemi turvalisusega seotud ühenduse kohta, Linuxi kernelipõhiste toodete tootjad peavad pidevalt kõik parandused üle kandma uutest stabiilsetest harudest. Kuid see töö on töömahukas ja seisab ettevõtetes vastupanu tõttu, kuna kardetakse regressiivseid muutusi, mis võivad häirida toote normaalset toimimist.
Keys Cook usub, et ainus lahendus kerneli turvaliseks hoidmiseks mõistliku hinnaga pikas perspektiivis on plaastriinseneride kolimine pööraste kerneliehitustenil teha koostööd koordineeritult plaastrite ja haavatavuste säilitamiseks ülesvoolu kernelis. Praegusel kujul ei kasuta paljud müüjad oma toodetes ja tagapordi parandustes omaenda uusimaid kerneli versioone, mis tähendab, et erinevate ettevõtete insenerid kopeerivad üksteise tööd, lahendades sama probleemi.
Näiteks kui 10 ettevõtet, millest igaühel on samu parandusi toetav insener, suunavad need insenerid vead parandama ülesvoolu, selle asemel, et ühe paranduse üle viia, võiksid nad üldise kasu nimel parandada 10 erinevat viga või tulla kokku vead üle vaatama. . Ja vältige lollaka koodi lisamist tuuma. Ressursse saab kasutada ka uute koodianalüüsi- ja testimisvahendite loomiseks, mis tuvastaksid varases staadiumis automaatselt tüüpilised veaklassid, mis ikka ja jälle esile kerkivad.
Keys Cook teeb samuti ettepaneku kasutada aktiivsemalt automatiseeritud testimist ja hägustamist otse kerneli arendusprotsessis, kasutage pidevaid integratsioonisüsteeme ja loobuge arhailisest arendusjuhtimisest e-posti teel.
allikas: https://security.googleblog.com