Kees varí Robím blogový príspevok, v ktorom vyvolalo obavy v súvislosti s procesom opravy chýb prebieha v stabilných vetvách jadra Linuxu a je to tak spomenúť, že týždeň čo týždeň je zahrnutých asi sto opráv na stabilných vetvách, čo je príliš veľa a vyžaduje si to veľa úsilia na údržbu produktov založených na jadre Linuxu.
Podľa Keesa, bude proces spracovania chýb jadra obídený a jadru chýba najmenej 100 ďalších vývojárov v tejto oblasti koordinovane pracovať. Okrem zmienky o tom, že hlavní vývojári jadra pravidelne opravujú chyby, ale neexistuje žiadna záruka, že sa tieto opravy prenesú na varianty jadra tretích strán.
Pri tom spomína, že používatelia rôznych produktov založených na jadre Linuxu tiež nemajú žiadny spôsob, ako kontrolovať, ktoré chyby sú opravené a ktoré jadro sa používa na ich zariadeniach. V konečnom dôsledku sú za bezpečnosť svojich produktov zodpovední dodávatelia, ale vzhľadom na veľmi vysokú mieru opráv na stabilných vetvách jadra museli čeliť možnosti migrácie všetkých opráv, selektívnej migrácii tých najdôležitejších alebo ignorovaniu všetkých opráv. .
Vývojári upstream jadra môžu opravovať chyby, ale nemajú žiadnu kontrolu nad tým, čo sa následný dodávateľ rozhodne začleniť do svojich produktov. Koncoví užívatelia si môžu vyberať svoje produkty, ale spravidla nemajú žiadnu kontrolu nad tým, ktoré chyby sú opravené alebo aké jadro sa používa (problém sám o sebe). V konečnom dôsledku sú predajcovia zodpovední za bezpečnosť svojich jadier produktov.
Kees varí navrhuje, že optimálnym riešením by bol prenos iba najdôležitejších opráv a zraniteľností, ale hlavným problémom je oddeliť tieto chyby od všeobecného toku, pretože väčšina vznikajúcich problémov je dôsledkom používania jazyka C, ktorý si pri práci s pamäťou a ukazovateľmi vyžaduje veľkú starostlivosť.
Aby toho nebolo málo, mnoho potenciálnych opráv zraniteľností nie je označených identifikátormi CVE alebo neobdržia identifikátor CVE nejaký čas po vydaní opravy.
V takom prostredí je pre výrobcov veľmi ťažké oddeliť drobné opravy od veľkých bezpečnostných problémov. Podľa štatistík je pred priradením CVE odstránených viac ako 40% zraniteľností a v priemere je oneskorenie medzi vydaním opravy a priradením CVE tri mesiace (to znamená, že na začiatku vníma riešenie ako bežnú chybu. ,
Výsledkom je, nemajú samostatnú vetvu s opravami zraniteľností a nedostávať informácie o spojení s bezpečnosťou tohto alebo toho problému, Výrobcovia produktov založených na jadre Linux musia nepretržite prenášať všetky opravy nových stabilných pobočiek. Táto práca je však náročná na prácu a v spoločnostiach čelí odporu kvôli obavám z regresívnych zmien, ktoré by mohli narušiť normálnu prevádzku produktu.
Kľúče Cook je presvedčený, že jediným riešením, ako dlhodobo udržať jadro v bezpečí za rozumnú cenu, je premiestniť inžinierov opráv k šialeným stavbám jadraSpolupracovať koordinovane na udržanie opráv a zraniteľností v upstream jadre. V súčasnej dobe mnoho dodávateľov nepoužíva vo svojich produktoch najnovšie verzie jadra a opravy backportu, čo znamená, že inžinieri z rôznych spoločností si navzájom duplikujú prácu a riešia rovnaký problém.
Ak napríklad 10 spoločností, z ktorých každá má inžiniera podporujúceho rovnaké opravy, presmeruje týchto inžinierov na opravu chýb v pôvodnom poradí, namiesto migrácie jednej opravy môžu opraviť 10 rôznych chýb z celkového prospechu alebo sa spoločne pokúsiť chyby skontrolovať. . A vyhnite sa zahrnutiu buggy kódu do jadra. Prostriedky je možné použiť aj na vytvorenie nových nástrojov na analýzu a testovanie kódu, ktoré by v počiatočnom štádiu automaticky detegovali typické triedy chýb, ktoré sa objavujú znova a znova.
Kľúče Cook taktiež navrhuje využívať aktívnejšie automatizované testovanie a fuzzovanie priamo v procese vývoja jadra používajte systémy nepretržitej integrácie a upustite od archaického riadenia vývoja prostredníctvom e-mailu.
Fuente: https://security.googleblog.com