Theo De Raadt planer for at styrke W^X (Write XOR Execute) hukommelsesbeskyttelsesmekanismen. Essensen af mekanismen er, at hukommelsessiderne i processen ikke kan være tilgængelige for både skrivning og udførelse på samme tid. På den måde kan koden kun udføres efter at skriveadgang er blevet forbudt, og skrivning til hukommelsessiden er kun mulig efter udførelsen er forbudt. W^X-mekanismen hjælper med at beskytte applikationer i brugerrummet mod typiske angreb, der udføres gennem buffer overflow, herunder stak overflow, og den er aktiv i OpenBSD .
Fra begyndelsen af arbejdet med W^X var det klart, at det ville være en lang rejse, da der findes et betydeligt antal applikationer, der bruger JIT. JIT-implementeringer kan opdeles i tre kategorier:
- Skifter hukommelsen mellem W og X tilstande, idet de accepterer "omkostningerne" ved systemopkald. .
- Opretter aliasser mellem et par af W og X kortlægninger af den samme hukommelse.
- Den mest "beskidte" variant - kræver en hukommelsesmodel W|X, der tillader samtidig skrivning og udførelse.
I øjeblikket er der betydeligt færre programmer, der bruger den tredje variant, og flere der bruger den første og anden. Ikke desto mindre, da det var nødvendigt at køre programmer med W|X JIT (primært Chromium og Iridum), blev der tilføjet en mulighed for at montere filsystemet "wxallowed", som tillod brugen af hukommelse til både skrivning og udførelse, hvis den udførlige ELF-fil var markeret med "wxneeded", og selve applikationerne blev yderligere beskyttet ved hjælp af mekanismerne og for at begrænse listen over anvendte systemopkald og de dele af filsystemet, der er tilgængelige for applikationen.
For yderligere at komplicere udnyttelsen af sårbarheder i sådanne applikationer er der foreslået en tilføjelse til mekanismen , som kontrollerer, om systemopkaldet udføres fra en skrivbar hukommelsesside. Hvis siden er tilgængelig for skrivning, afsluttes processen tvangsmæssigt. På den måde kan en angriber ikke bruge systemopkald og vil være nødt til at forsøge at finde de nødvendige gadgets i JIT-implementeringen eller endda udføre det hårdere arbejde med at opdage stub-systemopkald direkte indeni. .
Chrome/Iridium-processerne er allerede ret sikkert beskyttede ved hjælp af pledge og unveil, men at fjerne muligheden for at bruge for eksempel systemopkaldet write(2) har åbenlyst nogle fordele, da det skaber yderligere vanskeligheder for angriberen. Dog kan der opstå problemer, hvis JIT-implementeringen bruger native systemopkald fra W|X-hukommelsen. Der er imidlertid grund til at håbe, at man ikke vil støde på sådanne problemer, da ABI er blevet ændret flere gange, men ingen har nogensinde rapporteret om problemer.
Ændringerne er allerede tilgængelige i de regelmæssige snapshots fra OpenBSD - Current-grenen, alle interesserede er inviteret til at teste.
Teo fortjente en særlig kommentar angående nyheden om tilføjelsen af en tilstand i Chrome/Iridium . Fra hans synspunkt er dette acceptabelt for nogle brugsmønstre, men sandsynligvis ikke for alle, da CPU-belastningen åbenlyst vil stige i denne tilstand. I øjeblikket vil Chrome i hovedsagelig fungerer, hvis man deaktiverer "wxallowed" for /usr/local, selvom der kan opstå problemer med nogle udvidelser (ghostery nævnes som eksempel). Under alle omstændigheder håber Teo, at den fulde funktionalitet i JITless-tilstand vil blive gjort helt operationel inden for kort tid.
Kilde: opennet.ru
