Планове за укрепване на механизма за сигурност W^X в OpenBSD

Тео Де Радт споделени планира да подсили механизма за защита на паметта W^X (Write XOR Execute). Същността на механизма е, че страниците на паметта на процеса не могат да бъдат достъпни едновременно за запис и изпълнение. По този начин кодът може да бъде изпълнен само след като записът е деактивиран, а записът в страница с памет е възможен само след като изпълнението е деактивирано. Механизмът W^X помага за защита на приложенията в потребителското пространство от често срещани атаки за препълване на буфер, включително препълване на стека, и е активен в OpenBSD по подразбиране.

От началото на работата по W^X беше ясно, че това е дълъг път, тъй като имаше значителен брой приложения, използващи JIT. JIT имплементациите могат да бъдат разделени на три категории:

• Превключване на паметта между W и X състояния, приемане на „цената“ на системното повикване mprotect.
• Създаване на псевдоними между двойка W и X преобразувания на една и съща памет.
• Най-„мръсната“ опция изисква W|X модел памет, който позволява едновременно записване и изпълнение.

В момента има значително по-малко програми, които използват третата опция и повече, които използват първата и втората. Въпреки това, тъй като беше необходимо да се изпълняват програми с W|X JIT (главно Chromium и Iridum), беше добавена опция за монтиране на файловата система "wxallowed", която позволява паметта да се използва едновременно както за запис, така и за изпълнение, в случай че изпълнимият ELF файлът е маркиран с маркера „wxneeded“, а самите приложения са допълнително защитени с помощта на механизми залог и откривам за ограничаване на списъка с използвани системни извиквания и съответно части от файловата система, достъпни за приложението.

За допълнително усложняване на използването на уязвимости в такива приложения се предлага допълнение към механизма MAP_STACK, който проверява дали системното повикване се изпълнява от страница с памет за запис. Ако страницата може да се записва, процесът се прекратява принудително. По този начин нападателят няма да може да използва системните повиквания и ще бъде принуден да се опита да намери необходимите притурки в изпълнението на JIT или дори да свърши по-трудната работа по откриване на мъничета на системни повиквания директно вътре случайно свързан libc.

Процесите на Chrome/Iridium вече са доста надеждно защитени с помощта на pledge и unveil, но премахването на възможността за използване например на системното извикване write(2) очевидно има известно предимство, тъй като създава допълнителни трудности за нападателя. Въпреки това могат да възникнат трудности, ако изпълнението на JIT използва собствени системни повиквания от W|X памет. Има обаче основание да се надяваме, че това няма да е така, тъй като ABI е променян няколко пъти, но никой никога не е докладвал за проблеми.

Промените вече са налични в редовните моментни снимки на клона OpenBSD-Current, всички заинтересовани са поканени да тестват.

Свързаните новини за появата на режима в Chrome/Iridium заслужават отделен коментар от Тео JITless. От негова гледна точка това е приемливо за някои модели на използване, но вероятно не за всички, тъй като този режим очевидно ще увеличи натоварването на процесора. Понастоящем Chrome ще работи най-вече, ако деактивирате „wxallowed“ за /usr/local, въпреки че може да има проблеми с някои разширения (ghostery е пример). По един или друг начин, Тео се надява, че пълноценната работа в режим JITless ще бъде доведена до напълно работоспособно състояние в близко бъдеще.

Източник: opennet.ru