Ellenőrző pont (az IT biztonsági megoldások globális szolgáltatója) kiadta néhány napja a bevezetést a biztonsági mechanizmus "Biztonságos összekapcsolás", hogy megnehezíti a kihasználások létrehozását amelyek manipulálják a mutatók definiálását vagy megváltoztatását allokált pufferekre, amikor malloc hívást indítanak.
Az új «Safe-Linking» mechanizmus nem zárja le teljesen a sebezhetőségek kihasználásának lehetőségét, de minimális rezsivel bonyolítja a kihasználások bizonyos kategóriáinak létrehozásátMivel a kihasznált puffer túlcsordulás mellett meg kell találni egy másik biztonsági rést, amely információt szolgáltat a halom helyéről a memóriában.
Készültek a Safe-Linking implementációs javítások a Glibc (ptmalloc), az uClibc-NG (dlmalloc), a gperftools (tcmalloc) és a Google TCMalloc számára, valamint javaslatot tettek a Chromium (2012 óta a Chromium) védelmének korszerűsítésére. ugyanaz a probléma) MaskPtr védelmi technika, de a Checkpoint megoldása jobb teljesítményt mutat).
A javasolt javításokat a Glibc 3.32 augusztusi kiadásában már engedélyezték a szállításra, és a Safe-Linking alapértelmezés szerint engedélyezve lesz. Az uClibc-NG alkalmazásban a biztonságos kapcsolat támogatása az 1.0.33 verzióba került, és alapértelmezés szerint engedélyezve van. A gperftools (régi tcmalloc) módosításait elfogadjuk, de opcióként felajánljuk egy későbbi kiadásban.
A TCMalloc fejlesztői nem voltak hajlandók elfogadni a változást, cnagy teljesítményű sikerrel és fejlett tesztek hozzáadásával, hogy rendszeresen ellenőrizzük, hogy minden megfelelően működik-e.
A vizsgálatokat elvégezte Az ellenőrző pont mérnökei kimutatták, hogy a Safe-Linking módszer nem vezet további memóriafelhasználáshoz és a kupacműveletek teljesítése átlagosan csak 0.02% -kal, a legrosszabb esetben 1.5% -kal csökken
A Safe-Linking engedélyezése 2-3 további összeállító utasítás végrehajtásához vezet minden egyes free to híváshoz () és 3-4 utasításhoz a malloc () hívásakor. Az inicializálás kezdete és a véletlenszerű érték generálása nem szükséges.
A Safe-Linking nemcsak a biztonság növelése érdekében használható különféle halom megvalósítások, sino az integritás-ellenőrzések hozzáadásához bármilyen adatstruktúrához amely a pufferek mellett elhelyezett, egyenként összekapcsolt mutatók listáját használja.
A módszer végrehajtása nagyon egyszerű, és csak makró hozzáadását igényli és alkalmazza a kód következő blokkjára mutató mutatókra (például a Glibc esetében csak néhány sort változtatnak meg a kódban).
A módszer lényege, hogy az ASLR cím véletlenszerűsítési mechanizmusból (mmap_base) származó véletlenszerű adatokat alkalmazzuk az egyenként összekapcsolt listák, például a Fast-Bins és a TCache védelmére. Mielőtt a mutató értékét a lista következő elemére alkalmazná, a maszk átalakítását és az igazítást ellenőrizni kell a memóriaoldal szélén. A mutató helyére az "(L >> PAGE_SHIFT) XOR (P)" művelet eredménye kerül, ahol P a mutató értéke, L pedig a memóriában az a hely, ahol ezt a mutatót tárolják.
Amikor az ASLR (Address Space Layout Randomization) rendszerben használják, a halom alapcímével rendelkező L bitek egy része véletlenszerű értékeket tartalmaz, amelyeket kulcsként használnak a P kódolásához (12 bit eltolásos művelettel vonják ki őket). 4096 bájtos oldalakhoz).
Ilyen manipuláció csökkenti annak kockázatát, hogy egy mutatót kihasználjon, Mivel a mutató nem az eredeti formájában van tárolva, és annak cseréjéhez tudnia kell a kupac helyére vonatkozó információkat.
A módszer hatékonyan védi a részleges mutató újradefiniálást alkalmazó támadásokat (alacsony bájteltolás), a mutatók teljes átírása (átirányítás a támadó kódjára) és a lista áthelyezése nem igazított irányba.
Példaként bemutatjuk, hogy a biztonságos összekapcsolás malloc-ban megakadályozná a CVE-2020-6007 biztonsági rés kihasználását, amelyet ugyanazok a kutatók nemrég fedeztek fel a Philips Hue Bridge intelligens háttérvilágításában, amelyet a puffer túlcsordulása okozott, és lehetővé tette az eszköz.
forrás: https://research.checkpoint.com