Tarkista kohta (maailmanlaajuinen tietoturvaratkaisujen toimittaja) julkaistiin useita päiviä sitten johdanto turvamekanismin "Safe-Linking", että vaikeuttaa hyödyntämisen luomista jotka manipuloivat osoittimien määrittelyä tai vaihtamista allokoituihin puskureihin, kun he soittavat malloc-puhelua.
Uusi «Safe-Linking» -mekanismi ei estä täysin mahdollisuutta hyödyntää haavoittuvuuksia, mutta minimaalisilla yleiskustannuksilla vaikeuttaa tiettyjen hyväksikäyttöryhmien luomistaKuten hyödynnetyn puskurin ylivuoton lisäksi on löydettävä toinen haavoittuvuus, joka aiheuttaa tietoja kasan sijainnista muistissa.
Glibc: lle (ptmalloc), uClibc-NG: lle (dlmalloc), gperftooleille (tcmalloc) ja Google TCMallocille valmisteltiin Safe-Linking -korjaustiedostoja sekä ehdotus Chromiumin suojauksen modernisoimiseksi (vuodesta 2012 lähtien Chromium on jo integroitu ratkaisuihin sama ongelma) MaskPtr-suojaustekniikka, mutta Checkpointin ratkaisu näyttää paremman suorituskyvyn).
Ehdotetut korjaustiedostot on jo hyväksytty toimitettavaksi Glibc 3.32: n elokuun julkaisussa, ja Safe-Linking on oletusarvoisesti käytössä. UClibc-NG: ssä suojatun linkin tuki sisältyi versioon 1.0.33 ja se on oletusarvoisesti käytössä. Gperftoolsissa (vanha tcmalloc) muutokset hyväksytään, mutta ne tarjotaan vaihtoehtona tulevassa julkaisussa.
TCMalloc-kehittäjät kieltäytyivät hyväksymästä muutosta, cVahva suorituskyky ja tarve lisätä edistyneitä testejä säännöllisen tarkistuksen varmistamiseksi, että kaikki toimii oikein.
Testit suorittaa Tarkistuskohta-insinöörit osoittivat, että Safe-Linking -menetelmä ei lisää muistin kulutusta ja kasaoperaatioiden suorituskyky heikkenee keskimäärin vain 0.02% ja pahimmassa tapauksessa 1.5%
Safe-Linking -ominaisuuden käyttöönotto johtaa 2-3 lisäasenninohjeen suorittamiseen jokaisen ilmaisen puhelun yhteydessä () ja 3-4 käskyä mallocia () soitettaessa. Alustamisen aloitusta ja satunnaisarvojen muodostamista ei vaadita.
Safe-Linking -toimintoa voidaan käyttää paitsi turvallisuuden parantamiseen erilaisia kasan toteutuksia, sino myös lisätä eheystarkastuksia mihin tahansa tietorakenteeseen joka käyttää luetteloa yksittäisesti linkitetyistä osoittimista puskurien vieressä.
Menetelmä se on hyvin helppo toteuttaa ja vaatii vain makron lisäämisen ja käytä sitä osoittimiin koodin seuraavaan lohkoon (esimerkiksi Glibc: ssä koodissa muutetaan vain muutama rivi).
Menetelmän ydin on soveltaa satunnaisia tietoja ASLR-osoitteen satunnaistamismekanismista (mmap_base) yksilöllisesti linkitettyjen luetteloiden, kuten Fast-Bins ja TCache, suojaamiseksi. Ennen osoittimen arvon lisäämistä luettelon seuraavaan kohtaan maskin muunnos ja kohdistus tarkistetaan muistisivun reunalla. Osoitin korvataan operaation "(L >> PAGE_SHIFT) XOR (P)" tuloksella, jossa P on osoittimen arvo ja L on muistin paikka, johon tämä osoitin on tallennettu.
Kun käytetään ASLR (Address Space Layout Randomization) -järjestelmässä, jotkut kasan perusosoitteella varustetuista L-biteistä sisältävät satunnaisia arvoja, joita käytetään avaimena P: n koodaamiseen (ne puretaan 12 bitin siirtotoiminnolla) 4096 tavun sivuille).
Tällainen manipulointi vähentää osoittimen kaappaamisen riskiä hyödyntämisessä, Koska osoitinta ei ole tallennettu alkuperäisessä muodossaan, ja sen korvaamiseksi sinun on tiedettävä tiedot kasan sijainnista.
Menetelmä on tehokas suojaamaan hyökkäyksiltä, jotka käyttävät osittaista osoittimen uudelleenmäärittelyä (matalan tavun siirto), kirjoita osoitteet kokonaan uudelleen (ohjaa hyökkääjän koodiin) ja muuta luettelon sijaintia kohdistamattomaan suuntaan.
Esimerkiksi osoitetaan, että Safe-Linkingin käyttö mallocissa estäisi haavoittuvuuden CVE-2020-6007 hyödyntämisen, jonka samat tutkijat löysivät äskettäin samojen tutkijoiden Philips Hue Bridge -älyvalossa, jonka puskurin ylivuoto aiheutti ja jonka avulla hallita laitteen.
lähde: https://research.checkpoint.com