Theo De Raadt planlægger at styrke W^X (Write XOR Execute) hukommelsesbeskyttelsesmekanismen. Essensen af mekanismen er, at proceshukommelsessider ikke kan tilgås samtidigt til skrivning og udførelse. Kode kan således kun udføres, efter at skrivning er deaktiveret, og skrivning til en hukommelsesside er kun mulig, efter at udførelsen er deaktiveret. W^X-mekanismen hjælper med at beskytte brugerrumsapplikationer mod almindelige bufferoverløbsangreb, herunder stackoverløb, og er aktiv i OpenBSD .
Fra starten af arbejdet med W^X var det klart, at dette var en lang vej, da der var et betydeligt antal applikationer, der brugte JIT. JIT-implementeringer kan opdeles i tre kategorier:
- Skift hukommelse mellem W og X tilstande, accept af "omkostningerne" for systemopkaldet .
- Oprettelse af aliaser mellem et par W- og X-tilknytninger af den samme hukommelse.
- Den mest "beskidte" mulighed kræver en W|X-hukommelsesmodel, der tillader samtidig optagelse og udførelse.
I øjeblikket er der betydeligt færre programmer, der bruger den tredje mulighed og flere, der bruger den første og anden. Men da det var nødvendigt at køre programmer med W|X JIT (hovedsageligt Chromium og Iridum), blev der tilføjet en "wxallowed" filsystemmonteringsmulighed, som gjorde det muligt at bruge hukommelsen samtidigt til både skrivning og udførelse, i tilfælde af at den eksekverbare ELF filen er markeret med "wxneeded" markøren, og selve applikationerne blev desuden beskyttet ved hjælp af mekanismer и at begrænse listen over anvendte systemkald og dele af filsystemet, der er tilgængelige for applikationen.
For yderligere at komplicere udnyttelsen af sårbarheder i sådanne applikationer foreslås en tilføjelse til mekanismen , som kontrollerer, om systemkaldet udføres fra en skrivbar hukommelsesside. Hvis siden er skrivbar, er processen tvunget til at afslutte. På denne måde vil en angriber ikke være i stand til at udnytte systemopkald og vil blive tvunget til at forsøge at finde de nødvendige gadgets i JIT-implementeringen eller endda udføre det sværere arbejde med at opdage systemopkaldsstubber direkte inde .
Chrome/Iridium-processer er allerede ret pålideligt beskyttet ved hjælp af pledge og unveil, men fjernelse af muligheden for at bruge f.eks. write(2) systemkaldet har naturligvis en vis fordel, da det skaber yderligere vanskeligheder for angriberen. Der kan dog også opstå vanskeligheder, hvis JIT-implementeringen bruger native systemkald fra W|X-hukommelse. Der er dog grund til at håbe, at det ikke bliver tilfældet, da ABI er blevet ændret flere gange, men ingen har nogensinde meldt om problemer.
Ændringerne er allerede tilgængelige i almindelige snapshots af OpenBSD-Current grenen, alle interesserede er inviteret til at teste.
Relaterede nyheder om udseendet af tilstanden i Chrome/Iridium fortjener en separat kommentar fra Theo . Fra hans synspunkt er dette acceptabelt for nogle brugsmodeller, men sandsynligvis ikke for alle, da denne tilstand naturligvis vil øge belastningen på processoren. I øjeblikket fungerer Chrome for det meste, hvis du deaktiverer "wxallowed" for /usr/local, selvom der kan være problemer med nogle udvidelser (ghostery er et eksempel). På en eller anden måde håber Theo, at fuldgyldigt arbejde i JITless-tilstand vil blive bragt til en fuldt operationel tilstand i den nærmeste fremtid.
Kilde: opennet.ru