Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Значит, он либо пользуется каким-нибудь защищенным кодогенератором, порождающим заведомо безопасный код, либо не работает при включенном DEP.
ЕМ>У меня DEP включен по умолчанию, и явных исключений нет — значит, среди работающего у меня софта такого безобразия не имеется.
DEP/NX у всех включён по умолчанию. И даже наличие этого флажка на исполнимом файле, всего лишь означает, что он просто обещает быть совместим с этим режимом.
И это никак не связано с возможностью того, что процесс сам себе может выделить страницу памяти, и маркировать её как исполнимую.
А вот управление этим разрешением (на порождение или изменение исполнимого кода) — тоже существует в виде process mitigation policy, но врядли такой запрет можно ожидать от программы, которая полностью основана на JIT-рантайме, да ещё и с набором примитивов на борту, которые активно это используют.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>>А, пардон, это я попутал DEP с политиками запрета исполнения неподписанного кода, которые в ядре уже давно обязательны, а в user-mode — пока еще добровольны.
S>Ну, пока не очень понятно, как эти политики будут совмещаться с JIT. Ну, то есть можно, наверное, построить защиту на том, что право на динамическое порождение исполняемого кода предоставляется только коду, который подписан сертификатом производителя ОС. Тогда дотнет и джава смогут выполнять JIT, а какие-нибудь опенсорсные решения — не смогут.
S>Но выглядит это всё довольно хрупко.

В Маке так и работает и ничего.
Если нет у приложения разрешения на JIT изначально то ему будет нельзя.
То есть при подписи указываем в специальном файле, что будет у нас JIT и подписываем.

Из замеченного, маководу не любят языки с JIT из-за этого дополнительного шага =)

Здравствуйте, _NN_, Вы писали:
_NN>В Маке так и работает и ничего.

_NN>Если нет у приложения разрешения на JIT изначально то ему будет нельзя.
_NN>То есть при подписи указываем в специальном файле, что будет у нас JIT и подписываем.
Но это же опять хрупко: смотрите, если гранулярность разрешения — приложение, то как мы отличим работу православного JIT от злоумышленного генератора в стиле топикстартера?

То есть мат ставится в три хода:

1. Пишем нормальное, добронравное приложение, которое пользуется JIT. Подписываем официальным сертификатом благонадёжного разработчика. В приложении имеется дырка в стиле log4j, которая позволяет исполнять сторонний код (а способов такое сделать — много; тут и плагины, и уязвимости сторонних библиотек)
   
2. Засовываем через эту дырку сторонний код. Сам по себе этот код написан на IL, который обрабатывается всё ещё православным JIT.
   
3. Засунутый сторонний код порождает нативный код, который уже не является безопасным, и делает всякие нехорошести с приложением и его окружением.

Здравствуйте, Sinclair, Вы писали:

S>То есть мат ставится в три хода:
S>* Пишем нормальное, добронравное приложение, которое пользуется JIT. Подписываем официальным сертификатом благонадёжного разработчика. В приложении имеется дырка в стиле log4j, которая позволяет исполнять сторонний код (а способов такое сделать — много; тут и плагины, и уязвимости сторонних библиотек)
S>*Засовываем через эту дырку сторонний код. Сам по себе этот код написан на IL, который обрабатывается всё ещё православным JIT.
S>*Засунутый сторонний код порождает нативный код, который уже не является безопасным, и делает всякие нехорошести с приложением и его окружением.

Хороший вопрос как различать.
Это надо как-то системе сообщать кто может менять страницу и дать права запуска кода.
И чувствуется, что и это можно обойти

Проще тогда просто запрещать JIT.