Kees vaří Vytvářím blogový příspěvek, ve kterém vyvolal obavy z procesu opravy chyb pokračuje ve stabilních větvích jádra Linuxu a je to zmínit, že týden co týden je zahrnuto asi sto oprav na stabilních větvích, což je příliš mnoho a vyžaduje mnoho úsilí k údržbě produktů založených na linuxovém jádře.
Podle Keese, proces zpracování chyb jádra je vynechán a jádru chybí nejméně 100 dalších vývojářů v této oblasti koordinovaně pracovat. Kromě toho, že hlavní vývojáři jádra pravidelně opravují chyby, ale neexistuje žádná záruka, že se tyto opravy přenesou do variant jádra třetích stran.
Přitom uvádí, že uživatelé různých produktů založených na jádře Linuxu také nemají žádný způsob, jak kontrolovat, které chyby jsou opraveny a které jádro je na jejich zařízeních používáno. V konečném důsledku jsou dodavatelé zodpovědní za bezpečnost svých produktů, ale tváří v tvář velmi vysoké míře oprav na stabilních větvích jádra čelili možnosti migrace všech oprav, selektivní migrace těch nejdůležitějších nebo ignorování všech oprav. .
Vývojáři upstream jádra mohou opravit chyby, ale nemají žádnou kontrolu nad tím, co se následný dodavatel rozhodne začlenit do svých produktů. Koncoví uživatelé si mohou vybrat své produkty, ale obecně nemají žádnou kontrolu nad tím, které chyby jsou opraveny nebo které jádro je použito (problém sám o sobě). V konečném důsledku jsou prodejci zodpovědní za udržování jader svých produktů v bezpečí.
Kees vaří navrhuje, že optimálním řešením by bylo přenést pouze nejdůležitější opravy a chyby zabezpečení, ale hlavním problémem je oddělit tyto chyby od obecného toku, protože většina vznikajících problémů je důsledkem používání jazyka C, který vyžaduje hodně péče při práci s pamětí a ukazateli.
Aby toho nebylo málo, mnoho potenciálních oprav zranitelnosti není označeno identifikátory CVE nebo neobdrží identifikátor CVE nějakou dobu po vydání opravy.
V takovém prostředí je pro výrobce velmi obtížné oddělit drobné opravy od zásadních bezpečnostních problémů. Podle statistik je před přiřazením CVE odstraněno více než 40% zranitelností a průměrná prodleva mezi vydáním opravy a přiřazením CVE je tři měsíce (to znamená, že na začátku vnímá řešení jako běžnou chybu,
Jako výsledek, nemají samostatnou větev s opravami chyb zabezpečení a neobdržíte informace o spojení s bezpečností toho či onoho problému, výrobci produktů založených na linuxovém jádře musí průběžně přenášet všechny opravy nových stabilních poboček. Tato práce je však náročná na práci a čelí odporu společností kvůli obavám z regresivních změn, které by mohly narušit normální provoz produktu.
Klíče Cook domnívá se, že jediným řešením, jak dlouhodobě zajistit jádro za rozumnou cenu, je přemístit opraváře k šíleným stavbám jádraSpolupracovat koordinovaně udržovat záplaty a zranitelnosti v upstream jádře. Ve skutečnosti mnoho prodejců ve svých produktech nepoužívá nejnovější verze jádra a opravy backportu, což znamená, že inženýři z různých společností se navzájem duplikují a řeší stejný problém.
Pokud například 10 společností, z nichž každá má inženýra podporujícího stejné opravy, přesměruje tyto inženýry, aby opravili chyby proti proudu, místo migrace jedné opravy by mohly opravit 10 různých chyb za účelem celkového prospěchu nebo se spojit a zkontrolovat chyby. Navrhované změny . A vyvarujte se zahrnutí chybného kódu do jádra. Prostředky by také mohly být použity k vytvoření nových nástrojů pro analýzu a testování kódu, které by v počáteční fázi automaticky detekovaly typické třídy chyb, které se objevují znovu a znovu.
Klíče Cook také navrhuje aktivněji využívat automatizované testování a fuzzování přímo v procesu vývoje jádra používejte systémy kontinuální integrace a upusťte od archaické správy vývoje prostřednictvím e-mailu.
zdroj: https://security.googleblog.com