Checkpoint ehdotti Safe-Linking-suojaustekniikkaa, mikä vaikeuttaa haavoittuvuuksien hyödyntämistä

Checkpoint Company esitetty Safe-Linking-suojausmekanismi, joka vaikeuttaa hyväksikäyttötoimintojen luomista, jotka manipuloivat malloc-kutsua suoritettaessa varattujen puskureiden osoittimien määrittelyä tai muokkaamista. Safe-Linking ei estä täysin mahdollisuutta hyödyntää haavoittuvuuksia, mutta minimaalisella ylikuormituksella se vaikeuttaa merkittävästi tiettyjen hyväksikäyttöluokkien luomista, koska hyödynnettävän puskurin ylivuodon lisäksi on löydettävä toinen haavoittuvuus, joka aiheuttaa tietojen vuotamisen kasan sijoittaminen muistiin.

Safe-Linkingin toteuttavat korjaustiedostot on valmistettu Glibc:lle (ptmalloc), uClibc-NG:lle (dlmalloc), gperftoolsille (tcmalloc) ja Google TCMallocille, ja niitä ehdotetaan myös suojauksen päivittämiseen Chromiumissa (in
Vuodesta 2012 lähtien Chromium on jo rakentanut MaskPtr-suojaustekniikan, jonka tarkoituksena on ratkaista sama ongelma, mutta Checkpointin ratkaisu osoittaa parempaa suorituskykyä).
Ehdotetut korjaustiedostot on jo hyväksytty toimitettavaksi elokuun julkaisussa Glibc 3.32 ja Safe-Linking on oletusarvoisesti käytössä. uClibc-NG tukee Safe-Linkingä astui sisään sisältyy julkaisuun 1.0.33 ja se on oletuksena käytössä. Muutokset gperftoolsissa (vanha tcmalloc) hyväksytty, mutta se tarjotaan vaihtoehtona tulevassa julkaisussa.

Kehittäjät TCMalloc (uusi tcmalloc) kieltäytyi hyväksymästä muuttaa, vedoten vakavaan suorituskyvyn heikkenemiseen ja tarpeeseen lisätä laajoja testejä, joilla tarkistetaan säännöllisesti, että kaikki toimii odotetulla tavalla. Checkpointin insinöörien testaus osoitti, että Safe-Linking -menetelmä ei johda ylimääräiseen muistinkulutukseen ja suorituskyky hep-operaatioita suoritettaessa heikkenee keskimäärin vain 0.02 % ja pahimmassa tapauksessa 1.5 % (vertailun vuoksi: kromissa käytetty menetelmä on arvioitu "alle 2%"). Inkluusio
Safe-Linking johtaa 2–3 lisäkokoonpanokäskyn suorittamiseen joka kerta, kun free():tä kutsutaan, ja 3–4 käskyä joka kerta, kun malloc():ta kutsutaan. Alustus- ja satunnaisarvon luontivaiheita ei vaadita.

Safe-Linkingiä voidaan käyttää paitsi parantamaan erilaisten kasatoteutusten turvallisuutta, myös lisäämään eheyssäätimiä kaikkiin tietorakenteisiin, jotka käyttävät itse puskurien viereen sijoitettuja osoittimien luetteloita. Menetelmä on hyvin yksinkertainen toteuttaa ja vaatii vain yhden makron lisäämisen ja sen soveltamisen koodin seuraavaan lohkoon (esimerkiksi Glibc:lle) muutoksia vain muutama rivi koodia). Menetelmä tiivistyy seuraaviin muutoksiin:

+#define PROTECT_PTR(pos, ptr) \
+ ((__tyyppi (ptr)) (((((koko_t) pos) >> 12) ^ ((koko_t) ptr)))

+#define REVEAL_PTR(ptr) PROTECT_PTR (&ptr, ptr)

- nextp = p->fd;
+ nextp = REVEAL_PTR (p->fd);
...

Menetelmän ydin on käyttää satunnaista dataa ASLR-osoitteen satunnaistusmekanismista (mmap_base) yksittäisten linkitettyjen luetteloiden, kuten Fast-Bins ja TCache, suojaamiseen. Ennen kuin arvoa käytetään luettelon seuraavaan elementtiin osoittavaan osoittimeen, se suorittaa maskin muuntamisen ja tarkistaa sivun tasauksen. Osoitin korvataan operaation "(L >> PAGE_SHIFT) XOR (P)" tuloksella, jossa P on osoittimen arvo ja L on muistipaikka, johon osoitin on tallennettu.

Kun sitä käytetään järjestelmässä ASLR (Address Space Layout Randomization) osa L-bitistä keon perusosoitteella sisältää satunnaisia ​​arvoja, joita käytetään avaimena P:n koodaamiseen (erotettu 12-bittisellä siirtotoiminnolla 4096-tavuisille sivuille). Tämä manipulointi vähentää osoittimen kaappauksen riskiä hyväksikäytössä, koska osoitinta ei tallenneta alkuperäisessä muodossaan ja sen korvaaminen edellyttää keon varaustiedon tuntemista. Lisäksi korjauskoodi sisältää myös lisätarkistuksen lohkon kohdistukselle, mikä ei salli hyökkääjän korvata osoitinta kohdistamattomalla arvolla ja vaatii tietoa kohdistettujen bittien määrästä, mikä 64-bittisissä järjestelmissä mahdollistaa lisäksi eston. 15 16:sta hyökkäysyrityksestä, jotka eivät ota kohdistusta huomioon.

Menetelmä suojaa tehokkaasti hyökkäyksiltä, ​​jotka käyttävät osittaista osoittimen uudelleenkirjoittamista (pienten tavujen muuttaminen), täydellistä osoittimen uudelleenkirjoittamista (uudelleenohjaaminen hyökkääjän koodiin) ja listan sijainnin vaihtamista kohdistamattomassa osoitteessa. Esimerkkinä on osoitettu, että Safe-Linkingin käyttö mallocissa mahdollistaisi viime aikoina tapahtuneen hyväksikäytön eston tunnistettu samat haavoittuvuustutkijat CVE-2020-6007 Philips Hue Bridge -älyvalossa, joka johtuu puskurin ylivuodosta ja antaa sinun hallita laitetta.

Lähde: opennet.ru