A Chromium projekt fejlesztői 912 magas kockázatú és kritikus biztonsági rést azonosítottak a Chrome 2015 óta tartó stabil kiadásaiban, és arra a következtetésre jutottak, hogy ezek 70%-át a memória bizonytalansága okozta (hiba a C/C++ kód mutatóival való munka során). Ezeknek a problémáknak a felét (36.1%) a pufferhez való hozzáférés okozza a hozzá tartozó memória felszabadítása után (use-after-free).
A Chromium tervezésekor kezdetben az volt hogy előfordulhat, hogy hibák jelenhetnek meg a kódban, ezért nagy hangsúlyt fektettek a sandbox izoláció használatára, hogy korlátozzák a sebezhetőségek következményeit. Jelenleg ennek a technológiának a felhasználási lehetőségei elérték képességeik határát, és a további folyamatokba bontás az erőforrás-felhasználás szempontjából nem praktikus.
A kódbázis biztonságának megőrzése érdekében a Google kényszeríti a "“, amely szerint bármely hozzáadott kódnak legfeljebb kettőnek kell megfelelnie a három feltétel közül: érvényesítetlen bemeneti adatokkal való munkavégzés, nem biztonságos programozási nyelv (C/C++) használata és emelt szintű jogosultságokkal való futtatás. Ez a szabály azt jelenti, hogy a külső adatok feldolgozására szolgáló kódot vagy minimális jogosultságokra kell csökkenteni (elszigetelni), vagy biztonságos programozási nyelven kell megírni.
A kódbázis biztonságának további fokozása érdekében egy projektet indítottak, amely megakadályozza, hogy memóriahibák jelenjenek meg a kódbázisban. Három fő megközelítés létezik: C++ könyvtárak létrehozása a memória biztonságos működését szolgáló funkciókkal és a szemétgyűjtő hatókörének bővítése, hardveres védelmi mechanizmusok használatával (Memory Tagging Extension) és olyan nyelveken írható komponensek, amelyek biztosítják a biztonságos memóriával való munkát (Java, Kotlin, JavaScript, Rust, Swift).
A munka várhatóan két területre összpontosul:
- Jelentős változás a C++ fejlesztési folyamatban, ami nem zárja ki a teljesítményre gyakorolt negatív hatást (további határellenőrzések és szemétszállítás). A nyers mutatók helyett a típus használata javasolt , amely lehetővé teszi a kihasználható, utánhasználat nélküli hibák olyan összeomlásokká való csökkentését, amelyek nem jelentenek biztonsági fenyegetést anélkül, hogy észrevehető negatív hatással lenne a teljesítményre, a memóriafogyasztásra és a stabilitásra.
- A fordítás során memóriabiztonsági ellenőrzések elvégzésére tervezett nyelvek használata (kiküszöböli az ilyen ellenőrzésekben rejlő negatív hatást a teljesítményre a kód végrehajtása során, de többletköltségekhez vezet az új nyelvű kód és a programban lévő kód interakciójának megszervezéséhez. C++).
A memóriabiztos könyvtárak használata a legegyszerűbb, de kevésbé hatékony módszer. A kód átírása Rust nyelven a leghatékonyabb, de egyben nagyon költséges módszer.
Forrás: opennet.ru