Kontrollera punkten (en global leverantör av IT-säkerhetslösningar) släpptes för flera dagar sedan introduktionen säkerhetsmekanismen "Safe-Linking", que gör det svårt att skapa exploateringar som manipulerar definitionen eller ändringen av pekare till tilldelade buffertar när du gör ett malloc-samtal.
Den nya "Safe-Linking" -mekanismen blockerar inte helt möjligheten att utnyttja sårbarheter, men med minimal overhead komplicerar skapandet av vissa kategorier av exploateringarEftersom det förutom det utnyttjade buffertöverflödet är det nödvändigt att hitta en annan sårbarhet som orsakar information om platsen för högen i minnet.
Säkerlänkande implementeringsplåster förbereddes för Glibc (ptmalloc), uClibc-NG (dlmalloc), gperftools (tcmalloc) och Google TCMalloc, samt ett förslag om att modernisera skyddet i Chromium (sedan 2012 har Chromium redan integrerats med lösningar på samma problem) MaskPtr-skyddsteknik, men Checkpoints lösning visar bättre prestanda).
De föreslagna korrigeringsfilerna har redan godkänts för leverans i augusti-versionen av Glibc 3.32 och Safe-Linking är aktiverat som standard. I uClibc-NG inkluderades stöd för säker länk i version 1.0.33 och är aktiverat som standard. I gperftools (gammal tcmalloc) accepteras ändringarna, men kommer att erbjudas som ett alternativ i en framtida release.
TCMalloc-utvecklare vägrade att acceptera ändringen, cmed stark prestationsframgång och behovet av att lägga till avancerade tester för att regelbundet verifiera att allt fungerar som det ska.
Testerna utförda av Kontrollpunktsingenjörer visade att Safe-Linking-metoden inte leder till ytterligare minnesförbrukning och resultatet vid högoperationer minskar i genomsnitt endast med 0.02% och i värsta fall med 1.5%
Aktivera Safe-Linking leder till exekvering av 2-3 ytterligare monteringsinstruktioner för varje samtal för att frigöra () och 3-4 instruktioner när du ringer till malloc (). Initialiseringsstart och slumpmässig värdegenerering krävs inte.
Safe-Linking kan inte bara användas för att öka säkerheten av olika högimplementeringar, säven för att lägga till integritetskontroller i alla datastrukturer som använder en lista med individuellt länkade pekare bredvid buffertarna.
Metoden det är väldigt enkelt att implementera och kräver bara ett makro och tillämpa den på pekarna till nästa kodblock (till exempel, för Glibc ändras bara några rader i koden).
Kärnan i metoden är att tillämpa slumpmässiga data från ASLR-adress-randomiseringsmekanismen (mmap_base) för att skydda individuellt länkade listor som snabbfack och TCache. Innan pekvärdet appliceras på nästa objekt i listan utförs maskkonvertering och justeringskontroll längs kanten på minnessidan. Pekaren ersätts med resultatet av operationen "(L >> PAGE_SHIFT) XOR (P)", där P är pekarens värde och L är den plats i minnet där denna pekare är lagrad.
När det används i ASLR-systemet (Address Space Layout Randomization) innehåller några av L-bitarna med basadressen på slumpmässiga slumpmässiga värden som används som en nyckel för att koda P (de extraheras med en skiftoperation på 12 bitar för 4096 byte sidor).
Sådan manipulation minskar risken för att fånga en pekare i en exploatering, eftersom pekaren inte lagras i sin ursprungliga form och för att ersätta den måste du veta information om platsen för högen.
Metoden är effektiv för att skydda mot attacker som använder partiell pekdefinition (låg byteförskjutning), fullständig omskrivning av pekare (omdirigera till angriparens kod) och ändra listans position i en icke-inriktad riktning.
Som ett exempel visas att användningen av Safe-Linking i malloc skulle blockera utnyttjandet av sårbarheten CVE-2020-6007 som nyligen upptäcktes av samma forskare i Philips Hue Bridge-smarta bakgrundsbelysning orsakad av buffertöverflödet och möjliggör enheten.
Fuente: https://research.checkpoint.com