Kees Cook a hibajavítások tekintetében jobb munkaszervezést kér a Linuxon

Kees főz Készítek egy blogbejegyzést, amelyben aggodalmát fejezte ki a hibajavítási folyamattal kapcsolatban folyamatban van a Linux kernel stabil ágaiban, és ez az említse meg, hogy hétről hétre körülbelül száz korrekció szerepel stabil ágakon, ami túl sok és sok erőfeszítést igényel a Linux kernel-alapú termékek karbantartásához.

Kees szerint, a rendszermag hibakezelési folyamata megkerülve és a kernelből legalább 100 további fejlesztő hiányzik hogy összehangoltan dolgozzanak ezen a területen. Amellett, hogy megemlíti, hogy a nagy kernelfejlesztők rendszeresen javítják a hibákat, de nincs garancia arra, hogy ezek a javítások átkerülnek harmadik féltől származó kernelváltozatokba.

Ennek során megemlíti, hogy a különböző Linux-kernel-alapú termékek felhasználói sem tudják ellenőrizni, hogy mely hibákat javították, és mely kernelt használják az eszközeiken. Végső soron a szállítók felelősek termékeik biztonságáért, de a stabil kernelágakon tapasztalt javítások nagyon magas arányával szemben az volt a választásuk, hogy az összes javítást áthelyezik, a legfontosabbakat szelektíven áttelepítik, vagy figyelmen kívül hagyják az összes javítást. .

Az upstream kernelfejlesztők kijavíthatják a hibákat, de nincs ellenőrzésük arra vonatkozóan, hogy a downstream gyártó mit választ a termékei közé. A végfelhasználók megválaszthatják termékeiket, de általában nem tudják szabályozni, hogy mely hibákat javították ki, vagy melyik kernelt használták (ez önmagában is probléma). Végső soron a gyártók felelősek termékeik biztonságáért.

Kees főz azt javasolja, hogy az optimális megoldás csak a legfontosabb javítások és biztonsági rések átvitele lenne, de a fő probléma az, hogy ezeket a hibákat el kell különíteni az általános folyamattól, mivel a felmerülő problémák nagy része a C nyelv használatának következménye, amely nagy odafigyelést igényel a memóriával és a mutatókkal való munkavégzés során.

A helyzetet súlyosbítja, hogy számos potenciális sebezhetőségi javítást nem jelölnek meg CVE -azonosítókkal, vagy nem kapnak CVE -azonosítót egy ideig a javítás kiadása után.

Ilyen környezetben a gyártóknak nagyon nehéz elválasztaniuk a kisebb javításokat a fontos biztonsági problémáktól. A statisztikák szerint a sebezhetőségek több mint 40% -át eltávolítják a CVE kiosztása előtt, és átlagosan három hónap a javítás kiadása és a CVE hozzárendelése közötti késés (vagyis az elején gyakori hibaként érzékeli a megoldást,

Ennek eredményeként nem rendelkezik külön ággal a biztonsági rések javításával és nem kap információt a kapcsolatról az adott probléma biztonságával, a Linux kernel-alapú termékek gyártóinak folyamatosan át kell vinniük az összes javítást az új stabil ágak közül. Ez a munka azonban munkaigényes, és ellenáll a vállalatoknak a regresszív változásoktól való félelmek miatt, amelyek megzavarhatják a termék normál működését.

Keys Cook úgy véli, hogy az egyetlen megoldás a kernel hosszú távú ésszerű áron történő biztonságának megőrzése érdekében a patch mérnökök áthelyezése őrült kernelépítésekhezl Összehangoltan együtt dolgozni javítások és sebezhetőségek fenntartása az upstream kernelben. Jelenleg sok gyártó nem használja önmagában a legújabb kernelverziókat termékeiben és a hátsó port javításaiban, ami azt jelenti, hogy a különböző vállalatok mérnökei megismétlik egymás munkáját, megoldva ugyanazt a problémát.

Például, ha 10 vállalat, amelyek mindegyikének mérnöke ugyanazokat a javításokat támogatja, átirányítja ezeket a mérnököket a hibák kijavítására, ahelyett, hogy egy javítást migrálna, akkor 10 különböző hibát javíthatnak az általános előnyök érdekében, vagy összegyűlhetnek a hibák felülvizsgálatára. . És kerülje a hibás kódot a kernelbe. Az erőforrások felhasználhatók új kódelemző és tesztelő eszközök létrehozására is, amelyek korai szakaszban automatikusan észlelik az újra és újra előforduló tipikus hibaosztályokat.

Keys Cook javasolja továbbá az automatizált tesztelés és fuzzing aktívabb alkalmazását közvetlenül a kernelfejlesztési folyamatban, használjon folyamatos integrációs rendszereket, és hagyja abba az archaikus fejlesztési irányítást e-mailben.

forrás: https://security.googleblog.com


Legyen Ön az első hozzászóló

Hagyja megjegyzését

E-mail címed nem kerül nyilvánosságra. Kötelező mezők vannak jelölve *

*

*

  1. Az adatokért felelős: Miguel Ángel Gatón
  2. Az adatok célja: A SPAM ellenőrzése, a megjegyzések kezelése.
  3. Legitimáció: Az Ön beleegyezése
  4. Az adatok közlése: Az adatokat csak jogi kötelezettség alapján továbbítjuk harmadik felekkel.
  5. Adattárolás: Az Occentus Networks (EU) által üzemeltetett adatbázis
  6. Jogok: Bármikor korlátozhatja, helyreállíthatja és törölheti adatait.