Sjekk punkt (en global leverandør av IT-sikkerhetsløsninger) utgitt introduksjonen for flere dager siden av sikkerhetsmekanismen "Safe-Linking", que gjør det vanskelig å skape utnyttelser som manipulerer definisjonen eller endringen av pekere til tildelte buffere når du foretar et malloc-anrop.
Den nye «Safe-Linking» -mekanismen blokkerer ikke helt muligheten for å utnytte sårbarheter, men med minimal overhead kompliserer etableringen av visse kategorier av utnyttelserSiden i tillegg til det utnyttede bufferoverløpet, er det nødvendig å finne en annen sårbarhet som forårsaker informasjon om plasseringen av dyngen i minnet.
Safe-Linking implementeringsoppdateringer ble utarbeidet for Glibc (ptmalloc), uClibc-NG (dlmalloc), gperftools (tcmalloc) og Google TCMalloc, samt et forslag om å modernisere beskyttelsen i Chromium (siden 2012 har Chromium allerede blitt integrert med løsninger på samme problem) MaskPtr-beskyttelsesteknikk, men Checkpoints løsning viser bedre ytelse).
De foreslåtte oppdateringene er allerede godkjent for levering i augustutgivelsen av Glibc 3.32, og Safe-Linking vil være aktivert som standard. I uClibc-NG var støtte for sikker kobling inkludert i versjon 1.0.33 og er aktivert som standard. I gperftools (gammel tcmalloc) godtas endringene, men vil bli tilbudt som et alternativ i en fremtidig utgivelse.
TCMalloc-utviklere nektet å godta endringen, cmed sterk prestasjonssuksess og behovet for å legge til avanserte tester for å regelmessig verifisere at alt fungerer som det skal.
Testene utført av Kontrollpunktingeniører viste at Safe-Linking-metoden ikke fører til ekstra minneforbruk og ytelsen når man utfører haugoperasjoner i gjennomsnitt bare reduseres med 0.02%, og i verste fall med 1.5%
Aktivering av Safe-Linking fører til utførelse av 2-3 ekstra monteringsinstruksjoner for hver samtale for å få gratis () og 3-4 instruksjoner når du ringer til malloc (). Initialiseringsstart og tilfeldig verdigenerering er ikke nødvendig.
Safe-Linking kan brukes ikke bare for å øke sikkerheten av forskjellige haugimplementeringer, sogså for å legge til integritetskontroller i enhver datastruktur som bruker en liste over individuelt koblede pekere som ligger ved siden av bufferne.
Metoden det er veldig enkelt å implementere og krever bare å legge til en makro og bruk den på pekerne til neste blokk med koden (for eksempel for Glibc endres bare noen få linjer i koden).
Essensen av metoden er å bruke tilfeldige data fra ASLR-adresser randomiseringsmekanismen (mmap_base) for å beskytte individuelt koblede lister som Fast-Bins og TCache. Før du bruker pekerverdien til neste element i listen, utføres maskeringskonvertering og justeringskontroll langs kanten av minnesiden. Pekeren erstattes med resultatet av operasjonen "(L >> PAGE_SHIFT) XOR (P)", hvor P er verdien til pekeren og L er stedet i minnet der denne pekeren er lagret.
Når det brukes i ASLR-systemet (Address Space Layout Randomization), inneholder noen av L-bitene med bunndressen til bunken tilfeldige verdier som brukes som en nøkkel til å kode P (de ekstraheres av en skiftoperasjon på 12 bits for 4096 byte sider).
Slik manipulasjon reduserer risikoen for å fange en peker i en utnyttelse, siden pekeren ikke er lagret i sin opprinnelige form, og for å erstatte den, må du vite informasjon om plasseringen av dyngen.
Metoden er effektiv for å beskytte mot angrep som bruker delvis peker-omdefinering (lav byte skift), fullstendig omskriving av pekere (omdirigere til angriperens kode) og endre posisjonen til listen i en ikke-justert retning.
Som et eksempel er det vist at bruk av Safe-Linking i malloc ville blokkere utnyttelsen av sårbarheten CVE-2020-6007 som nylig ble oppdaget av de samme forskerne i Philips Hue Bridge-smarte bakgrunnsbelysning forårsaket av bufferoverløpet og tillater kontroll enheten.
Fuente: https://research.checkpoint.com