Тео Де Раадт поделился планами по усилению механизма защиты памяти 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", а сами приложения дополнительно защищались, используя механизмы pledge и unveil для ограничения списка используемых системных вызовов и доступных для приложения частей файловой системы соответственно.

Для дальнейшего усложнения эксплуатации уязвимостей в подобных приложениях предложено дополнение механизма MAP_STACK, которое проверяет, выполняется ли системный вызов из доступной для записи страницы памяти. Если страница доступна для записи, процесс принудительно завершается. Таким образом, злоумышленник не сможет использовать системные вызовы и будет вынужден пытаться найти нужные гаджеты в реализации JIT или даже выполнять более трудную работу по обнаружению заглушек системных вызовов непосредственно внутри случайно связанного libc.

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

Отдельного комментария со стороны Тео заслужили связанные новости про появление в Chrome/Iridium режима JITless. С его точки зрения, это приемлемо для некоторых моделей использования, однако, вероятно, не для всех, так как в данном режиме очевидно возрастёт нагрузка на процессор. Сейчас Chrome в основном будет работать, если отключить "wxallowed" для /usr/local, хотя и вероятны проблемы с некоторыми расширениями (в пример приводится ghostery). Так или иначе, Тео надеется, что полноценная работа в JITless-режиме будет доведена до полностью рабочего состояния в ближайшее время.