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>Вот оно как... (с) анекдот.

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

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

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

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

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

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

Практика показала. Такой код легко модифицируем.

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

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

Неплохо бы ознакомиться с темой и её насущными проблемами, подобные вопросы отпадут.

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

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

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

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

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

Вкус устриц

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

Действительно, .NET ни причём, что к нему цепляться то? Лучше запретим модифицирование памяти

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

GN>>Да нет, внедрение в чужой процесс — распространённый вид атаки, описан у Рихтера и используется в большом количестве легального софта.
E>Если это работает и с процессами ядра ОС, я просто в шоке. Это же собственно сверхуязвимость, неужели если она есть, то до сих пор не исправили? Мне всегда казалось, что так можно поступать только с процессами с тем же или меньшим уровнем привилегий, чем мой.
Так и есть, причем еще нужно иметь специальную привилегию (SE_DEBUG_PRIVILEGE), которую можно запретить политиками безопасности. Но ведь пользователи в Винде работают под Администратором.

Хотя, IID несет бред, конечно. Если у процесса будет возможность выполнить код в режиме ядра, то никакие перекомпиляции уже не спасут.

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

C>Хотя, IID несет бред, конечно. Если у процесса будет возможность выполнить код в режиме ядра, то никакие перекомпиляции уже не спасут.

1) Где я писал про выполнение в режиме ядра ?
2) все-таки спасут. При попытке запустить руткит в абсолютно незнакомом ему окружении он или грохнет систему в синий экран или повистнет, или просто обломается (зависит от характера ошибок у автора руткита). Бонус — данные пользователя не будут украдены.

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

C>Так и есть, причем еще нужно иметь специальную привилегию (SE_DEBUG_PRIVILEGE), которую можно запретить политиками безопасности. Но ведь пользователи в Винде работают под Администратором.
Читал я это все лет 6 назад, и использовать знания не пришлось, могу ошибаться, но вроде приложения, запущенные под администратором все равно имеют меньший приоритет, чем системные процессы и драйверы. Админ может конечно свои драйверы установить и из них уже гадить в системные процессы, но придется перезагрузиться, чтобы это получилось. Я что, не прав?

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

E>приложения, запущенные под администратором все равно имеют меньший приоритет, чем системные процессы и драйверы.

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

E> Админ может конечно свои драйверы установить и из них уже гадить в системные процессы, но придется перезагрузиться, чтобы это получилось.

Перезагрузка давно уже не нужна.

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

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

Самое забавное, что для защиты от этого нужно очень эффективно всякий раз "перемешивать" код ядра. Вплоть до перепахивания всех без исключения устойчивых последовательностей бинарного кода, кои, как известно, есть следствие работы оптимизатора (в частности). Ergo, предлагается всякий раз получать систему с непредсказуемыми характеристиками? Вот уж, воистину, мечта поэта: две-три перезагрузки, и ОС начнёт работать быстро с вероятностью 59.8%.

Короче, это отдаёт не столько решением проблемы, сколько подведенеим основания для того, чем хочется позаниматься (регулярно перетранслируемым ядром и воплями неизвестно о чём, зато громко).

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

Угу. Ещё 25-й кадр нужно упомянуть.

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

C>>Хотя, IID несет бред, конечно. Если у процесса будет возможность выполнить код в режиме ядра, то никакие перекомпиляции уже не спасут.
IID>1) Где я писал про выполнение в режиме ядра ?
А user-mode руткитов не существует. И в Windows ты из user-mode не можешь патчить ядерные структуры.

IID>2) все-таки спасут. При попытке запустить руткит в абсолютно незнакомом ему окружении он или грохнет систему в синий экран или повистнет, или просто обломается (зависит от характера ошибок у автора руткита). Бонус — данные пользователя не будут украдены.
Чем оно "незнакомое"? Или структуры системных таблиц тоже каждый раз менять будем с помощью встроенного искусственного интеллекта?

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

GN>Да, т.к привилегии ОС и процессора это разные вещи. Первые — реализуются на основе софтовых проверок, 2е — аппаратно. Ядро ОС — это 0е кольцо защиты процессора, из 3го кольца недоступно, однако код выполняемый на уровне 0 может делать всё, что угодно (в том числе и модифицировать проверки).
Вообще-то я, как пользователь большинство программ запускаю из 3-его кольца защиты вроде (не 0-го точно), даже под админом. Более того, если мне не изменяет память, драйвера — это 1-е кольцо защиты, а не 0-е. Мои процессы да, могут вызывать функции ядра, выполняющиеся в 0-м кольце защиты. Так собственно эти функции ядра вроде как должны быть уже достаточно вылизаны со времен NT, чтобы не позволять легко запускать собственные процессы в 0-м кольце защиты, и уж тем более проверять, могу ли я гадить в процессы, выполняющиеся в более привилегированных кольцах. Я бы например на месте разработчиков ОС не поленился бы проверять именно кольцо защиты, не могу понять причины, по которой не проверяют это. Если не так, то это ИМХО мегабага.

PS Неужели в Линуксе тоже самое ?

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

ГВ>Самое забавное, что для защиты от этого нужно очень эффективно всякий раз "перемешивать" код ядра.

Во-первых, достаточно только при установке. Необходимость компиляции каждый раз при загрузке ОС нужно отдельно изучать.
Во-вторых, что значит "очень" эффективно? Достаточно это делать эффективнее, чем анализируется код. Можно предусмотреть апдейты компилятора.

ГВ>Вплоть до перепахивания всех без исключения устойчивых последовательностей бинарного кода, кои, как известно, есть следствие работы оптимизатора (в частности).

Это, кстати, самое простое, для этого не нужен исходный код, и это уже помешает большому проценту малвари.

ГВ>Ergo, предлагается всякий раз получать систему с непредсказуемыми характеристиками?

Это лишняя сложность, достаточно с предсказуемыми.

ГВ>Ещё 25-й кадр нужно упомянуть.

Зачем?

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

E>Вообще-то я, как пользователь большинство программ запускаю из 3-его кольца защиты вроде (не 0-го точно), даже под админом.

Верно, и эти программы могут привести к загрузке драйвера.

E>Более того, если мне не изменяет память, драйвера — это 1-е кольцо защиты, а не 0-е.

В Виндовсе только 2 кольца защиты — 3е и 0е.

E>Мои процессы да, могут вызывать функции ядра, выполняющиеся в 0-м кольце защиты. Так собственно эти функции ядра вроде как должны быть уже достаточно вылизаны со времен NT, чтобы не позволять легко запускать собственные процессы в 0-м кольце защиты и уж тем более проверять, могу ли я гадить в процессы, выполняющиеся в более привилегированных кольцах.

Если говорить о багах — то многое вылизано. А если о загрузке драйвера — то как узнать, что будет делать этот драйвер? На данном этапе нет возможности изменять чужие драйвера, тем более переписывать их на Шарпе.

E>Я бы например на месте разработчиков ОС не поленился бы проверять именно кольцо защиты, не могу понять причины, по которой не проверяют это. Если не так, то это ИМХО мегабага.

Если речь о переодической проверки целостности ядра — так и делает PatchGuard, но он обходится из ядра.

E>PS Неужели в Линуксе тоже самое ?

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

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

ГВ>>Самое забавное, что для защиты от этого нужно очень эффективно всякий раз "перемешивать" код ядра.
GN>Во-первых, достаточно только при установке. Необходимость компиляции каждый раз при загрузке ОС нужно отдельно изучать.
GN>Во-вторых, что значит "очень" эффективно? Достаточно это делать эффективнее, чем анализируется код. Можно предусмотреть апдейты компилятора.

"Очень" эффективно, это чтобы не было никакой возможности, например, привязаться к какой-то определённой последовательности и, например, взяв некоторое смещение от её начала получить точку входа в некоторую системную функцию. "Никакой возможности" означает, например, что вероятность повторения такой последовательности не больше, чем, скажем 2% (конкретную цифру назвать не могу — нужно прикидывать в зависимости от предполагаемых потребностей вируса) Заметь, что это должно происходить при трансляции одного и того же исходного кода.

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

ЧТО????????????????? Это — самое простое? Так... Разговаривать больше не о чем.

