Тео Де Раадт планове за укрепване на механизма за защита на паметта 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”, а самите приложения допълнително се защитават, използвайки механизми. и за ограничаване на списъка с използваните системни повиквания и достъпните за приложението части от файловата система съответно.
За допълнително усложняване на експлоатацията на уязвимостите в подобни приложения е предложено допълнение на механизма , което проверява, дали системното повикване се изпълнява от достъпна за запис страница памет. Ако страницата е достъпна за запис, процесът се принудително приключва. Така нападателят не може да използва системни повиквания и ще бъде принуден да опита да намери нужните „gadgets” в имплементацията на JIT или дори да извърши по-трудната работа по откриване на „stubs” на системните повиквания директно в .
Процессите Chrome/Iridium са надеждно защитени с pledge и unveil, но забраната за използване на системни повици като write(2) очевидно предлага предимства, тъй като поставя допълнителни пречки пред нападателя. Въпреки това, трудности могат да възникнат и ако реализацията на JIT използва нативни системни повици от W|X памет. Все пак, има основания да се надеем, че такова ще бъде избегнато, тъй като ABI многократно се е променяло, но никой никога не е докладвал за проблеми.
Промените вече са налични в редовните снапшоти на клон OpenBSD-CURRENT, всички заинтересовани са поканени да направят тестове.
Отделен коментар от Тео заслужава новината за появата на режим в Chrome/Iridium. . От неговата гледна точка, това е приемливо за някои модели на използване, но вероятно не за всички, тъй като в този режим очевидно ще се увеличи натоварването на процесора. В момента Chrome ще работи основно, ако се изключи «wxallowed» за /usr/local, въпреки че е вероятно да има проблеми с някои разширения (например ghostery). Както и да е, Тео се надява, че пълната работа в JITless-режим ще бъде доведена до напълно работно състояние в близко бъдеще.
Източник: opennet.ru
