Здравствуйте, gear nuke, Вы писали:
GN>Да нет, внедрение в чужой процесс — распространённый вид атаки, описан у Рихтера и используется в большом количестве легального софта.
Если это работает и с процессами ядра ОС, я просто в шоке. Это же собственно сверхуязвимость, неужели если она есть, то до сих пор не исправили? Мне всегда казалось, что так можно поступать только с процессами с тем же или меньшим уровнем привилегий, чем мой.
Здравствуйте, VladD2,
IID>>1) машинный код небезопасен, если он компилится сходным образом. Это постулат (лемма).
VD>А с чего это бредовое предположение вдруг стало леммой?
Практика показала. Такой код легко модифицируем.
IID>>Что понимается под "небезопастностью" ? То что код может быть легко модифицирован малварью, (сплоетом, трояном и т.д.)
VD>После этого умозаключения неплохо было бы задуматься, а является ли это проблемой?
Неплохо бы ознакомиться с темой и её насущными проблемами, подобные вопросы отпадут.
VD>Например, посмотреть статистику разных атак и выяснить в каком проценте из них проблемой ялялось то, что был модифицирован код исполняемых модулей.
VD>Насколько я знаю самой большой процент вредоносного софта запускается тупыми пользователями самостоятельно причем из под администратора.
И что, эти пользователи не люди? Я предлагаю решить часть их проблем. Повторю, предполагается, что малвара уже запущена. Нужно помешать ей произвести ряд побочных эффектов.
VD>Челове создавший эту тему не только в дотнете и иуравляемом коде нихрена не смыслет, но и вообще в принципах обеспечения безопасности и источниках проблем с нею.
VD>Пришел орел... намечтал себе что-то там... вылил кашу из своих домыслов в виде потока сознания. И что? Что тут обсуждать?
Вкус устриц
VD>Если у нас есть возможность править исполняемые модули или память процессов, то ничто не безопастно перед внешнеми угрозами. И .NET тут не причем.
Действительно, .NET ни причём, что к нему цепляться то? Лучше запретим модифицирование памяти
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[10]: JIT компиляция - безопасность о которой не думали
Здравствуйте, elmal, Вы писали:
GN>>Да нет, внедрение в чужой процесс — распространённый вид атаки, описан у Рихтера и используется в большом количестве легального софта. E>Если это работает и с процессами ядра ОС, я просто в шоке. Это же собственно сверхуязвимость, неужели если она есть, то до сих пор не исправили? Мне всегда казалось, что так можно поступать только с процессами с тем же или меньшим уровнем привилегий, чем мой.
Так и есть, причем еще нужно иметь специальную привилегию (SE_DEBUG_PRIVILEGE), которую можно запретить политиками безопасности. Но ведь пользователи в Винде работают под Администратором.
Хотя, IID несет бред, конечно. Если у процесса будет возможность выполнить код в режиме ядра, то никакие перекомпиляции уже не спасут.
Sapienti sat!
Re[11]: JIT компиляция - безопасность о которой не думали
Здравствуйте, Cyberax, Вы писали:
C>Хотя, IID несет бред, конечно. Если у процесса будет возможность выполнить код в режиме ядра, то никакие перекомпиляции уже не спасут.
1) Где я писал про выполнение в режиме ядра ?
2) все-таки спасут. При попытке запустить руткит в абсолютно незнакомом ему окружении он или грохнет систему в синий экран или повистнет, или просто обломается (зависит от характера ошибок у автора руткита). Бонус — данные пользователя не будут украдены.
kalsarikännit
Re[11]: JIT компиляция - безопасность о которой не думали
Здравствуйте, Cyberax, Вы писали:
C>Так и есть, причем еще нужно иметь специальную привилегию (SE_DEBUG_PRIVILEGE), которую можно запретить политиками безопасности. Но ведь пользователи в Винде работают под Администратором.
Читал я это все лет 6 назад, и использовать знания не пришлось, могу ошибаться, но вроде приложения, запущенные под администратором все равно имеют меньший приоритет, чем системные процессы и драйверы. Админ может конечно свои драйверы установить и из них уже гадить в системные процессы, но придется перезагрузиться, чтобы это получилось. Я что, не прав?
Re[12]: JIT компиляция - безопасность о которой не думали
Здравствуйте, elmal, Вы писали:
E>приложения, запущенные под администратором все равно имеют меньший приоритет, чем системные процессы и драйверы.
Да, т.к привилегии ОС и процессора это разные вещи. Первые — реализуются на основе софтовых проверок, 2е — аппаратно. Ядро ОС — это 0е кольцо защиты процессора, из 3го кольца недоступно, однако код выполняемый на уровне 0 может делать всё, что угодно (в том числе и модифицировать проверки).
E> Админ может конечно свои драйверы установить и из них уже гадить в системные процессы, но придется перезагрузиться, чтобы это получилось.
Перезагрузка давно уже не нужна.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[9]: JIT компиляция - безопасность о которой не думали
Здравствуйте, gear nuke, Вы писали:
E>>пользовательские процессы уже очень давно не могут модифицировать ядро GN>Они могут загрузить драйвер (разными путями). Руткит это обычно и есть драйвер — он скрывает себя и еще много чего (что бы не находили антивирусы и пользователь). Для скрытия ему обычно нужно модифицировать код или данные ядра, а для этого нужно найти место модификации.
Самое забавное, что для защиты от этого нужно очень эффективно всякий раз "перемешивать" код ядра. Вплоть до перепахивания всех без исключения устойчивых последовательностей бинарного кода, кои, как известно, есть следствие работы оптимизатора (в частности). Ergo, предлагается всякий раз получать систему с непредсказуемыми характеристиками? Вот уж, воистину, мечта поэта: две-три перезагрузки, и ОС начнёт работать быстро с вероятностью 59.8%.
Короче, это отдаёт не столько решением проблемы, сколько подведенеим основания для того, чем хочется позаниматься (регулярно перетранслируемым ядром и воплями неизвестно о чём, зато громко).
E>>Через ошибки переполнения буфера в ядре ОС чтоль? GN>В том числе и через разные ошибки.
Угу. Ещё 25-й кадр нужно упомянуть.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[12]: JIT компиляция - безопасность о которой не думали
Здравствуйте, IID, Вы писали:
C>>Хотя, IID несет бред, конечно. Если у процесса будет возможность выполнить код в режиме ядра, то никакие перекомпиляции уже не спасут. IID>1) Где я писал про выполнение в режиме ядра ?
А user-mode руткитов не существует. И в Windows ты из user-mode не можешь патчить ядерные структуры.
IID>2) все-таки спасут. При попытке запустить руткит в абсолютно незнакомом ему окружении он или грохнет систему в синий экран или повистнет, или просто обломается (зависит от характера ошибок у автора руткита). Бонус — данные пользователя не будут украдены.
Чем оно "незнакомое"? Или структуры системных таблиц тоже каждый раз менять будем с помощью встроенного искусственного интеллекта?
Sapienti sat!
Re[13]: JIT компиляция - безопасность о которой не думали
Здравствуйте, gear nuke, Вы писали:
GN>Да, т.к привилегии ОС и процессора это разные вещи. Первые — реализуются на основе софтовых проверок, 2е — аппаратно. Ядро ОС — это 0е кольцо защиты процессора, из 3го кольца недоступно, однако код выполняемый на уровне 0 может делать всё, что угодно (в том числе и модифицировать проверки).
Вообще-то я, как пользователь большинство программ запускаю из 3-его кольца защиты вроде (не 0-го точно), даже под админом. Более того, если мне не изменяет память, драйвера — это 1-е кольцо защиты, а не 0-е. Мои процессы да, могут вызывать функции ядра, выполняющиеся в 0-м кольце защиты. Так собственно эти функции ядра вроде как должны быть уже достаточно вылизаны со времен NT, чтобы не позволять легко запускать собственные процессы в 0-м кольце защиты, и уж тем более проверять, могу ли я гадить в процессы, выполняющиеся в более привилегированных кольцах. Я бы например на месте разработчиков ОС не поленился бы проверять именно кольцо защиты, не могу понять причины, по которой не проверяют это. Если не так, то это ИМХО мегабага.
PS Неужели в Линуксе тоже самое ?
Re[10]: JIT компиляция - безопасность о которой не думали
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Самое забавное, что для защиты от этого нужно очень эффективно всякий раз "перемешивать" код ядра.
Во-первых, достаточно только при установке. Необходимость компиляции каждый раз при загрузке ОС нужно отдельно изучать.
Во-вторых, что значит "очень" эффективно? Достаточно это делать эффективнее, чем анализируется код. Можно предусмотреть апдейты компилятора.
ГВ>Вплоть до перепахивания всех без исключения устойчивых последовательностей бинарного кода, кои, как известно, есть следствие работы оптимизатора (в частности).
Это, кстати, самое простое, для этого не нужен исходный код, и это уже помешает большому проценту малвари.
ГВ>Ergo, предлагается всякий раз получать систему с непредсказуемыми характеристиками?
Это лишняя сложность, достаточно с предсказуемыми.
ГВ>Ещё 25-й кадр нужно упомянуть.
Зачем?
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[14]: JIT компиляция - безопасность о которой не думали
Здравствуйте, elmal, Вы писали:
E>Вообще-то я, как пользователь большинство программ запускаю из 3-его кольца защиты вроде (не 0-го точно), даже под админом.
Верно, и эти программы могут привести к загрузке драйвера.
E>Более того, если мне не изменяет память, драйвера — это 1-е кольцо защиты, а не 0-е.
В Виндовсе только 2 кольца защиты — 3е и 0е.
E>Мои процессы да, могут вызывать функции ядра, выполняющиеся в 0-м кольце защиты. Так собственно эти функции ядра вроде как должны быть уже достаточно вылизаны со времен NT, чтобы не позволять легко запускать собственные процессы в 0-м кольце защиты и уж тем более проверять, могу ли я гадить в процессы, выполняющиеся в более привилегированных кольцах.
Если говорить о багах — то многое вылизано. А если о загрузке драйвера — то как узнать, что будет делать этот драйвер? На данном этапе нет возможности изменять чужие драйвера, тем более переписывать их на Шарпе.
E>Я бы например на месте разработчиков ОС не поленился бы проверять именно кольцо защиты, не могу понять причины, по которой не проверяют это. Если не так, то это ИМХО мегабага.
Если речь о переодической проверки целостности ядра — так и делает PatchGuard, но он обходится из ядра.
E>PS Неужели в Линуксе тоже самое ?
Там ситуация намного лучше — он слабо распространён, пользователи гораздо грамотнее (в среднем), поэтому невыгодно под него малвары делать.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[11]: JIT компиляция - безопасность о которой не думали
Здравствуйте, gear nuke, Вы писали:
ГВ>>Самое забавное, что для защиты от этого нужно очень эффективно всякий раз "перемешивать" код ядра. GN>Во-первых, достаточно только при установке. Необходимость компиляции каждый раз при загрузке ОС нужно отдельно изучать. GN>Во-вторых, что значит "очень" эффективно? Достаточно это делать эффективнее, чем анализируется код. Можно предусмотреть апдейты компилятора.
"Очень" эффективно, это чтобы не было никакой возможности, например, привязаться к какой-то определённой последовательности и, например, взяв некоторое смещение от её начала получить точку входа в некоторую системную функцию. "Никакой возможности" означает, например, что вероятность повторения такой последовательности не больше, чем, скажем 2% (конкретную цифру назвать не могу — нужно прикидывать в зависимости от предполагаемых потребностей вируса) Заметь, что это должно происходить при трансляции одного и того же исходного кода.
ГВ>>Вплоть до перепахивания всех без исключения устойчивых последовательностей бинарного кода, кои, как известно, есть следствие работы оптимизатора (в частности). GN>Это, кстати, самое простое, для этого не нужен исходный код, и это уже помешает большому проценту малвари.
ЧТО????????????????? Это — самое простое? Так... Разговаривать больше не о чем.
ГВ>>Ergo, предлагается всякий раз получать систему с непредсказуемыми характеристиками? GN>Это лишняя сложность, достаточно с предсказуемыми.
Ну ты же предлагаешь чуть ли не оптимизатором играть! Впрочем — ладно. Закрываем тему. Ты, похоже, даже не понимаешь, какую чушь тут городишь.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[13]: JIT компиляция - безопасность о которой не думали
Здравствуйте, Cyberax, Вы писали:
C>А user-mode руткитов не существует.
Да и Земля плоская.
C>И в Windows ты из user-mode не можешь патчить ядерные структуры.
Можно через Device\PhysicalMemory.
C>Чем оно "незнакомое"? Или структуры системных таблиц тоже каждый раз менять будем с помощью встроенного искусственного интеллекта?
В основном я имел ввиду патч кода, но морфинг структур тоже очень желателен, для начала можно просто менять поля местами.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[12]: JIT компиляция - безопасность о которой не думали
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, gear nuke, Вы писали:
ГВ>>>Самое забавное, что для защиты от этого нужно очень эффективно всякий раз "перемешивать" код ядра. GN>>Во-первых, достаточно только при установке. Необходимость компиляции каждый раз при загрузке ОС нужно отдельно изучать. GN>>Во-вторых, что значит "очень" эффективно? Достаточно это делать эффективнее, чем анализируется код. Можно предусмотреть апдейты компилятора.
ГВ>"Очень" эффективно, это чтобы не было никакой возможности, например, привязаться к какой-то определённой последовательности и, например, взяв некоторое смещение от её начала получить точку входа в некоторую системную функцию. "Никакой возможности" означает, например, что вероятность повторения такой последовательности не больше, чем, скажем 2% (конкретную цифру назвать не могу — нужно прикидывать в зависимости от предполагаемых потребностей вируса) Заметь, что это должно происходить при трансляции одного и того же исходного кода.
ГВ>>>Вплоть до перепахивания всех без исключения устойчивых последовательностей бинарного кода, кои, как известно, есть следствие работы оптимизатора (в частности).
всех и не нужно. Круг интересных малвари сервисов ОС довольно неплохо очерчен.
GN>>Это, кстати, самое простое, для этого не нужен исходный код, и это уже помешает большому проценту малвари.
ГВ>ЧТО????????????????? Это — самое простое? Так... Разговаривать больше не о чем.
выше была инфа про building own kernel — выстроить аналогичное образу на диске дерево исполнения машинных инструкций это вполне решабельная задача, объемом в пару человекомесяцев максимум для профильного специалиста хорошего уровня. А перемешать ветви исполнения и модифицировать инструкции (хотя бы по примитивной маске используемых командной регистров) — задача не намного сложнее. Так что не надо делать большие глаза, авторы малвари давно это осилили.
ГВ>>>Ergo, предлагается всякий раз получать систему с непредсказуемыми характеристиками? GN>>Это лишняя сложность, достаточно с предсказуемыми.
ГВ>Ну ты же предлагаешь чуть ли не оптимизатором играть! Впрочем — ладно. Закрываем тему. Ты, похоже, даже не понимаешь, какую чушь тут городишь.
Он то как раз понимает
kalsarikännit
Re[14]: JIT компиляция - безопасность о которой не думали
Здравствуйте, gear nuke, Вы писали:
C>>И в Windows ты из user-mode не можешь патчить ядерные структуры. GN>Можно через Device\PhysicalMemory.
Ну так его запретить не сложно. Кроме того, без администратора все равно его не затронуть.
Ну а с админом уже что угодно можно творить.
C>>Чем оно "незнакомое"? Или структуры системных таблиц тоже каждый раз менять будем с помощью встроенного искусственного интеллекта? GN>В основном я имел ввиду патч кода, но морфинг структур тоже очень желателен, для начала можно просто менять поля местами.
Еще раз, чем тебе морфинг кода поможет? Руткиты его вообще редко трогают код — обычно меняют структуры данных. А смена полей элементарно отслеживается.
Sapienti sat!
Re[12]: JIT компиляция - безопасность о которой не думали
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>"Очень" эффективно, это чтобы не было никакой возможности, например, привязаться к какой-то определённой последовательности и, например, взяв некоторое смещение от её начала получить точку входа в некоторую системную функцию.
Обычно всё немного сложнее — есть несколько последовательностей и нефиксированные смещения. Работает простейший вариант дизассемблера — поиск по маскам (даже без учёта длин инструкций). Вот если потребуется строить и анализировать граф вызовов...
ГВ>"Никакой возможности" означает, например, что вероятность повторения такой последовательности не больше, чем, скажем 2% (конкретную цифру назвать не могу — нужно прикидывать в зависимости от предполагаемых потребностей вируса)
Да, достаточно, что бы эта возможность не всегда была.
ГВ>Заметь, что это должно происходить при трансляции одного и того же исходного кода.
Разумеется, это требование к компилятору.
ГВ>>>Вплоть до перепахивания всех без исключения устойчивых последовательностей бинарного кода, кои, как известно, есть следствие работы оптимизатора (в частности). GN>>Это, кстати, самое простое, для этого не нужен исходный код, и это уже помешает большому проценту малвари.
ГВ>ЧТО????????????????? Это — самое простое?
А какие проблемы в поиске и замене? Простейший пример — add на sub
ГВ>Так... Разговаривать больше не о чем.
Там есть уже почти весь нужный код. Выбор из нескольких вариантов наиболее эффективного, доработать (ядро и так компилируется без полной оптимизации). Ну а полный рандом — это вроде как отдельная научная задача.
ГВ>Впрочем — ладно. Закрываем тему. Ты, похоже, даже не понимаешь, какую чушь тут городишь.
Что ж никто из гуру не просветил меня до сих пор?
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[15]: JIT компиляция - безопасность о которой не думали
Здравствуйте, Cyberax, Вы писали:
C>Ну а с админом уже что угодно можно творить.
Положим этому конец
C>Еще раз, чем тебе морфинг кода поможет? Руткиты его вообще редко трогают код
Действительно, последнее время модификация кода редко используется, так как детектится сравнением с оригиналом. Однако код всё равно анализируется — найти адрес "оригинального обработчика" или неэкспортируемую переменную ядра. Это нетривиально в полиморфленом коде.
C>обычно меняют структуры данных.
Для DKOM нужно найти неэкспортируемые переменные. Патч таблицы мажоров и подобное обычно требует "оригинальные обработчики". Хотя для надёжности лучше менять бинарное представление структур, но такой морфинг сложно реализовать, проще компилировать заново.
C>А смена полей элементарно отслеживается.
На это нужно время, и не факт, что проверяющий код будет выполняться.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[13]: JIT компиляция - безопасность о которой не думали
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.
Этим авторы прямо расписываются в том, что морфинг влияет на производительность не в лучшую сторону (что, в принципе, очевидно). Ты предлагаешь таким образом играться с ядром ОС? Спасибо, смешно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[13]: JIT компиляция - безопасность о которой не думали
Здравствуйте, IID, Вы писали:
ГВ>>>>Вплоть до перепахивания всех без исключения устойчивых последовательностей бинарного кода, кои, как известно, есть следствие работы оптимизатора (в частности).
IID>всех и не нужно. Круг интересных малвари сервисов ОС довольно неплохо очерчен.
Так мы говорим о принципиальной возможности влезть в адресное пространство ядра или о защите определённых сервисов?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[14]: JIT компиляция - безопасность о которой не думали
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, IID, Вы писали:
ГВ>>>>>Вплоть до перепахивания всех без исключения устойчивых последовательностей бинарного кода, кои, как известно, есть следствие работы оптимизатора (в частности).
IID>>всех и не нужно. Круг интересных малвари сервисов ОС довольно неплохо очерчен.
ГВ>Так мы говорим о принципиальной возможности влезть в адресное пространство ядра или о защите определённых сервисов?
мы говорим об эффективном противодействии руткитам, малвари, и другому зловредному коду.