ГВ>>Ergo, предлагается всякий раз получать систему с непредсказуемыми характеристиками?
GN>Это лишняя сложность, достаточно с предсказуемыми.

Ну ты же предлагаешь чуть ли не оптимизатором играть! Впрочем — ладно. Закрываем тему. Ты, похоже, даже не понимаешь, какую чушь тут городишь.

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

C>А user-mode руткитов не существует.

Да и Земля плоская.

C>И в Windows ты из user-mode не можешь патчить ядерные структуры.

Можно через Device\PhysicalMemory.

C>Чем оно "незнакомое"? Или структуры системных таблиц тоже каждый раз менять будем с помощью встроенного искусственного интеллекта?

В основном я имел ввиду патч кода, но морфинг структур тоже очень желателен, для начала можно просто менять поля местами.

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

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

ГВ>>>Самое забавное, что для защиты от этого нужно очень эффективно всякий раз "перемешивать" код ядра.
GN>>Во-первых, достаточно только при установке. Необходимость компиляции каждый раз при загрузке ОС нужно отдельно изучать.
GN>>Во-вторых, что значит "очень" эффективно? Достаточно это делать эффективнее, чем анализируется код. Можно предусмотреть апдейты компилятора.

ГВ>"Очень" эффективно, это чтобы не было никакой возможности, например, привязаться к какой-то определённой последовательности и, например, взяв некоторое смещение от её начала получить точку входа в некоторую системную функцию. "Никакой возможности" означает, например, что вероятность повторения такой последовательности не больше, чем, скажем 2% (конкретную цифру назвать не могу — нужно прикидывать в зависимости от предполагаемых потребностей вируса) Заметь, что это должно происходить при трансляции одного и того же исходного кода.

ГВ>>>Вплоть до перепахивания всех без исключения устойчивых последовательностей бинарного кода, кои, как известно, есть следствие работы оптимизатора (в частности).

всех и не нужно. Круг интересных малвари сервисов ОС довольно неплохо очерчен.

GN>>Это, кстати, самое простое, для этого не нужен исходный код, и это уже помешает большому проценту малвари.

ГВ>ЧТО????????????????? Это — самое простое? Так... Разговаривать больше не о чем.

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

ГВ>>>Ergo, предлагается всякий раз получать систему с непредсказуемыми характеристиками?
GN>>Это лишняя сложность, достаточно с предсказуемыми.

ГВ>Ну ты же предлагаешь чуть ли не оптимизатором играть! Впрочем — ладно. Закрываем тему. Ты, похоже, даже не понимаешь, какую чушь тут городишь.

Он то как раз понимает

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

C>>И в Windows ты из user-mode не можешь патчить ядерные структуры.
GN>Можно через Device\PhysicalMemory.
Ну так его запретить не сложно. Кроме того, без администратора все равно его не затронуть.

Ну а с админом уже что угодно можно творить.

C>>Чем оно "незнакомое"? Или структуры системных таблиц тоже каждый раз менять будем с помощью встроенного искусственного интеллекта?
GN>В основном я имел ввиду патч кода, но морфинг структур тоже очень желателен, для начала можно просто менять поля местами.
Еще раз, чем тебе морфинг кода поможет? Руткиты его вообще редко трогают код — обычно меняют структуры данных. А смена полей элементарно отслеживается.

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

ГВ>"Очень" эффективно, это чтобы не было никакой возможности, например, привязаться к какой-то определённой последовательности и, например, взяв некоторое смещение от её начала получить точку входа в некоторую системную функцию.

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

ГВ>"Никакой возможности" означает, например, что вероятность повторения такой последовательности не больше, чем, скажем 2% (конкретную цифру назвать не могу — нужно прикидывать в зависимости от предполагаемых потребностей вируса)

Да, достаточно, что бы эта возможность не всегда была.

ГВ>Заметь, что это должно происходить при трансляции одного и того же исходного кода.

Разумеется, это требование к компилятору.

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

ГВ>ЧТО????????????????? Это — самое простое?

А какие проблемы в поиске и замене? Простейший пример — add на sub

ГВ>Так... Разговаривать больше не о чем.

Почитай лучше что люди делают http://www.strongbit.com/execryptor_inside.asp

ГВ>Ну ты же предлагаешь чуть ли не оптимизатором играть!

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

ГВ>Впрочем — ладно. Закрываем тему. Ты, похоже, даже не понимаешь, какую чушь тут городишь.

Что ж никто из гуру не просветил меня до сих пор?

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

C>Ну а с админом уже что угодно можно творить.

Положим этому конец

C>Еще раз, чем тебе морфинг кода поможет? Руткиты его вообще редко трогают код

Действительно, последнее время модификация кода редко используется, так как детектится сравнением с оригиналом. Однако код всё равно анализируется — найти адрес "оригинального обработчика" или неэкспортируемую переменную ядра. Это нетривиально в полиморфленом коде.

C>обычно меняют структуры данных.

Для DKOM нужно найти неэкспортируемые переменные. Патч таблицы мажоров и подобное обычно требует "оригинальные обработчики". Хотя для надёжности лучше менять бинарное представление структур, но такой морфинг сложно реализовать, проще компилировать заново.

C>А смена полей элементарно отслеживается.

На это нужно время, и не факт, что проверяющий код будет выполняться.

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

GN>Почитай лучше что люди делают http://www.strongbit.com/execryptor_inside.asp

In addition you do not have to worry about the size or speed of your program because you don't need to transform its entire code. You have to protect only critical parts of your code, responsible for serial number verification, trial expiration date, and other evaluation restrictions. The rest of application code remains intact and software execution speed remains the same.

Этим авторы прямо расписываются в том, что морфинг влияет на производительность не в лучшую сторону (что, в принципе, очевидно). Ты предлагаешь таким образом играться с ядром ОС? Спасибо, смешно.

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

ГВ>>>>Вплоть до перепахивания всех без исключения устойчивых последовательностей бинарного кода, кои, как известно, есть следствие работы оптимизатора (в частности).

IID>всех и не нужно. Круг интересных малвари сервисов ОС довольно неплохо очерчен.

Так мы говорим о принципиальной возможности влезть в адресное пространство ядра или о защите определённых сервисов?

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

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

ГВ>>>>>Вплоть до перепахивания всех без исключения устойчивых последовательностей бинарного кода, кои, как известно, есть следствие работы оптимизатора (в частности).

IID>>всех и не нужно. Круг интересных малвари сервисов ОС довольно неплохо очерчен.

ГВ>Так мы говорим о принципиальной возможности влезть в адресное пространство ядра или о защите определённых сервисов?

мы говорим об эффективном противодействии руткитам, малвари, и другому зловредному коду.

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

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

GN>>Почитай лучше что люди делают http://www.strongbit.com/execryptor_inside.asp

ГВ>

ГВ>In addition you do not have to worry about the size or speed of your program because you don't need to transform its entire code. You have to protect only critical parts of your code, responsible for serial number verification, trial expiration date, and other evaluation restrictions. The rest of application code remains intact and software execution speed remains the same.

ГВ>Этим авторы прямо расписываются в том, что морфинг влияет на производительность не в лучшую сторону (что, в принципе, очевидно). Ты предлагаешь таким образом играться с ядром ОС? Спасибо, смешно.

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

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

ГВ>авторы прямо расписываются в том, что морфинг влияет на производительность не в лучшую сторону

Сначала не хотел говорить, теперь началась демагогия. Итак, мы видели факт — морфинг возможен и работает на практике

ГВ>(что, в принципе, очевидно).

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

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

GN>Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>авторы прямо расписываются в том, что морфинг влияет на производительность не в лучшую сторону

GN>Сначала не хотел говорить, теперь началась демагогия. Итак, мы видели факт — морфинг возможен и работает на практике

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

ГВ>>(что, в принципе, очевидно).

GN>И какие же причины? Если размер кода — дык, его не обязательно раздувать.

А вы сами посмотрите на вашу практику. 5 комманд заменяются на 26.

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

Z>Дык вроде никто не спорил, что возможен =). Только ценой нехилого снижения производительности.

Ещё раз — речь о возморжности рекомпиляции, то есть декомпилировать бинарник в некий граф и скомпилировать его после трансформации. Если Экзекриптор при компиляции раздувает код — так это поэтому, что у него цель такая! а не какой-то побочный неустранимый эффект.

