Planer för att stärka skyddsmekanismen W^X i OpenBSD

Theo De Raadt delte planer för att förstärka W^X (Write XOR Execute) minnesskyddsmekanismen. Idén bakom mekanismen är att processens minnessidor inte samtidigt kan vara tillgängliga för skrivning och exekvering. På så sätt kan koden exekveras först efter att skrivning har förhindrats, och skrivning till minnessidan är endast möjlig efter att exekvering har förhindrats. W^X-mekanismen hjälper till att skydda användarutrymmet från typiska attacker som utförs genom buffertöverskridning, inklusive stacköverskridningar, och är aktiv i OpenBSD. standard.

Från början av arbetet med W^X var det klart att detta skulle bli en lång väg, eftersom det finns ett betydande antal applikationer som använder JIT. JIT-implementationer kan delas in i tre kategorier:

• Att växla minne mellan W- och X-tillstånd och acceptera "kostnaden" för systemanrop. mprotect.
• Skapar alias mellan ett par W och X-mappingar av samma minne.
• Den mest "smutsiga" varianten är de som kräver W|X-minnesmodeller, som tillåter samtidig skrivning 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. Ändå, eftersom det var nödvändigt att köra program med W|X JIT (främst Chromium och Iridum), lades alternativet för montering av filsystemet "wxallowed" till, vilket gjorde det möjligt att använda minnet för både skrivning och exekvering, om den exekverbara ELF-filen var markerad med "wxneeded"-taggen, och själva applikationerna skyddades ytterligare med hjälp av mekanismer. pledge och unveil för att begränsa listan över använda systemanrop och de delar av filsystemet som är tillgängliga för applikationen.

För att ytterligare komplicera utnyttjandet av sårbarheter i sådana applikationer föreslogs en tilläggsmekanism. MAP_STACK, som kontrollerar om systemanropet utförs från en minnessida som är tillgänglig för skrivning. Om sidan är tillgänglig för skrivning avslutas processen tvingat. Således kan inte angriparen använda systemanrop och tvingas försöka hitta nödvändiga gadgets i JIT-implementationen eller till och med utföra ett svårare arbete med att upptäcka stubbarna för systemanrop direkt i. slumptilldelad libc..

Chrome- och Iridium-processerna är tillräckligt skyddade med pledge och unveil, men att begränsa möjligheten att använda systemanrop som write(2) ger uppenbarligen några fördelar, eftersom det skapar ytterligare svårigheter för angriparen. Å andra sidan kan svårigheter också uppstå om JIT-implementationen använder inbyggda systemanrop från W|X-minnet. Det finns dock anledning att hoppas att detta inte blir ett problem, eftersom ABI har ändrats flera gånger, och ingen har någonsin rapporterat om några problem.

Ändringarna finns nu tillgängliga i de regelbundna snapshots för OpenBSD-CURRENT-grenen, alla intresserade är inbjudna att testa.

Theo förtjänade en särskild kommentar angående relaterade nyheter om introduktionen av lägen i Chrome/Iridium. JITless. Ur hans perspektiv är detta acceptabelt för vissa användningsmodeller, men sannolikt inte för alla, eftersom belastningen på processorn uppenbarligen ökar i detta läge. Nu kommer Chrome huvudsakligen att fungera om "wxallowed" stängs av för /usr/local, även om det kan uppstå problem med vissa tillägg (ghostery nämns som ett exempel). Hur som helst hoppas Theo att fullständig drift i JITless-läget kommer att nå ett fullt fungerande tillstånd inom en snar framtid.

Källa: opennet.ru