JIT и безопасность сейчас

Just in time компиляция — обязательный атрибут современных т.н. "безопасных" сред Java и .NET. Основное предназначение — повышение скорости работы исполняемого кода. Под безопасностью в данном случае понимают пресловутые проверки на выход за границы массива и прочие шаолиньские приёмы против граблей.

Пользователь под угрозой

Далее речь пойдёт о совершенно другой безопасности — данных (включая денги) пользователя системы. Жизнь показала неспособность современных ОС противостоять атакам. Дело даже не столько в имеющем дыры дизайне ОС, сколько в большом количестве возможных векторов атаки; большую роль играет человеческий фактор. Поэтому принимаем как входное условие — малвара может быть запущена в системе пользователя.

Ловушка для троянского коня

После того, как троян успешно обошёл современные средства безопасности и запустился с правами админа, он должен обеспечить:

возможность повторного запуска;

невозможность удаления;

выполнение "полезной нагрузки" (payload).

2й пункт часто выполняет т.н. rootkit. В качестве ближайшего аналога можно вспомнить stealth-вирусы времён DOS. Руткиты бывают разные по наблюдаемому поведению (скрытие объектов ядра, файлов, сетевого трафика) и деталям реализации. Но все их объединяет один главный принцип — перехват различных функций для последующей модификации данных.

Если обеспечить невозможность перехвата, современные руткиты не смогут работать.

Хардкод — зло (в память PathGuard)

Про это пишут в книгах. Тоже самое пишут в статьях о создании руткитов, рекомендуя использовать дизассемблер (в простейшем случае — поиск по маскам) для поиска адресов в коде, которые нужно пропатчить. Такой способ более универсален, поскольку даже различные версии компилятора производят похожий код. Перехват путём модификации структур данных обычно проще, т.к структуры документированы.

Представим, что компилятор при повторной компиляции производит заметно отличающийся бинарник, и компиляция ядра системы происходит заново при установке, либо при каждом запуске. Такое возможно уже сейчас, например у *них (где руткиты мало распространены). Поиск адресов для перехвата может стать нетривиальным (подобный принцип — рандомизация адресов загрузки системных модулей — используется против т.н exploits).

Обратная сторона

Если включить (слегка модернизированный современный) компилятор в поставку ОС от MS, он начнёт использоваться большим количеством новых полиморфных вирусов. Хотя эта проблема может быть решена административным путём.

MS вынуждена будет поставлять некоторую производную исходного кода, что облегчит reverse engineering. Однако и сейчас доступны PDB файлы, а для минимальной функциональности метода достаточно объектных файлов и линкера.

Ничто не ново

Несколько лет назад известный вирусописатель Z0MBiE обошёлся без компилятора и исходных кодов — бинарный файл разбирался дизассемблером в дерево и компилировался после его трансформации. Подобная техника описана в статье 90210 Kernel mode antihooking by building our own kernel для обеспечения псходных целей с другой стороны.

Здравствуйте, gear nuke,

У меня два вопроса:
1а. О чём статья?
1б. Какова мораль?
2. Причём здесь JIT?

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

Ну, и к чему этот словестный фейерверк?

Что ты сказать то хотел?

Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>У меня два вопроса:
ДГ>1а. О чём статья?
ДГ>1б. Какова мораль?

Да, забыл про это написать Если ядро ОС определённым образом компилировать у пользователя на машине, 80-100% современной малвары перестанет работать.

ДГ>2. Причём здесь JIT?

Впринципе JIT не обязательно. Я просто записал мысли в том порядке, в каком они приходили ко мне; без подробностей о видах и методах перехватов (hooks) — это не важно, поскольку метод противодействия работает для общего случая.

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

VD>Здравствуйте, gear nuke, Вы писали:

VD>Ну, и к чему этот словестный фейерверк?

VD>Что ты сказать то хотел?

