Тэа Дэ Раадт планамі па ўзмацненні механізму абароны памяці W^X (Write XOR Execute). Сутнасць механізму ў тым, што старонкі памяці працэсу не могуць быць адначасова даступныя на запіс і выкананне. Такім чынам, код можа быць выкананы толькі пасля забароны запісу, а запіс у старонку памяці магчыма толькі пасля забароны выканання. Механізм W^X дапамагае абараніць прыкладанні ў прасторы карыстача ад тыпавых нападаў, якія здзяйсняюцца праз перапаўненне буфера, у тым ліку ад перапаўненняў стэка і актыўны ў OpenBSD. .
З пачатку прац над W^X было зразумела, што гэта доўгая дарога, бо існуе значная колькасць прыкладанняў, выкарыстоўвалых JIT. Рэалізацыі JIT можна падзяліць на тры катэгорыі:
- Пераключалыя памяць паміж W і X станамі, зміраючыся са «коштам» сістэмнага выкліку .
- Якія ствараюць псеўданімы паміж парай W і X адлюстраванняў адной і той жа памяці.
- Найбольш "брудны" варыянт - якія патрабуюць мадэлі памяці W | X, якая дапускае адначасовае ажыццяўленне запісу і выканання.
У наш час стала значна менш праграм, выкарыстоўвалых трэці варыянт і больш выкарыстоўвалых першы і другі. Тым не менш, бо было неабходна запускаць і праграмы з W|X JIT (галоўным чынам, Chromium і Iridum), была дададзеная опцыя мантавання файлавай сістэмы "wxallowed", якая дазваляла выкарыстоўваць памяць адначасова і для запісу і для выканання, у выпадку, калі выкананы ELF-файл адзначаны маркерам "wxneeded", а самі прыкладанні дадаткова абараняліся, выкарыстаючы механізмы и для абмежавання спісу выкарыстоўваных сістэмных выклікаў і даступных для дадатку частак файлавай сістэмы адпаведна.
Для далейшага ўскладнення эксплуатацыі ўразлівасцяў у падобных прыкладаннях прапанавана дадатак механізму. , якое правярае, ці выконваецца сістэмны выклік з даступнай для запісу старонкі памяці. Калі старонка даступная для запісу, працэс прымусова завяршаецца. Такім чынам, зламыснік не зможа выкарыстаць сістэмныя выклікі і будзе змушаны спрабаваць знайсці патрэбныя гаджэты ў рэалізацыі JIT ці нават выконваць цяжэйшую працу па выяўленні заглушак сістэмных выклікаў непасрэдна ўсярэдзіне. .
Працэсы Chrome/Iridium і так дастаткова надзейна абаронены пры дапамозе pledge і unveil, але пазбаўленне магчымасці выкарыстоўваць, напрыклад, сістэмны выклік write(2), відавочна, мае некаторую перавагу, бо стварае атакаваламу дадатковыя складанасці. Зрэшты, складанасці могуць узнікнуць і ў тым выпадку, калі рэалізацыя JIT выкарыстоўвае натыўныя сістэмныя выклікі з W | X памяці. Аднак, ёсць падставы спадзявацца, што з падобным не давядзецца сутыкнуцца, бо ABI неаднаразова змянялася, але ніхто ніколі не паведамляў аб праблемах.
Змены ўжо даступныя ў рэгулярных снапшотах галінкі OpenBSD-Сurrent, усе зацікаўленыя запрашаюцца да тэставання.
Асобнага каментара з боку Тэа заслужылі звязаныя навіны пра з'яўленне ў Chrome/Iridium рэжыму . З яго пункта гледжання, гэта прымальна для некаторых мадэляў выкарыстання, аднак, верагодна, не для ўсіх, бо ў дадзеным рэжыме відавочна ўзрасце нагрузка на працэсар. Цяпер Chrome у асноўным будзе працаваць, калі адключыць "wxallowed" для /usr/local, хоць і верагодныя праблемы з некаторымі пашырэннямі (у прыклад прыводзіцца ghostery). Так ці інакш, Тэа спадзяецца, што паўнавартасная праца ў JITless-рэжыме будзе даведзена да цалкам працоўнага стану ў бліжэйшы час.
Крыніца: opennet.ru