Theo De Raadt plannen om it W^X (Write XOR Execute) ûnthâldbeskermingsmeganisme te fersterkjen. De essinsje fan it meganisme is dat proses ûnthâld siden kinne net tagelyk tagonklik foar skriuwen en útfiering. Sa kin koade allinich útfierd wurde nei't skriuwen is útskeakele, en skriuwen nei in ûnthâldside is allinich mooglik nei't útfiering is útskeakele. It W^X-meganisme helpt om applikaasjes foar brûkersromte te beskermjen tsjin gewoane oanfallen fan bufferoverflow, ynklusyf stackoverflows, en is aktyf yn OpenBSD .
Fan it begjin fan wurk oan W^X wie it dúdlik dat dit in lange wei wie, om't d'r in signifikant oantal applikaasjes wiene dy't JIT brûkten. JIT-ymplemintaasjes kinne wurde ferdield yn trije kategoryen:
- Skeakelje ûnthâld tusken W en X steaten, akseptearje de "kosten" fan it systeem oprop .
- Aliassen oanmeitsje tusken in pear W- en X-mappings fan itselde ûnthâld.
- De meast "smoarch" opsje fereasket in W | X ûnthâld model dat makket simultane opname en útfiering.
Op it stuit binne d'r signifikant minder programma's dy't de tredde opsje brûke en mear mei de earste en twadde. Om't it lykwols nedich wie om programma's út te fieren mei W|X JIT (benammen Chromium en Iridum), waard in "wxallowed" triemsysteem-mount-opsje tafoege, wêrtroch ûnthâld tagelyk brûkt wurde koe foar sawol skriuwen as útfieren, yn gefal as de útfierbere ELF bestân is markearre mei de "wxneeded" marker, en de applikaasjes sels waarden ek beskerme mei help fan meganismen и om respektivelik de list mei brûkte systeemoproppen te beheinen en dielen fan it bestânsysteem beskikber foar de applikaasje.
Om de eksploitaasje fan kwetsberens yn sokke applikaasjes fierder te komplisearjen, wurdt in tafoeging oan it meganisme foarsteld , dy't kontrolearret oft de systeemoprop wurdt útfierd fan in skriuwbere ûnthâldside. As de side skriuwber is, wurdt it proses twongen om te beëinigjen. Op dizze manier sil in oanfaller net by steat wêze om systeemoproppen te eksploitearjen en wurdt twongen om te besykjen de nedige gadgets te finen yn 'e JIT-ymplemintaasje of sels it dreger wurk te dwaan fan it opspoaren fan systeemopropstubs direkt binnen .
Chrome/Iridium-prosessen binne al frij betrouber beskerme mei help fan pledge en ûntbleate, mar it fuortheljen fan de mooglikheid om bygelyks de write(2)-systeemoprop te brûken hat fansels wat foardiel, om't it ekstra swierrichheden foar de oanfaller skept. Swierrichheden kinne lykwols ek ûntstean as de JIT-ymplemintaasje native systeemoproppen brûkt fan W | X-ûnthâld. Der is lykwols reden om te hoopjen dat dit net it gefal sil wêze, om't de ABI ferskate kearen feroare is, mar gjinien hat ea problemen rapporteare.
De wizigingen binne al beskikber yn reguliere snapshots fan 'e OpenBSD-Current branch, elkenien dy't ynteressearre is útnoege om te testen.
Related nijs oer it uterlik fan 'e modus yn Chrome / Iridium fertsjinnet in aparte opmerking fan Theo . Fanút syn eachpunt is dit akseptabel foar guon gebrûksmodellen, mar wierskynlik net foar allegear, om't dizze modus fansels de lading op 'e prosessor sil ferheegje. Op it stuit sil Chrome meast wurkje as jo "wxallowed" útskeakelje foar /usr/local, hoewol d'r problemen kinne wêze mei guon tafoegings (ghosty is in foarbyld). Op ien of oare manier hopet Theo dat folweardich wurk yn JITless-modus yn 'e heine takomst nei in folslein operasjonele steat brocht wurde sil.
Boarne: opennet.ru