мда, Дотнеты-немерлы здорово промывают моск, дальше .NET песочницы современные программисты носа не кажут.
Если раньше считалось излишеством знать ассемблер, то теперь восременный программист разбирается в принципы работы ОС не лучше, чем свинья в апельсинах.

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

IID>мда, Дотнеты-немерлы здорово промывают моск, дальше .NET песочницы современные программисты носа не кажут.
IID>Если раньше считалось излишеством знать ассемблер, то теперь восременный программист разбирается в принципы работы ОС не лучше, чем свинья в апельсинах.

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

IID>мда, Дотнеты-немерлы здорово промывают моск, дальше .NET песочницы современные программисты носа не кажут.

Долго думал что ответить на этот порыв паронаидального бреда. Понял, что ничего разумного отверить нельзя. Ведь эти слова это так "плевок в небеса". К теме они относиться не могут просто потому, что темы просто нет, а к моим совам просто потому, что в них кроме вопроса "о чем эта тема?" ничего не было.

Так что ограничусь советом не захламлять форум бредом.

IID>Если раньше считалось излишеством знать ассемблер, то теперь восременный программист разбирается в принципы работы ОС не лучше, чем свинья в апельсинах.

У вас что по весне совсем что ли крышу снесло?

Ты то что сказать пыташся?

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

VD>К теме они относиться не могут просто потому, что темы просто нет, а к моим совам просто потому, что в них кроме вопроса "о чем эта тема?" ничего не было.

Я только сейчас понял, насколько прав IID. Дальше собственного носа — защита от ошибок программиста — не смотрите. Добро пожаловать в реальный мир: у пользователей воруют деньги, рассылают с зараженных машин спам и тд. Microsoft уже запретил патчить ядро. Только защиту от этого — PatchGuard — сломали и ломать будут, поскольку машинный код реализации поддаётся анализу малварой. Если же машинный код будет всегда разный, как его анализировать? Это проблема декомпиляции, и она сейчас не решается в общем виде за разумное время. Ну да, я не смогу привести строгое математическое доказательство, что метод даёт стойкую защиту от модификации кода (и, в ряде случаев, данных), как это никто не сможет сделать и для RSA.

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

GN>Я только сейчас понял, насколько прав IID.

Рад за твое прозрение.

GN> Дальше собственного носа — защита от ошибок программиста — не смотрите.

Это совет или приказ?

GN> Добро пожаловать в реальный мир: у пользователей воруют деньги, рассылают с зараженных машин спам и тд. Microsoft уже запретил патчить ядро.

Да, да. Microsoft это несомненно вселенское зло. И что из этого проистекает то?

GN> Только защиту от этого — PatchGuard — сломали и ломать будут, поскольку машинный код реализации поддаётся анализу малварой.

Здорово. И что?

GN> Если же машинный код будет всегда разный, как его анализировать? Это проблема декомпиляции, и она сейчас не решается в общем виде за разумное время. Ну да, я не смогу привести строгое математическое доказательство, что метод даёт стойкую защиту от модификации кода (и, в ряде случаев, данных), как это никто не сможет сделать и для RSA.

Я кажется догадался. Сегодня видимо мощьная солнечная активность которую не видно за олблаками и все кто сидит рядом у окон тихо (точнее очень громноко) сходя с ума.

Или в сумашедшем доме день открытх дверей?

Последний раз спрашиваю:
1. Что пытался сказать автор этой темы?
2. Каое отношение имет JIT к его рассуждениям.

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

GN>

JIT и безопасность сейчас

[...skipped...]

Разбираю пост gear_nuke по косточкам:

1) машинный код небезопасен, если он компилится сходным образом. Это постулат (лемма).

Что понимается под "небезопастностью" ? То что код может быть легко модифицирован малварью, (сплоетом, трояном и т.д.) для придания коду функций, не запланированных изначально автором этого кода. Прошу, не надо разводить флейм по поводу цифровых подписей и прочего. Пример: исполняется некий процесс, код которого был успешно проверен на легитимность. Имея права администратора я (на месте автора малвари) могу внедрить свой код в этот процесс не записывая в него ни байта данных извне, не делая CreateRemoteThread и прочих пакостей. Теперь злонамеренный код тоже рассматривается как доверенный.