Z>Опять же остается открытым вопрос насколько такой обфускатинг полезен для защиты.

Если для атаки необходимо найти функцию или переменную, но нет возможности это сделать — очевидно, атака не сможет быть произведена

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


GN>Если для атаки необходимо найти функцию или переменную, но нет возможности это сделать — очевидно, атака не сможет быть произведена

Для "атаки" обычно необходимо подменить функцию. Точку входа же из таблицы экспорта не спрячешь.

p.s.
Моя идея в том что вся эта кодогенерация — это всего лишь костыли. При чем по трудозатратам они сравнимы с выпрямлением архитектуры ядра. Т.е. гораздо перспективнее загружать драйверы с более низким уровнем привелегий и настроить правильно права доступа, чем пытаться запутать злоумышленика. Security by obscurity не наш метод =)

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

Z>Для "атаки" обычно необходимо подменить функцию.

Перед тем как подменить, нужно эту функцию найти.

Z>Точку входа же из таблицы экспорта не спрячешь.

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

Z>p.s.
Z>Моя идея в том что вся эта кодогенерация — это всего лишь костыли. При чем по трудозатратам они сравнимы с выпрямлением архитектуры ядра. Т.е. гораздо перспективнее загружать драйверы с более низким уровнем привелегий

Изменить дизайн ядра ОС — проще? Пока даже не стоит рассматривать проблемы с запуском существующих драйверов.

Z> и настроить правильно права доступа

Спрос рождает предложение. Пользователь хочет работать под админом, смотреть порносайты и запускать всякий хлам.

Z>чем пытаться запутать злоумышленика.

Это — о незнании пароля пользователя "Администратор"?

Z>Security by obscurity не наш метод =)

Алгоритм защиты открыт

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

Z>> и настроить правильно права доступа
GN>Спрос рождает предложение. Пользователь хочет работать под админом, смотреть порносайты и запускать всякий хлам.

Я вот одного не могу понять. Изначально говорилось о защите данных пользователя, было дело?
Ну так если нечто вредоносное запустится под логином Администратора (оттого что пользователь запускает всякий хлам) — то оно получит такие замечательные возможности к получению-отсылке пользовательских данных, что зачем ему вообще пытаться менять ядро?

Это похоже на предложение заменить копье на винтовку чтобы наконец победить ветряные мельницы...

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

ГВ>>Так мы говорим о принципиальной возможности влезть в адресное пространство ядра или о защите определённых сервисов?
IID>мы говорим об эффективном противодействии руткитам, малвари, и другому зловредному коду.
Malware у нас вообще в userspace сидит и не высовывается. Как мы ему будем противодействовать?

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

ГВ>>авторы прямо расписываются в том, что морфинг влияет на производительность не в лучшую сторону
GN>Сначала не хотел говорить, теперь началась демагогия. Итак, мы видели факт — морфинг возможен и работает на практике
В старую добрую эпоху DOS были полиморфные вирусы. Однако, это не мешало антивирусам их находить. Ты думаешь, что вирусописатели не смогут обойти морфинг, выполняющийся по заранее известным алгоритмам?

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

F>Я вот одного не могу понять. Изначально говорилось о защите данных пользователя, было дело?
F>Ну так если нечто вредоносное запустится под логином Администратора (оттого что пользователь запускает всякий хлам) — то оно получит такие замечательные возможности к получению-отсылке пользовательских данных, что зачем ему вообще пытаться менять ядро?

Совершенно верно. Поэтому умные дядьки никогда не пытаются выстраивать защиту для администратора — бесполезно.

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

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

ГВ>>>Так мы говорим о принципиальной возможности влезть в адресное пространство ядра или о защите определённых сервисов?
IID>>мы говорим об эффективном противодействии руткитам, малвари, и другому зловредному коду.
C>Malware у нас вообще в userspace сидит и не высовывается. Как мы ему будем противодействовать?

malware — собирательное название. Это не классификация по userland/kernel. Многие трояны таскают с собой драйвер для kernel-mode руткита, или инжектят код usermode руткита для скрытия и собственной защиты. В обоих случаях применятся анализ кода.

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

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

ГВ>>>авторы прямо расписываются в том, что морфинг влияет на производительность не в лучшую сторону
GN>>Сначала не хотел говорить, теперь началась демагогия. Итак, мы видели факт — морфинг возможен и работает на практике
C>В старую добрую эпоху DOS были полиморфные вирусы. Однако, это не мешало антивирусам их находить. Ты думаешь, что вирусописатели не смогут обойти морфинг, выполняющийся по заранее известным алгоритмам?

Полиморф мимо кассы! (ниже детально объясню почему)

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

Про вирусы и эмуляторы: Тем не менее до сих пор антивирусный эмулятор имеет некий таймаут, чтобы не трассировать код вируса вечно. И некоторые вирусы делают расшифровку настолько "долгоиграющей" что эмуль забивает на такой вирус и не детектит его. И все-таки полиморфные декрипторы — это убожество. Вот метаморфные вирусы (метаморфинг — полное изменение кода) гораздно тяжелее детектить. До сих пор существует метаморфный вирус, написанный Zombie, который не по зубам современным антивирусам. А gear nuke говорил именно о полном изменении кода, т.е. о метаморфинге.

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

F>Я вот одного не могу понять. Изначально говорилось о защите данных пользователя, было дело?

Да, о защите пользователя и его данных от вредоносного софта.

F>Ну так если нечто вредоносное запустится под логином Администратора (оттого что пользователь запускает всякий хлам) — то оно получит такие замечательные возможности к получению-отсылке пользовательских данных, что зачем ему вообще пытаться менять ядро?

Спасибо, хороший вопрос.

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

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

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

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

F>Это похоже на предложение заменить копье на винтовку чтобы наконец победить ветряные мельницы...

Скорее, построить ограду вокруг, что бы ветер не дул

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

AVK>умные дядьки никогда не пытаются выстраивать защиту для администратора — бесполезно.

Угу, они тусуются тут, на форуме, а часть остальных давно уже создали целую индустрию — AV и тп

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

GN>Скорее, построить ограду вокруг, что бы ветер не дул
Еще один дилетанский вопрос. Предположим, что ядро ОС каждый раз при запуске разное. Если не ошибаюсь, точки вызова системных функций при каждом запуске все время будут находиться по разным адресам. Но ... собственно эти точки входа то все равно будет можно найти, иначе как тогда к этому ядру вообще обращаться то? Это же все равно после компиляции обычный машинный код с кучей зависимостей, все равно вызываться в конечном счете все будет через call ADR, прямо из скомпилированного кода или из библиотек фреймворка. Во что это потом компилируется не знаю, но в случае если это обычный вызов, простейший обходной маневр — я пишу простейший свой управляемый код для вызова нужной системной функции ядра, потом запускаю неуправляемый свой код, который смотрит на то, во что скомпилировался мой управляемый, анализирую полученный адрес, и все, смогу гадить в ядро как раньше, разве нет?
Если же все не так просто и это все внутри работает похожим на IDispatch образом, да еще не возвращая прямой указатель, я что — точно никак адрес узнать не смогу? Сомневаюсь как-то. Управляющая то среда — обычная dll вроде, в любом случае защита не аппаратная, и все структуры данных, используемые .NET хорошо поддаются изучению и так же прекрасно должны смотреться, как сейчас ядро. Что мне помешает дизассемблировать исходники к тому же?

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

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

IID>>>мы говорим об эффективном противодействии руткитам, малвари, и другому зловредному коду.
C>>Malware у нас вообще в userspace сидит и не высовывается. Как мы ему будем противодействовать?
IID>malware — собирательное название. Это не классификация по userland/kernel. Многие трояны таскают с собой драйвер для kernel-mode руткита, или инжектят код usermode руткита для скрытия и собственной защиты. В обоих случаях применятся анализ кода.
Можешь вспомнить последний распространенный почтовый червь с kernel-mode частью? Я вот не могу.

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

