Theo De Raadt planlegger å styrke W^X (Write XOR Execute) minnebeskyttelsesmekanisme. Essensen av mekanismen er at prosessminnesider ikke kan nås samtidig for skriving og utførelse. Dermed kan kode kun kjøres etter at skriving er deaktivert, og skriving til en minneside er bare mulig etter at kjøring er deaktivert. W^X-mekanismen hjelper til med å beskytte brukerplassapplikasjoner fra vanlige bufferoverflyt-angrep, inkludert stackoverflyt, og er aktiv i OpenBSD .
Fra starten av arbeidet med W^X var det klart at dette var en lang vei, siden det var et betydelig antall applikasjoner som brukte JIT. JIT-implementeringer kan deles inn i tre kategorier:
- Bytte minne mellom W- og X-tilstander, akseptere "kostnaden" for systemanropet .
- Opprette aliaser mellom et par W- og X-tilordninger av samme minne.
- Det mest "skitne" alternativet krever en W|X-minnemodell som tillater samtidig opptak og utførelse.
For øyeblikket er det betydelig færre programmer som bruker det tredje alternativet og flere som bruker det første og andre. Men siden det var nødvendig å kjøre programmer med W|X JIT (hovedsakelig Chromium og Iridum), ble et "wxallowed" filsystemmonteringsalternativ lagt til, som tillot minne å brukes samtidig for både skriving og kjøring, i tilfelle den kjørbare ELF filen er merket med "wxneeded"-markøren, og selve applikasjonene ble i tillegg beskyttet ved hjelp av mekanismer и for å begrense listen over henholdsvis systemanrop som brukes og deler av filsystemet som er tilgjengelig for applikasjonen.
For ytterligere å komplisere utnyttelsen av sårbarheter i slike applikasjoner, foreslås et tillegg til mekanismen , som sjekker om systemanropet blir utført fra en skrivbar minneside. Hvis siden er skrivbar, blir prosessen tvunget til å avslutte. På denne måten vil en angriper ikke være i stand til å utnytte systemanrop og vil bli tvunget til å prøve å finne de nødvendige gadgetene i JIT-implementeringen eller til og med gjøre det vanskeligere arbeidet med å oppdage systemanropsstubber direkte inne i .
Chrome/Iridium-prosesser er allerede ganske pålitelig beskyttet ved bruk av pant og avsløring, men å fjerne muligheten til å bruke for eksempel write(2) systemkallet har åpenbart en fordel, siden det skaper ytterligere vanskeligheter for angriperen. Det kan imidlertid også oppstå vanskeligheter hvis JIT-implementeringen bruker native systemanrop fra W|X-minne. Det er imidlertid grunn til å håpe at dette ikke vil være tilfelle, siden ABI har blitt endret flere ganger, men ingen har noen gang rapportert om problemer.
Endringene er allerede tilgjengelige i vanlige øyeblikksbilder av OpenBSD-Current-grenen, alle interesserte er invitert til å teste.
Relaterte nyheter om utseendet til modusen i Chrome/Iridium fortjener en egen kommentar fra Theo . Fra hans synspunkt er dette akseptabelt for noen bruksmodeller, men sannsynligvis ikke for alle, siden denne modusen åpenbart vil øke belastningen på prosessoren. Foreløpig vil Chrome stort sett fungere hvis du deaktiverer "wxallowed" for /usr/local, selv om det kan være problemer med enkelte utvidelser (ghosty er et eksempel). På en eller annen måte håper Theo at fullverdig arbeid i JITless-modus vil bringes til en fullt operativ tilstand i nær fremtid.
Kilde: opennet.ru