Идем дальше

2).NET считается безопасным. Но т.к. запуск .NET программы в итоге выливается в исполнение машинного кода, сгенерированного сходным образом => (согласно лемме) .NET программы НЕБЕЗОПАСНЫ перед внешними угрозами. Они защищают программистов от самих же себя. Но не пользователя от злоумышленников. Пользователь .NET программы настолько же беззащитен, как и пользователь unmanaged софта.

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

GN> Если же машинный код будет всегда разный, как его анализировать? Это проблема декомпиляции, и она сейчас не решается в общем виде за разумное время. Ну да, я не смогу привести строгое математическое доказательство, что метод даёт стойкую защиту от модификации кода (и, в ряде случаев, данных), как это никто не сможет сделать и для RSA.
Ничего не понял, а при чем здесь машинный код? Что мне мешает модифицировать и анализировать непосредственно промежуточный код, который будет одинаковым? Это к тому же гораздо проще, чем машинный. В .Net как раз MSIL код и является конечным продуктом, никто же не лезет (за исключением производителей конкретного процессора) смотреть, на какие микрооперации процессор разбивает свои родные инструкции.

Т.е. автор топика СОВСЕМ не понимает что значит управляемая среда и о какой безопасности в ней идет речь ? ну ... можно посоветовать почитать документацию , статьи всякие ?

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

E>а при чем здесь машинный код?

Это откомпилированное ядро ОС и драйвера.

E>Что мне мешает модифицировать и анализировать непосредственно промежуточный код, который будет одинаковым?

Это не имеет смысла — ядро ОС уже скомпилировано и находится в памяти, готовое для злостной модификации. Модифицировать и ждать перезагрузки так же бессмысленно, поскольку элементарно обходится цифровой подписью.

Здравствуйте, VladD2,

GN>> Дальше собственного носа — защита от ошибок программиста — не смотрите.

VD>Это совет или приказ?

Данный топик показал, что факт.

GN>> Добро пожаловать в реальный мир: у пользователей воруют деньги, рассылают с зараженных машин спам и тд. Microsoft уже запретил патчить ядро.

VD>Да, да. Microsoft это несомненно вселенское зло. И что из этого проистекает то?

Здесь не LOR. Они добиваются тех же целей, о которых писал я. Методы другие.

GN>> Только защиту от этого — PatchGuard — сломали и ломать будут, поскольку машинный код реализации поддаётся анализу малварой.

VD>Здорово. И что?

Защита — фуфло. Но можно лучше.

VD>Я кажется догадался. Сегодня видимо мощьная солнечная активность которую не видно за олблаками и все кто сидит рядом у окон тихо (точнее очень громноко) сходя с ума.

VD>Или в сумашедшем доме день открытх дверей?

Для человека, способного поставить диагноз на расстоянии, следующие вопросы должны быть очень простыми:

VD>Последний раз спрашиваю:
VD>1. Что пытался сказать автор этой темы?
VD>2. Каое отношение имет JIT к его рассуждениям.

Можно получить разный машинный код ядра при каждой загрузке ОС.

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

GN>Это не имеет смысла — ядро ОС уже скомпилировано и находится в памяти, готовое для злостной модификации. Модифицировать и ждать перезагрузки так же бессмысленно, поскольку элементарно обходится цифровой подписью.
А можно поподробнее, каким образом я могу модифицировать ядро ОС из своей программы? Я вроде как всегда считал, что пользовательские процессы уже очень давно не могут модифицировать ядро и нагадить вроде могут только в своем процессе. Через ошибки переполнения буфера в ядре ОС чтоль?

Здравствуйте, IID,

Вообще-то я про .NET написал просто как пример использования JIT сейчас (то есть технологии есть и работают, нужно лишь подправить). Но мысль интересная... действительно, с выходом .NET MS говорили об одной безопасности, а с выходом Vista — о другой, заодно прикупив AV компанию

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