GN>Смысл действий руткита — компрометировать систему так, что указанные выше действия становятся невозможны. Это достигается путём перехвата системных функций и\или модификации внутренних структур ядра. В результате получается ситуация, что малвара работает, а анитивирус и фаервол молчат. Даже специализированный софт — руткит-детекторы не способны задетектить руткит в общем случае, они ищут конкретные реализации.
Можно вопрос? А как тогда Руссинович обнаружил Сонявский руткит?

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

IID>Полиморф мимо кассы! (ниже детально объясню почему)
IID>полиморфным у этих вирусов был только распаковщик.
Не только. Лично помню, что у меня товарищ писал вирус, который модифицировал свой код (вставлял мусорные фрагменты, менял инструкции на аналогичные).

IID>Находить их довольно просто — достаточно прогнать код вируса на эмуляторе, и дождаться его саморасшифровки. малварь же не будет иметь возможность таскать с собой эмуль, воспроизводящий enviroment ядра и трассировать в нем код ядра. Не нужно делать задачу неразрешимой — достаточно сделать ее настолько трудоемкой, что реализация окажется невыгодной.
Почему это "не будет"? Кто ему запрещает?

Кстати, антивирусы еще могут искать паттерн кода вируса, заданый в виде аналога регэкспов.

IID>Про вирусы и эмуляторы: Тем не менее до сих пор антивирусный эмулятор имеет некий таймаут, чтобы не трассировать код вируса вечно. И некоторые вирусы делают расшифровку настолько "долгоиграющей" что эмуль забивает на такой вирус и не детектит его. И все-таки полиморфные декрипторы — это убожество. Вот метаморфные вирусы (метаморфинг — полное изменение кода) гораздно тяжелее детектить. До сих пор существует метаморфный вирус, написанный Zombie, который не по зубам современным антивирусам. А gear nuke говорил именно о полном изменении кода, т.е. о метаморфинге.
Что это за вирус такой? Уж не Generator.Zombie?

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

C>Можешь вспомнить последний распространенный почтовый червь с kernel-mode частью? Я вот не могу.

Видишь суслика ? И я не вижу. А он есть...
Если серъезно — почтовые черви тут не при чем. Компьютеры пользователей заражаются сотнями тысяч в сутки. Через уязвимости в браузерах, в ОС, в каком-либо ПО, через социальную инженерию, с помощью почтовых червей — способов много. На зараженный компьютер устанавливается крохотный "Downloader", который закачивает и запускает код по прихоти нового "владельца" компьютера. Целая категория людей занимается тем, что продает "заражения" (запуск) троянописателям. Это уже бизнес. Поштучно компьютеры никто не считает, минимум тысячами. Если малварь оперативно лечат — троянописатели вынуждены постоянно покупать новые и новые заражения. Т.о. задача троянописателя — сделать свой зверек как можно более живучим и скрытным. А тут руткиты очень кстати. Некоторые черви остаются непойманными по 6 месяцев и более, в т.ч. за счет руткитов.

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

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

Z>>Для "атаки" обычно необходимо подменить функцию.

GN>Перед тем как подменить, нужно эту функцию найти.

Z>>Точку входа же из таблицы экспорта не спрячешь.

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

Обычно экспортируемые символы нужны для замены точек входа и коррекции входных и выходных данных функции т.е. т.н. "перехвата". А зачем искать неэкспортируемые функции?

GN>Изменить дизайн ядра ОС — проще? Пока даже не стоит рассматривать проблемы с запуском существующих драйверов.

Ну по крайней мере результат гарантирован

Z>>Security by obscurity не наш метод =)

GN> Алгоритм защиты открыт

Тогда докажите "взломостойкость" алгоритма, с учетом сохранения быстройдействия и совместимости с существующими драйверами. Давайте уже набросайте примерную реализацию, чтобы обсуждение не было похоже на игру детей в войнушку "- А я тебя танками. — А я тебя самолетами. — А я тебя ракетами...". Вы расскажете как вы это собираетесь делать. Мы раскажем как это можно обойти.

Честно говоря я не понимаю, как обеспечивать быстройдействие полиморфного кода. На x86 конечно можно записать одно и то же разными командами. Только вот по скорости они будут различаться очень и очень сильно.

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

ГВ>>авторы прямо расписываются в том, что морфинг влияет на производительность не в лучшую сторону
GN>Сначала не хотел говорить, теперь началась демагогия. Итак, мы видели факт — морфинг возможен и работает на практике

С принципиальной возможностью "морфинга вообще" я не спорю. Вопрос в балансе между "глубиной" морфинга, его влиянием на работу ОС и надёжностью решения исходной задачи.

ГВ>>(что, в принципе, очевидно).
GN>И какие же причины? Если размер кода — дык, его не обязательно раздувать.

Причина в том, что мы вынуждены расширять набор вариантов, из которых ранее делал выбор оптимизатор. Это просто логическое следствие замены, например, add на sub.

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

C>А как тогда Руссинович обнаружил Сонявский руткит?

здесь
RootkitRevealer его задетектил. Судя по описанию, руткит там примитивный. RootkitRevealer можно обойти очень тупо (и Марк сам пишет об этом, но не делает никаких попыток защититься) — детектить запуск и подсунуть инфу, которую он скушает без возмущения. На практике действуют более тонко (т.к. Марк лукавит: "RootkitRevealer compares the results of a system scan at the highest level with that at the lowest level") и хукают ниже уровнем.

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

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

А ядро и сейчс может быть разное при каждом запуске (в boot.ini опция /KERNEL + при обновлениях ОС оно иногда меняется). Решение простое — в ядре есть диспетчер, который вызывается из юзерспейса через шлюз (адрес шлюз знать не нужно, это особенность команд вызова — int 0x2e или sysenter).

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

Еще один (легальный) способ получить адрес функций ядра из драйвера — функция MmGetSystemRoutineAddress. Однако она работает только для 2х модулей — ntoskernel.exe и hal.dll, а руткиту помимо первого очень интересны сетевые модули (ndis.sys, tcpip.sys и тд)

[]

E>если это обычный вызов, простейший обходной маневр — я пишу простейший свой управляемый код для вызова нужной системной функции ядра, потом запускаю неуправляемый свой код, который смотрит на то, во что скомпилировался мой управляемый, анализирую полученный адрес

Даже проще можно. Имя функции в таблице экспорта не содержит информацию о типе, поэтому можно импортировать функцию как указатель, а не дизассемблировать команду вызова.

E>и все, смогу гадить в ядро как раньше, разве нет?

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

[]
E>все структуры данных, используемые .NET хорошо поддаются изучению и так же прекрасно должны смотреться, как сейчас ядро.

Не понял, при чём тут .NET

E>Что мне помешает дизассемблировать исходники к тому же?

Дык а как привязать исходный код ядра к конкретным адресам?

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

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

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

ГВ>Вопрос в балансе между "глубиной" морфинга, его влиянием на работу ОС

Если компилятор (или морфер) не содержит ошибок, то производимый ими код будет эквивалентен по наблюдаемому поведению.

ГВ>и надёжностью решения исходной задачи.

Если сейчас тупо скомпилировать ядро другим компилятором, подавляющее большенство малвары перестанет работать.

ГВ>мы вынуждены расширять набор вариантов, из которых ранее делал выбор оптимизатор.

Это не даст заметной потери производительности, до сих пор никого не напрягало, что ядро компилируется с неполной оптимизацией, да и тот же PatchGuard отнимает процессорное время.

ГВ>Это просто логическое следствие замены, например, add на sub.

Ээ.. это про невозможность заменить один из 256 возможных коротких вариантов sub коротким add (и наоборот)? Эти несколько быйт — копейки и на скорость практически не влияют.

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

Z>Обычно экспортируемые символы нужны для замены точек входа и коррекции входных и выходных данных функции т.е. т.н. "перехвата". А зачем искать неэкспортируемые функции?

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

GN>>Изменить дизайн ядра ОС — проще? Пока даже не стоит рассматривать проблемы с запуском существующих драйверов.

Z>Ну по крайней мере результат гарантирован

Верно, на такой ОС не будет малвары... она как Неуловимый Джо

Z>>>Security by obscurity не наш метод =)

GN>> Алгоритм защиты открыт

Z>Тогда докажите "взломостойкость" алгоритма

