Tekniske detaljer om Control Flow Integrity
"Tilgjengeligheten av et stort antall funksjonspekere i kjernen hjelper populariteten til dette angrepsmønsteret. Selv om angripere ikke kan injisere egen kjørbar kode, kan vilkårlige deler av eksisterende kjernekode kjøres for å fullføre utnyttelsen.
LLVMsin CFI forsøker å dempe disse angrepene ved å begrense gyldige anropsmål og tvinge frem en kjernepanikk når de oppdager et CFI-brudd. En sjekk legges til før hver indirekte gren for å bekrefte at måladressen peker på en gyldig funksjon med korrekt signatur. Dette forhindrer en indirekte gren fra å hoppe til en vilkårlig kodeplassering og begrenser til og med funksjonene som kan kalles. En angriper vil fortsatt kunne endre en funksjonspeker hvis en feil tillater tilgang. Men LLVMs CFI begrenser 55 % av indirekte samtaler til maksimalt 5 mulige mål og 80 % til maksimalt 20 mål. For å bestemme alle gyldige anropsmål for hver indirekte gren, må kompilatoren se hele kjernekoden på en gang.
Bruken av LTO (
Optimalisering av koblingstid) gjør dette mulig. LLVMs CFI krever bruk av LTO, der kompilatoren produserer LLVM-spesifikk bitkode for alle C kompileringsenheter, og en LTO-bevisst linker bruker LLVM-backend for å kombinere bitkoden og kompilere den til opprinnelig kode.I tillegg til å tillate bruk av CFI, oppnår LTO bedre kjøretidsytelse gjennom analyse av hele programmet og optimalisering på tvers av moduler.
ThinLTO har nesten tatt opp til LTOs ytelsesforbedring. I ThinLTO-modus, som med vanlig LTO, Clang sender ut LLVM-bitkode etter kompileringsfasen. ThinLTO-bitkoden er utvidet med et kompakt sammendrag av modulen. Under koblingstrinnet blir bare sammendragene lest og slått sammen til en kombinert sammendragsindeks, som inkluderer en indeks over funksjonsplasseringer for senere import av funksjoner på tvers av moduler. Deretter utføres rask og effektiv analyse av hele programmet på den kombinerte oppsummeringsindeksen. ThinLTO tillater en flertråds koblingsprosess, noe som resulterer i redusert kompileringstid.
På grunn av at CFI avbryter programkjøringen når den treffer visse feilklasser, klassifiseres den også som et feilsøkingsverktøy, som tidligere nevnt, når den brukes i permissiv modus. Permissive CFI vil vise CFI-brudd i kjerneloggen, uten å tvinge fram en kjernepanikk. Kjernene 4.9 (Pixel 3-generasjonsenheter) og 4.14 (Pixel 4-generasjonsenheter) hadde flere funksjonstyper uoverensstemmelser som resulterte i CFI-brudd, som ble adressert av Google i patchsett tilgjengelig på kjernen/common repos.
På grunn av Android-økosystemets natur vil disse mismatchene sannsynligvis også finnes i SoC-produsenten (i dette tilfellet Qualcomm) eller OEM (OnePlus) spesifikk kode. Flere CFI-brudd i Qualcomm-koden som er forskjellig fra 4.19-kjernen ble fikset på Kirisakura-kjernen for OnePlus 8 Pro (eksempel: 1, 2, 3).
Å kjøre kjernen i tillatt CFI avslørte CFI-brudd i kode relatert til OnePlus-drivere også (relevante forpliktelser kan bli funnet her og her). Kirisakura-kjernen for OnePlus 8 Pro kjører med CFI håndhevet, og beskytter brukerne mot denne typen kodegjenbruksangrep."
Les mer
DIY-entusiast (dvs. berger av gamle PC-deler). Skanda har vært en ivrig bruker av Android siden Eclair-dagene, og liker også å følge de siste utviklingstrendene i verden av enkeltbordsdatabehandling.