E>пользовательские процессы уже очень давно не могут модифицировать ядро

Они могут загрузить драйвер (разными путями). Руткит это обычно и есть драйвер — он скрывает себя и еще много чего (что бы не находили антивирусы и пользователь). Для скрытия ему обычно нужно модифицировать код или данные ядра, а для этого нужно найти место модификации.

E>и нагадить вроде могут только в своем процессе.

Да нет, внедрение в чужой процесс — распространённый вид атаки, описан у Рихтера и используется в большом количестве легального софта.

E>Через ошибки переполнения буфера в ядре ОС чтоль?

В том числе и через разные ошибки.

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

GN>Данный топик показал, что факт.

Ты о своем потоке сознания?

GN>>> Добро пожаловать в реальный мир: у пользователей воруют деньги, рассылают с зараженных машин спам и тд. Microsoft уже запретил патчить ядро.

VD>>Да, да. Microsoft это несомненно вселенское зло. И что из этого проистекает то?

GN>Здесь не LOR. Они добиваются тех же целей, о которых писал я. Методы другие.

Поток сознания продолжается?

GN>>> Только защиту от этого — PatchGuard — сломали и ломать будут, поскольку машинный код реализации поддаётся анализу малварой.

VD>>Здорово. И что?

GN>Защита — фуфло. Но можно лучше.

Здорово. И что?

VD>>Последний раз спрашиваю:
VD>>1. Что пытался сказать автор этой темы?
VD>>2. Каое отношение имет JIT к его рассуждениям.

GN>Можно получить разный машинный код ядра при каждой загрузке ОС.

Вот оно как... (с) анекдот.

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

IID>1) машинный код небезопасен, если он компилится сходным образом. Это постулат (лемма).

А с чего это бредовое предположение вдруг стало леммой?

IID>Что понимается под "небезопастностью" ? То что код может быть легко модифицирован малварью, (сплоетом, трояном и т.д.)

После этого умозаключения неплохо было бы задуматься, а является ли это проблемой? Например, посмотреть статистику разных атак и выяснить в каком проценте из них проблемой ялялось то, что был модифицирован код исполняемых модулей.

Насколько я знаю самой большой процент вредоносного софта запускается тупыми пользователями самостоятельно причем из под администратора.

IID> Прошу, не надо разводить флейм по поводу цифровых подписей и прочего.

А зачем это делать? Челове создавший эту тему не только в дотнете и иуравляемом коде нихрена не смыслет, но и вообще в принципах обеспечения безопасности и источниках проблем с нею.

Пришел орел... намечтал себе что-то там... вылил кашу из своих домыслов в виде потока сознания. И что? Что тут обсуждать?

ID>2).NET считается безопасным. Но т.к. запуск .NET программы в итоге выливается в исполнение машинного кода, сгенерированного сходным образом => (согласно лемме) .NET программы НЕБЕЗОПАСНЫ перед внешними угрозами.

Если у нас есть возможность править исполняемые модули или память процессов, то ничто не безопастно перед внешнеми угрозами. И .NET тут не причем.

Что касается безопастности в .NET, то тут уже дали правильный совет заняться собственным образованием и не нести пдобной пурги на форуме. Цели и средства защиты .NET совершенно другие.

ID> Они защищают программистов от самих же себя. Но не пользователя от злоумышленников. Пользователь .NET программы настолько же беззащитен, как и пользователь unmanaged софта.

Тебе тоже стоит почитать что-то о защите в .NET.
Тогда поймешь, что они вообще никого не от чего не защищают, а предоставляют механизым контроля и управления защитой.

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

VD>Ты о своем потоке сознания?

Да нет, я пишу о безопасности пользователя, при чём тут Дотнет...

GN>>Можно получить разный машинный код ядра при каждой загрузке ОС.

VD>Вот оно как... (с) анекдот.

И, оказывается, это приведет к неработоспособности целого класса софта.