А зачем? Стойкость того же RSA никем не доказана, но он признан таковым

Z>с учетом сохранения быстройдействия

Ядро и так компилируется с неполной оптимизацией. Потеря производительности допустима, когда речь идёт о защите. Тот же PatchGuard отнимает процессорное время.

Z>и совместимости с существующими драйверами.

Microsoft запретил патчить ядро. У тех, кто не патчит, откуда проблемы возьмутся?

Z>Давайте уже набросайте примерную реализацию

Щас, отыщу сорцы ОС и компилятора

Z>чтобы обсуждение не было похоже на игру детей в войнушку "- А я тебя танками. — А я тебя самолетами. — А я тебя ракетами...". Вы расскажете как вы это собираетесь делать.

Ок, рассмотрим простейший практический пример (патч tcpip.sys против EventID 4226).

Проверка, которую нужно "обломать" выглядит так:

  mov     eax, _ActiveOpenProgressCount
  cmp     eax, _ActiveOpenProgressThreshold
  jge     [short] XX

Поиск этого места (включая патч) может выглядеть так:

for ( uintptr_t i = code_section_begin; i < code_section_end; ++i )
{
  if ( 0xA1 == *reinterpret_cast<uint8_t*>(i)
    && 0x053B == *reinterpret_cast<uint16_t*>(i+5) )
  {
    const uint32_t offset = *reinterpret_cast<uint32_t*>(i+7);
    if ( offset < data_section_begin|| offset > data_section_end )
      continue;
    if ( 10 == *reinterpret_cast<uint32_t*>(offset) )
    {
      *reinterpret_cast<uint32_t*>(offset) = 65535;
      break;
    }
  }
}

Как видно, здесь просто захардкожены опкоды и нет никакой привязки в каким-либо экспортируемым символам.

Теперь заменим регистр eax на любой другой и cmp на sub или add и:

Z>Мы раскажем как это можно обойти.

Первый вариант получится немного сложнее моего оригинала. Следующий этап — добавляем простой мусор (команды без влияния на используемые регистры) между mov и cmp.
Далее — мусорные команды становятся важными:

  mov     eax, _ActiveOpenProgressCount
  mov     ecx, eax
  cmp     ecx, _ActiveOpenProgressThreshold
  jge     [short] XX

Для начала хватит?

Z>Честно говоря я не понимаю, как обеспечивать быстройдействие полиморфного кода.

Преждевременная оптимизация — корень всех зол. В крайнем случае критичные по скорости участки можно не трогать.

Z>На x86 конечно можно записать одно и то же разными командами. Только вот по скорости они будут различаться очень и очень сильно.

Могут различаться, если мануалы производителя не читать.

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

...
Насколько я понял, основная идея, что JIT компиляция должна помочь скрыть адреса тех функциях ядра, адрес которых невозможно получить из таблицы экспорта, например которые вызываются грубо говоря через установку в определенный регистр процессора известного номера функции и передачи управления по известному адресу (int 0x2e)? Или даже для скрытия недокументировынных функций, которые нигде не описаны, но которые можно найти путем анализа кода (а то и вообще адрес известен), который чаще всего не меняется? А для тех функций, которые явно содержатся в таблице экспорта вся эта JIT компиляция не поможет абсолютно?

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

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

Поскольку малвара уже запущена, а ОС не может ей рпотивостоять, малвара уничтожает или отправляет в сеть своему хозяину данные пользователя в виле файла. JVM/CLR тут никаким боком, млаваре внедряться никуда не надо, если речь идет о безопасности данных пользователя — то проще их взять как файл не внедряясь в программы.

GN>Если обеспечить невозможность перехвата, современные руткиты не смогут работать.
Невозможность перехвата будут обеспечивтаь механизмы ОС, которые "неспособны противостоять атакам" как написано выше.
Иными словами, неворзможность перехвата обеспечить нельзя — проблему курицы и яйца.


GN>Представим, что компилятор при повторной компиляции производит заметно отличающийся бинарник, и компиляция ядра системы происходит заново при установке, либо при каждом запуске.

Тогда малвара просто встраивается в Java p-code или CLR MSIL и компилируется вместе с ним.

GN> Такое возможно уже сейчас, например у *них (где руткиты мало распространены).
GN> Поиск адресов для перехвата может стать нетривиальным (подобный принцип — рандомизация адресов загрузки системных модулей — используется против т.н exploits).
Правильно, не против руткитов, а против эксплойтов, чтобы через переполнение буфера встроившись в программу замучаться определять адреса API чтобы внедриться в ОС. Вопрос не скрытия себя и мониторинга других (rootkits), а записи и повторного запуска себя самого, локализация заражения одним запущенным в виртуальной памяти процессом.


IMHO разные части этого сообщения говорят о совершенно разных вещах, слабо связанных друг с другом.

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

A>Поскольку малвара уже запущена, а ОС не может ей рпотивостоять, малвара уничтожает

Это никому не нужно.

A>или отправляет в сеть своему хозяину данные пользователя в виле файла.

Она не сможет это сделать при установленном фаерволле.

A>JVM/CLR тут никаким боком, млаваре внедряться никуда не надо, если речь идет о безопасности данных пользователя — то проще их взять как файл не внедряясь в программы.

Поэтому малвара пропатчит ядро и выйдет в сеть в обход фаерволла.

A>Невозможность перехвата будут обеспечивтаь механизмы ОС, которые "неспособны противостоять атакам" как написано выше.
A>Иными словами, неворзможность перехвата обеспечить нельзя — проблему курицы и яйца.

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

GN>>Представим, что компилятор при повторной компиляции производит заметно отличающийся бинарник, и компиляция ядра системы происходит заново при установке, либо при каждом запуске.

A>Тогда малвара просто встраивается в Java p-code или CLR MSIL и компилируется вместе с ним.

Исключено, компиляция происходит до попадания малвары в систему.

A>не против руткитов, а против эксплойтов, чтобы через переполнение буфера встроившись в программу замучаться определять адреса API чтобы внедриться в ОС.

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

A>Вопрос не скрытия себя и мониторинга других (rootkits), а записи и повторного запуска себя самого

Ну это как раз не проблема.

A>локализация заражения одним запущенным в виртуальной памяти процессом.

Что есть заражение? По каким признакам это можно автоматически определить? А перехват функций — это однозначно ахтунг (кстати, речь о превентивном механизме, а не об анализе когда-то потом)

A>IMHO разные части этого сообщения говорят о совершенно разных вещах, слабо связанных друг с другом.

Там много места между строк

A>>или отправляет в сеть своему хозяину данные пользователя в виле файла.
GN>Она не сможет это сделать при установленном фаерволле.
Файрвол выключеН, поскольку ОС не смогла его защитить от малвары. http://bash.org.ru/quote.php?num=211190

A>>JVM/CLR тут никаким боком, млаваре внедряться никуда не надо, если речь идет о безопасности данных пользователя — то проще их взять как файл не внедряясь в программы.
GN>Поэтому малвара пропатчит ядро и выйдет в сеть в обход фаерволла.
Так чем JVM/CLR помодет в защите безопасности ?

A>>Невозможность перехвата будут обеспечивтаь механизмы ОС, которые "неспособны противостоять атакам" как написано выше.
A>>Иными словами, неворзможность перехвата обеспечить нельзя — проблему курицы и яйца.
GN>Для того, что бы перехватить некоторую функцию, необходим её адрес. Нет адреса — перехват невозможен.
Reflection, однако. Берем у VM и запрашиваем замену стандартной функции нa свою

A>>Тогда малвара просто встраивается в Java p-code или CLR MSIL и компилируется вместе с ним.
GN>Исключено, компиляция происходит до попадания малвары в систему.

Ей это поможет после перезагрузки. Непосредственно при заражении, конечно, надо как-то по другому отработать.

Но как в JIT'е реализован вызов еще не откомпилированной функции ? скорее всего по имени функции.
Так же малвара вызовет любую функцию по ее имени — и среди этих функций будут стандартные функции для загрузки пакетов, изменения кода классов налету и т.д.

A>>Вопрос не скрытия себя и мониторинга других (rootkits), а записи и повторного запуска себя самого
GN>Ну это как раз не проблема.

Так "не проблема" или "исключено" ?

