Checkpoint cége A Safe-Linking védelmi mechanizmus, amely megnehezíti a kihasználások létrehozását, amelyek manipulálják a malloc hívás során allokált pufferek címeinek meghatározását vagy megváltoztatását. A Safe-Linking nem zárja ki teljesen a sebezhetőségek kihasználásának lehetőségét, de minimális költségekkel jelentősen megnehezíti bizonyos kategóriájú kihasználások létrehozását, mivel a kihasználható puffertúlcsordulás mellett további sebezhetőséget is meg kell találni, amely információszivárgást idéz elő a memóriahalom elhelyezéséről.
A Safe-Linking megvalósításával készült javítások elérhetők Glibc (ptmalloc), uClibc-NG (dlmalloc), gperftools (tcmalloc) és Google TCMalloc számára, valamint a Chromium védelem frissítésére is javasolták.
A Chromiumba 2012 óta beépítve van egy megoldás ugyanarra a problémára, a MaskPtr védelmi technika, de a Checkpoint megoldása magasabb teljesítményt mutat.
A javasolt javításokat már jóváhagyták az augusztusi kiadásra és a Safe-Linking alkalmazása alapértelmezés szerint be fog kerülni. Az uClibc-NG a Safe-Linkinget az 1.0.33 verzióba fogja integrálni, és alapértelmezés szerint be van kapcsolva. A gperftools (régi tcmalloc) változtatása , de a jövőbeli kiadások egyikében opcióként javasolják.
Fejlesztők (új tcmalloc) elutasította a befogadást , hivatkozva a jelentős teljesítménycsökkenésre és a rendszeres teszteléshez szükséges kiterjesztett tesztek hozzáadására, hogy biztosítsák a megfelelő működést. A Checkpoint mérnökeinek tesztelése kimutatta, hogy a Safe-Linking módszer nem eredményez plusz memóriahasználatot, és a memóriahalommal kapcsolatos műveletek teljesítménye átlagosan csak 0,02%-kal csökken, a legrosszabb esetben pedig 1,5%-kal (összehasonlításul a Chromium által alkalmazott módszer költségeit „2%-nál kevesebbnek” értékelik). A Safe-Linking engedélyezése
minden free() hívásnál 2-3 további assembler utasítást és malloc() hívásnál 3-4 utasítást igényel. Az inicializáló és véletlenszám-generáló fázisok futtatására nincs szükség.
A Safe-Linking nemcsak a különböző halom (heap) megvalósítások biztonságának növelésére alkalmazható, hanem integritásellenőrző eszközök hozzáadására is bármely adatszerkezethez, ahol egyirányú mutatók listáit helyezik el közvetlenül a pufferek mellett. A módszer nagyon egyszerűen megvalósítható, és csupán egy makró hozzáadását igényli, valamint annak alkalmazását a következő blokkra mutató mutatókra a kódban (például a Glibc-hez) mindössze néhány sor a kódban). A módszer a következő módosításokra korlátozódik:
#define PROTECT_PTR(pos, ptr) \
((__typeof (ptr)) ((((size_t) pos) >> 12) ^ ((size_t) ptr)))
#define REVEAL_PTR(ptr) PROTECT_PTR (&ptr, ptr)
— nextp = p->fd;
+ nextp = REVEAL_PTR (p->fd);
…
A módszer lényege, hogy véletlenszerű adatokat használ az ASLR (Address Space Layout Randomization) címkézési mechanizmusából (mmap_base) az olyan egyirányú listák védelmére, mint a Fast-Bins és a TCache. A következő elem mutatójának értéke előtt maszkolás és memóriaoldalra való igazítás ellenőrzése történik. A mutató helyébe a „(L >> PAGE_SHIFT) XOR (P)” művelet eredménye kerül, ahol P a mutató értéke, L pedig a memóriahely, ahol a mutató található.
A rendszerben történő használatkor (Address Space Layout Randomization) a halom alapcímével egybeeső L bitjei véletlenszerű értékeket tartalmaznak, amelyek kulcsként szolgálnak P kódolásához (12 bites elmozdítással nyerik ki 4096 bájtos oldalak esetén). Az ilyen manipuláció csökkenti a mutató elkapásának kockázatát egy exploitban, mivel a mutató nem tárolódik a kezdeti formájában, és ahhoz, hogy azt helyettesíteni lehessen, tudni kell a halom elhelyezkedésére vonatkozó információkat. Ezenkívül a patch kódjában egy további blokk igazítási ellenőrzés is szerepel, amely megakadályozza a támadókat abban, hogy a mutatót nem igazított értékre cseréljék, és ismerniük kell, hány bitet használtak az igazításhoz; ez a 64 bites rendszereken további 15-ből 16 támadási kísérlet blokkolását teszi lehetővé, figyelembe véve az igazítást.
A módszer hatékony a mutatók részleges felülírására (az alsó bájtok megváltoztatása), a mutatók teljes újraírására (a támadó kódjára irányítás) és az lista pozíciójának nem igazított címen történő megváltoztatására irányuló támadásokkal szemben. Példaként bemutatják, hogy a Safe-Linking alkalmazása a malloc-ban megakadályozná a nemrégiben ugyanazok a kutatók a sebezhetőségekről a Philips Hue Bridge intelligens világításában, amelyet a pufferméret túllépése okoz, és lehetővé teszi az eszköz feletti irányítást.
Forrás: opennet.ru
