Theo De Raadt planerar att stärka minnesskyddsmekanismen W^X (Write XOR Execute). Kärnan i mekanismen är att processminnessidor inte kan nås samtidigt för skrivning och exekvering. Således kan kod exekveras endast efter att skrivning har inaktiverats, och skrivning till en minnessida är endast möjlig efter att exekveringen har inaktiverats. W^X-mekanismen hjälper till att skydda användarutrymmesapplikationer från vanliga buffertspillsattacker, inklusive stackspill, och är aktiv i OpenBSD .
Från början av arbetet med W^X stod det klart att detta var en lång väg, eftersom det fanns ett betydande antal applikationer som använde JIT. JIT-implementationer kan delas in i tre kategorier:
- Växla minne mellan W och X tillstånd, acceptera "kostnaden" för systemanropet .
- Skapa alias mellan ett par W- och X-mappningar av samma minne.
- Det mest "smutsiga" alternativet kräver en W|X-minnesmodell som tillåter samtidig inspelning och exekvering.
För närvarande finns det betydligt färre program som använder det tredje alternativet och fler som använder det första och andra. Men eftersom det var nödvändigt att köra program med W|X JIT (främst Chromium och Iridum), lades ett "wxallowed" filsystemmonteringsalternativ till, vilket gjorde att minnet kunde användas samtidigt för både skrivning och exekvering, i fallet med den körbara ELF:en filen är märkt med "wxneeded"-markören, och själva applikationerna skyddades dessutom med hjälp av mekanismer и för att begränsa listan över använda systemanrop och delar av filsystemet som är tillgängliga för applikationen.
För att ytterligare komplicera utnyttjandet av sårbarheter i sådana applikationer föreslås ett tillägg till mekanismen , som kontrollerar om systemanropet exekveras från en skrivbar minnessida. Om sidan är skrivbar tvingas processen att avslutas. På så sätt kommer en angripare inte att kunna utnyttja systemsamtal och kommer att tvingas försöka hitta de nödvändiga prylarna i JIT-implementeringen eller till och med göra det svårare arbetet med att upptäcka systemanropsstubbar direkt inuti .
Chrome/Iridium-processer är redan ganska tillförlitligt skyddade med hjälp av pledge och unveil, men att ta bort möjligheten att använda till exempel skriv(2)-systemanropet har uppenbarligen en viss fördel, eftersom det skapar ytterligare svårigheter för angriparen. Men svårigheter kan också uppstå om JIT-implementeringen använder inbyggda systemanrop från W|X-minne. Det finns dock anledning att hoppas att så inte blir fallet, eftersom ABI har ändrats flera gånger, men ingen har någonsin rapporterat problem.
Ändringarna är redan tillgängliga i vanliga ögonblicksbilder av OpenBSD-Current-grenen, alla intresserade är välkomna att testa.
Relaterade nyheter om utseendet på läget i Chrome/Iridium förtjänar en separat kommentar från Theo . Ur hans synvinkel är detta acceptabelt för vissa användningsmodeller, men förmodligen inte för alla, eftersom detta läge uppenbarligen kommer att öka belastningen på processorn. För närvarande fungerar Chrome mest om du inaktiverar "wxallowed" för /usr/local, även om det kan finnas problem med vissa tillägg (ghosty är ett exempel). På ett eller annat sätt hoppas Theo att fullfjädrat arbete i JITless-läge kommer att föras till ett fullt operativt tillstånd inom en snar framtid.
Källa: opennet.ru