A>>локализация заражения одним запущенным в виртуальной памяти процессом.

GN>Что есть заражение? По каким признакам это можно автоматически определить? А перехват функций — это однозначно ахтунг (кстати, речь о превентивном механизме, а не об анализе когда-то потом)

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

Заражение — запуск в системе пришедшего снаружи кода, который пользователь/администратор не хотели запускать.

A>>IMHO разные части этого сообщения говорят о совершенно разных вещах, слабо связанных друг с другом.
GN>Там много места между строк
возможно, слишком.

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

А загрузчик MSIL-пакетов у нас ведь нативный будет, и цифровой подписью не защищён, его-то модифицировать никто не запрещает.

Z> Т.е. гораздо перспективнее загружать драйверы с более низким уровнем привелегий

Ну вроде так пытались делать в OS/2

А вот в OS/2 NT (равно как и в Linux/i386) вернулись к двум уровням привелегий — 0 и 3, userland и supervisor
Потому что чем больше разныхз уровней — тем чаще приходится переключать контексты и притормаживать процессор.

не говоря уже про Micro Kernel (где на x86 кроме QNX и так пока не родившегося Hurd ? )

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

A>А загрузчик MSIL-пакетов у нас ведь нативный будет, и цифровой подписью не защищён, его-то модифицировать никто не запрещает.

Ну и кто виноват? При правильном дизайне он будет защищен цифровой подписью и средствами ОС от модификации. Для начала попробуй удалить ядро текущей ОС.

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

A>Файрвол выключеН, поскольку ОС не смогла его защитить от малвары. http://bash.org.ru/quote.php?num=211190

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

A>>>JVM/CLR тут никаким боком, млаваре внедряться никуда не надо, если речь идет о безопасности данных пользователя — то проще их взять как файл не внедряясь в программы.
GN>>Поэтому малвара пропатчит ядро и выйдет в сеть в обход фаерволла.
A>Так чем JVM/CLR помодет в защите безопасности ?

Понятия не имею и не предлагал это использовать. Упомянул их, как пример использования JIT (то есть у MS давно есть наработки)

GN>>Для того, что бы перехватить некоторую функцию, необходим её адрес. Нет адреса — перехват невозможен.
A>Reflection, однако. Берем у VM и запрашиваем замену стандартной функции нa свою

См. выше. Я говорю о компиляции того ядра, что есть уже сейчас. Написано оно на С и С++.

A>>>Тогда малвара просто встраивается в Java p-code или CLR MSIL и компилируется вместе с ним.
GN>>Исключено, компиляция происходит до попадания малвары в систему.

A>Ей это поможет после перезагрузки. Непосредственно при заражении, конечно, надо как-то по другому отработать.

Опиши сценарий атаки, не пойму о чём речь. Компиляция ядра происходит при установке системы, и, опционально, на начальной стадии загрузки.

A>Так "не проблема" или "исключено" ?

Не проблема обеспечить автозапуск малвары. Но запуск будет после компиляции ядра.

A>Заражение — запуск в системе пришедшего снаружи кода, который пользователь/администратор не хотели запускать.

По каким правилам будет работать препятствующий этому эвристик? Я их все не знаю, поэтому не считаю его надёжным решением.

GN>>Там много места между строк
A>возможно, слишком.

Это вынужденная мера К сожалению, не мог спрогнозировать заранее, какие вопросы возникнут у неспециалистов в области (не принимайте близко к сердцу, есть люди, кто начал работать в этом направлении еще до того, как идея пришла мне в голову ). Благодаря обсуждению, можно будет написать нормальную статью.

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

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

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

А кто будет компилировать этот код just in time? JIT компилятор, а он будет каким, тоже компилироваться just in time? А кто будет компилировать его? (И вообще — на каком компиляторе был скомпилирован первый компилятор?) В конце концов получис нативный бинарный компилятор с постоянными адресами, который будет компилировать нечто на раннем этапе загрузки системы и малвары будут атаковать его ... Короче в хумор!!!!

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

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

GN>Практика показала. Такой код легко модифицируем.

Такой код не модифицируем, если
1) ОС не содержит ошибок и правильно использует предоставляемые аппаратные ресурсы, как-то: 4 кольца защиты процессора, защита памяти с исполняемыми данными от модификации, стека и динамической памяти от исполнения;
2) пользователь придерживается элементарной гигиены — не ходить в сеть под админом...

Изобретено давно и иногда даже применяется, всё остальное демагогия.

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

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

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

GN>>Практика показала. Такой код легко модифицируем.

MN>Такой код не модифицируем, если
MN>1) ОС не содержит ошибок и правильно использует предоставляемые аппаратные ресурсы, как-то: 4 кольца защиты процессора, защита памяти с исполняемыми данными от модификации, стека и динамической памяти от исполнения;

ГГГ все программы содержат ошибки. Это аксиома. А какая ОС содержит (вернее использует) все 4 кольца ?

MN>2) пользователь придерживается элементарной гигиены — не ходить в сеть под админом...

А лучше вообще ампутация — чтобы совсем без сети.
На самом деле даже если пользователь не админ и ОС без ошибок все равно возможно privelege escalation, через ошибки в сторонних продуктах (как то: драйверы StarForce, драйверы ATI, ядро ZoneAlarm. Все эти примеры реального эксплуатирования ошибок.)

MN>Изобретено давно и иногда даже применяется, всё остальное демагогия.

Слишком категорично, не так ли ?

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

A>не говоря уже про Micro Kernel (где на x86 кроме QNX и так пока не родившегося Hurd ? )

Minix 3

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

MN>Такой код не модифицируем, если
MN>1) ОС не содержит ошибок и правильно использует предоставляемые аппаратные ресурсы, как-то: 4 кольца защиты процессора, защита памяти с исполняемыми данными от модификации, стека и динамической памяти от исполнения;

ОС уже есть и приходится с ней жить.

MN>2) пользователь придерживается элементарной гигиены — не ходить в сеть под админом...

Можно бы ответить аналогично — кто цепляет малвару под админом, у того руки не оттуда растут. И вообще, меня удивляет подобная позиция профессионалов. Клиент всегда прав.

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

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

MN>А кто будет компилировать этот код just in time? JIT компилятор, а он будет каким, тоже компилироваться just in time?

Нет, он будет поставляться (подписанным ЭЦП) производителем ОС на немодифицируемом носителе.

MN> А кто будет компилировать его? (И вообще — на каком компиляторе был скомпилирован первый компилятор?) В конце концов получис нативный бинарный компилятор с постоянными адресами, который будет компилировать нечто на раннем этапе загрузки системы и малвары будут атаковать его ... Короче в хумор!!!!

Можно увидеть подробный сценарий атаки компилятора? посмеёмся в месте.

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

GN>>>Практика показала. Такой код легко модифицируем.

MN>>Такой код не модифицируем, если
MN>>1) ОС не содержит ошибок и правильно использует предоставляемые аппаратные ресурсы, как-то: 4 кольца защиты процессора, защита памяти с исполняемыми данными от модификации, стека и динамической памяти от исполнения;

IID>ГГГ все программы содержат ошибки. Это аксиома.

ЭТО ОТМАЗКА


IID>А какая ОС содержит (вернее использует) все 4 кольца ?

Unix`ы семейства S5R4 (как обстоят дела с Linux`ом, FreeBSD и вообще сейчас — не в курсе, давно выпустил из виду), Vista (вы удивлены — так знайте). Если напрячься, то можно вспомнить ещё не одну.

MN>>2) пользователь придерживается элементарной гигиены — не ходить в сеть под админом...

IID>А лучше вообще ампутация — чтобы совсем без сети.

В отдельных случаях да:
1) домен-контроллерам, SANу, серверу DB или почтовому Back-Endу не зачем смотреть в глобальную сеть, Front-End сервера или сервера из DMZ зоны могут связываться с ними по одному интерфейсу, а во внешний мир светить другим;
2) обычному пользователю, ходящему в интернет с домашнего компьютера совершенно не нужна половина сетевых сервисов и протоколов, включенных по умолчанию.


IID>На самом деле даже если пользователь не админ и ОС без ошибок все равно возможно privelege escalation, через ошибки в сторонних продуктах (как то: драйверы StarForce, драйверы ATI, ядро ZoneAlarm. Все эти примеры реального эксплуатирования ошибок.)

Мы про уязвимости говорим и их гигиену или про лёгкую модифицируемость кода операционной системы на лету? Ещё раз вам говорю, в ring0 попасть очень и очень сложно, а при выполнении небольшого числа условий просто невозможно. Если вспомнить старые ОС (w2k, например, которой я до сих пор успешно пользуюсь), то даже при отсутсвии 4-ёх колец, на моей памяти всего с десяток уязвимостей, позволявших пролезть в kernel mode по вине ОС. А насчёт ваших примеров: ограничьте в правах и привилегиях процессы браузеров, почтовых клиентов, ICQ. Включите DEP, включите Safer — это доступно уже в XP. В висте у вас появляются UAC и MIC (Integrity Levels).


MN>>Изобретено давно и иногда даже применяется, всё остальное демагогия.

IID>Слишком категорично, не так ли ?

Нет.

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

GN>Здравствуйте, Mr. None, Вы писали:

MN>>Такой код не модифицируем, если
MN>>1) ОС не содержит ошибок и правильно использует предоставляемые аппаратные ресурсы, как-то: 4 кольца защиты процессора, защита памяти с исполняемыми данными от модификации, стека и динамической памяти от исполнения;

GN>ОС уже есть и приходится с ней жить.

Vista — все 4 кольца защиты. Unix`ы семейства S5R4 — все 4 кольца защиты. Ещё вопросы есть? Осталось исправить ошибки, после 2-ого сервис пака, я уверен, висту чёрта в 2 прошибёшь... Так — изредка. Если уж w2k стала стабильной при всех её недостатках.


MN>>2) пользователь придерживается элементарной гигиены — не ходить в сеть под админом...

GN>Можно бы ответить аналогично — кто цепляет малвару под админом, у того руки не оттуда растут. И вообще, меня удивляет подобная позиция профессионалов. Клиент всегда прав.

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

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

GN>Здравствуйте, Mr. None, Вы писали:

MN>>А кто будет компилировать этот код just in time? JIT компилятор, а он будет каким, тоже компилироваться just in time?

GN>Нет, он будет поставляться (подписанным ЭЦП) производителем ОС на немодифицируемом носителе.

А ЭЦП ты будешь проверять вручную .


MN>> А кто будет компилировать его? (И вообще — на каком компиляторе был скомпилирован первый компилятор?) В конце концов получис нативный бинарный компилятор с постоянными адресами, который будет компилировать нечто на раннем этапе загрузки системы и малвары будут атаковать его ... Короче в хумор!!!!

GN>Можно увидеть подробный сценарий атаки компилятора? посмеёмся в месте.

Давай. MS не так давно заявила, что Vista будет последней операционной системой распространяемой традиционным спомобом, посредством продажи на дисках в коробочках. Последующие ОС будут, скорее всего, распространятся отдельными модулями посредством скачивания с их сайта и последующей авторизацией покупаемым ключом. А вы "немодифицируемый носитель"...

>>Vista — все 4 кольца защиты.

Где про это можно почитать?

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

>>>Vista — все 4 кольца защиты.

G>Где про это можно почитать?

К сожалению толком нигде . Изначально Майкрософт заявляла, что будут все 4 кольца защиты в 64-битной версии ОС. Но потом тишина. Одни источники утверждают, что это так другие, что нет. Достоверного подтверждения или опровержения я так и не нашёл. Так что моё заявление, можно сказать, не вполне подтверждённое. В любом случае ждём Longhorn`а...

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

A>>>или отправляет в сеть своему хозяину данные пользователя в виле файла.
GN>>Она не сможет это сделать при установленном фаерволле.
A>Файрвол выключеН, поскольку ОС не смогла его защитить от малвары. http://bash.org.ru/quote.php?num=211190

A>>>JVM/CLR тут никаким боком, млаваре внедряться никуда не надо, если речь идет о безопасности данных пользователя — то проще их взять как файл не внедряясь в программы.
GN>>Поэтому малвара пропатчит ядро и выйдет в сеть в обход фаерволла.
A>Так чем JVM/CLR помодет в защите безопасности ?
Если запретить исполнение неуправляемого кода, то всё, что делает скачанный из недобросовестного источника код, будет проходить через CAS. В итоге, манипуляции с чужими данными будут посланы в лес. Манипуляции с OS, в том числе и c JVM/CLR будут посланы в лес. Ну и так далее.
Единственная остающаяся дыра в CAS — это программы, маскирующие нелегальное поведение под легальное. К примеру, бэкапилка с автоапдейтом. Как бэкап она имеет право читать всё, и пользователь это подтвердит, а для автоапдейта ей нужен доступ к родному серверу. То, что при "автоапдейте" программка будет сливать на сервер данные "забэкапленных" кредиток, обнаружится значительно позже.
Тем не менее, как минимум будут отслежены
— хождения "не туда" (что, впрочем, уже сейчас мониторится фаерволлами)
— попытки манипулировать чем не надо (например, тем же фаерволлом).

Для неуправляемого кода ничего полезного сделать все равно нельзя. Это аксиома. Как только пользователь под привилегиями администратора запустил неуправляемый код, никакая защита не сработает (кроме заранее запущенного антивируса, который вовремя предотвратит запуск злонамеренного кода, умея его обнаруживать).
Полиморфное ядро не слишком поможет. На первое время — да. А потом кто-то поумнее напишет анализатор ядра, который посканирует код и найдет точки входа. Все, что спрятал пингвин, завсегда найдет буревестник. У него — всё время мира и полные права администратора в user mode. После этого можно будет сгенерировать соответствущий руткит, который активизируется сразу после перезагрузки (а то и до неё). Лично видел вполне легальный инсталлер, который отключал ворнинги винды по поводу неподписанных драйверов на время инсталляции. А если бы острым, а если бы в глаз?

A>>>Невозможность перехвата будут обеспечивтаь механизмы ОС, которые "неспособны противостоять атакам" как написано выше.
A>>>Иными словами, неворзможность перехвата обеспечить нельзя — проблему курицы и яйца.
GN>>Для того, что бы перехватить некоторую функцию, необходим её адрес. Нет адреса — перехват невозможен.
A>Reflection, однако. Берем у VM и запрашиваем замену стандартной функции нa свою
CAS не даст нам это сделать. В том, естественно, случае, если мы не запустили неуправляемый код. Потому что неуправляемый код банально поправит настройки CAS и всего чего душеньке угодно.

Sinclair wrote:
> CAS не даст нам это сделать. В том, естественно, случае, если мы не
> запустили неуправляемый код. Потому что неуправляемый код банально
> поправит настройки CAS и всего чего душеньке угодно.
Кстати, я уже пару раз говорил, что никто не мешает использовать CAS для
unmanaged-кода.

Например, http://coyotos.org/ фактически так и делает — там используется
система "capabilities". Каждый "capability" — это по-сути handle для
какого-то ресурса, его нельзя создать без участия ядра. Грубо говоря, у
тебя unmanaged-программа ничего не сможет сделать с ядром, если у нее не
будет хэндла на доступ к нему.

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

S>Для неуправляемого кода ничего полезного сделать все равно нельзя. Это аксиома. Как только пользователь под привилегиями администратора запустил неуправляемый код, никакая защита не сработает (кроме заранее запущенного антивируса, который вовремя предотвратит запуск злонамеренного кода, умея его обнаруживать).

Очень авторитетные товарищи имеют прямо противроположное мнение:

http://citforum.ru/operating_systems/reliable_os/

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

MN>А ЭЦП ты будешь проверять вручную .

Да. А что? Эта проверка будет происходить на стадии инсталляции или загрузки, то есть до запуска зловредного кода.

MN>MS не так давно заявила, что Vista будет последней операционной системой распространяемой традиционным спомобом, посредством продажи на дисках в коробочках. Последующие ОС будут, скорее всего, распространятся отдельными модулями посредством скачивания с их сайта и последующей авторизацией покупаемым ключом. А вы "немодифицируемый носитель"...

Я просил сценарий атаки, а не размышления о поставках ОС.

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

MN>Vista — все 4 кольца защиты.

Речь о Toyota Vista что ли?

MN> Unix`ы семейства S5R4 — все 4 кольца защиты.

Рад за них, но есть еще и массовая ОС, а не только Неуловый Джо.

MN> Ещё вопросы есть?

Да. И зачем же MS реализовали PatchGuard?

MN>Если он чётко следует инструкциям и руководствам — мы же с вами в реальном мире живём, где правят продажи, а не оголтелый фанатизм и альтруизм.

А я о продажах и говорю, клиент хочет ПО для спокойной работы, а не для постоянного ввода паролей и подтверждений

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

S>Полиморфное ядро не слишком поможет. На первое время — да. А потом кто-то поумнее напишет анализатор ядра, который посканирует код и найдет точки входа.

А как приблизительно будет выглядеть такой анализатор? Есть мнения, что это NP-полная задача.

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

C>Кстати, я уже пару раз говорил, что никто не мешает использовать CAS для
C>unmanaged-кода.
Гм. Никаких шансов реализовать CAS для неуправляемого кода нет. Грубо говоря, мне достаточно подпатчить собственный стек, чтобы получить любые требуемые привилегии. А потом подпатчить его обратно.
В том-то и дело, что управляемая среда банально не дает коду вылезти из песочницы.

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

FR>http://citforum.ru/operating_systems/reliable_os/
Гм. Авторитетные товарищи занимаются в основном улучшением ситуации с взаимопроникновением драйверов. Действительно, некоторые аспекты безопасности системы можно улучшить благодаря изоляции драйверов, хотя до полной безопасности еще далеко. Позволю себе напомнить, что подавляющее большинство вредоносного софта сейчас исполняется в user mode и зачастую не требует даже администраторских привилегий для того, чтобы пошалить.

Всё это связано с отсутствием контроля за тем, какой именно код исполняется неуправляемым приложением. Я, честно говоря, не вижу проблемы для приложения, выполняемого в юзермоде под правами администратора взять и, к примеру, "починить" реестр или файловую систему так, чтобы обеспечить перехват системных функций после следующей перезагрузки.
Ну вот выделили мы всё, что можно, из ядра. И что? Как это поможет предотвратить вклинивание или замену драйвера файлухи на свой, который будет видеть всё, кроме вируса?

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

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

FR>>http://citforum.ru/operating_systems/reliable_os/
S>Гм. Авторитетные товарищи занимаются в основном улучшением ситуации с взаимопроникновением драйверов. Действительно, некоторые аспекты безопасности системы можно улучшить благодаря изоляции драйверов, хотя до полной безопасности еще далеко. Позволю себе напомнить, что подавляющее большинство вредоносного софта сейчас исполняется в user mode и зачастую не требует даже администраторских привилегий для того, чтобы пошалить.

Ты прочитай до конца статью там есть и про защиту в user mode.

S>Всё это связано с отсутствием контроля за тем, какой именно код исполняется неуправляемым приложением. Я, честно говоря, не вижу проблемы для приложения, выполняемого в юзермоде под правами администратора взять и, к примеру, "починить" реестр или файловую систему так, чтобы обеспечить перехват системных функций после следующей перезагрузки.

По моему ничего не выйдет. Обычные приложения имеют очень мало прав в этой системе.

S>Ну вот выделили мы всё, что можно, из ядра. И что? Как это поможет предотвратить вклинивание или замену драйвера файлухи на свой, который будет видеть всё, кроме вируса?

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

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

FR>Ты прочитай до конца статью там есть и про защиту в user mode.
Прочитал. Не нашел. Везде только детский лепет про "наша система не предназначена для защиты от злонамеренного кода, зато помогает добропорядочным драйверам восстановиться при сбое". Да, есть упоминания про то, как контролируется IPC, но нет никакого упоминания про то, каким образом настраиваются эти политики.
Поэтому нет никакой гарантии того, что все сработает как надо. Вот у них там упоминается про инициализацию векторов защиты портов из файлухи. В будушем они обещают это починить и получать информацию из BIOS, но пока что вирус может тупо переписать файл (а права иметь запись в файлуху будут у очень большого количества приложений), и поправить привилегии.

То, что предлагают эти парни — средство повышения отказоустойчивости, а не безопасности. Предлагается что-то вроде CAS, только очень грубое; на уровне процесса. Я на 100% уверен, что реализовать полномасштабную проверку в ядре — невозможно. Можно только несколько затруднить взлом такой системы. Против пользователя с административными привилегиями все эти меры не дадут никакого результата.

FR>По моему ничего не выйдет. Обычные приложения имеют очень мало прав в этой системе.
Да ну, не смеши меня.
S>>Ну вот выделили мы всё, что можно, из ядра. И что? Как это поможет предотвратить вклинивание или замену драйвера файлухи на свой, который будет видеть всё, кроме вируса?
FR>Вкливание вообще не возможно, пользовательские приложения вообще не могут получить доступ к памяти других процессов.
Ха-ха. Просто в этой системе вклинивание не будет требовать доступа к памяти. Зачем?
FR>Для замены драйвера придется его ручками устанавливать.
Что значит "ручками"? Если админ может подергать за ручки, то же самое может сделать и червь под его правами. Он точно так же пропишет себя как драйвер файлухи, и всё заработает как ему надо.

Sinclair wrote:
> C>Кстати, я уже пару раз говорил, что никто не мешает использовать CAS для
> C>unmanaged-кода.
> Гм. Никаких шансов реализовать CAS для неуправляемого кода нет. Грубо
> говоря, мне достаточно подпатчить собственный стек, чтобы получить любые
> требуемые привилегии. А потом подпатчить его обратно.
Как? Еще раз напомню — с важными ресурсами ты работаешь через
специальные handle'ы. Сам создать или изменить ты их не можешь. А что ты
там со своим стеком делаешь — это твое личное дело.

Собственно, CASы для неуправляемого кода уже делались, причем вполне
успешно — http://en.wikipedia.org/wiki/Plessey_250

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

C>Sinclair wrote:
>> C>Кстати, я уже пару раз говорил, что никто не мешает использовать CAS для
>> C>unmanaged-кода.
>> Гм. Никаких шансов реализовать CAS для неуправляемого кода нет. Грубо
>> говоря, мне достаточно подпатчить собственный стек, чтобы получить любые
>> требуемые привилегии. А потом подпатчить его обратно.
C>Как? Еще раз напомню — с важными ресурсами ты работаешь через
C>специальные handle'ы. Сам создать или изменить ты их не можешь.
Ок, откуда я получаю такой хэндл? Правильно, я делаю системный вызов. Например, CreateFile("C:\boot.ini"). Как система проверяет, что мне можно этот вызов делать? Система привилегий пользователя тупо сравнивает ACL с моим списком групп. Система CAS должна посмотреть в стек, чтобы понять, что за код делает такой вызов. В управляемой среде это так; именно поэтому я могу запретить стороннему приложению открывать файлы напрямую, но разрешить через специальный SandBox API. Так вот: в неуправляемом коде стек ты не проверишь. Потому, что я могу его "починить".
C>Собственно, CASы для неуправляемого кода уже делались, причем вполне
C>успешно — http://en.wikipedia.org/wiki/Plessey_250
Гм. Я так понял, у парней было аппаратное решение. Т.е. что-то вроде управляемой среды на реальной машине, а не на виртуальной.

Sinclair wrote:
> именно поэтому я могу запретить стороннему приложению открывать файлы
> напрямую, но разрешить через специальный SandBox API. Так вот: в
> неуправляемом коде стек ты не проверишь. Потому, что я могу его "починить".
Размести этот Sandbox API в отдельном процессе со специальными
привиллегиями — тогда проверка привиллегий вызывающего будет надежной.
Еще раз, проблема CAS уже успешно решалась для нативного кода.

> C>Собственно, CASы для неуправляемого кода уже делались, причем вполне
> C>успешно — http://en.wikipedia.org/wiki/Plessey_250
> Гм. Я так понял, у парней было аппаратное решение. Т.е. что-то вроде
> управляемой среды на реальной машине, а не на виртуальной.
Такое можно и сейчас сделать на x86 — просто оно будет медленнее
работать (потребуется делить код на процессы).