Tim
так-то джавку какую-нить запросто
Anonymous
Берёшь seccomp, берёшь AppArmor, берёшь cgroups.
Это так, альтернативный подход, если виртуалки или свою песочницу не хочется.
Tim
в винде, кстати, есть low integrity level на процесс - там можешь гибко настраивать ограничения. они даже писать могут только в специальный темп - LocalLow.
Constantine
хз правда можно ли там достаточно обезопасить сырые указатели
полный санитайз, наверное, можно оптимизировать
Tim
что такое полный санитайз? санитайзеры знаю - но они ж такие, гарантий не дают.
Constantine
это значит, что любое чтение-запись памяти в LLVM коде проверяется
Constantine
а потом думаем
Tim
что мешает в плюсах сделать VirtualAlloc(read | write | executable access), записать шеллкодес, скастовать указатель на этот буфер на указатель на функцию и вызвать её?
Constantine
то, что у тебя не будет импорта VirtualAlloc
Anatoly
но почему винда? у кого-то виндовый сервер?
Tim
ну это я так, для примера
Constantine
ну тут на самом деле такой основной пример
Constantine
существуют альтернативные способы импорта
Constantine
помню один для 86, он был основан на поиске обработчика исключений в kernel32
Tim
помню один для 86, он был основан на поиске обработчика исключений в kernel32
аа, ты про то как импорт получить в обход таблицы импорта?
Constantine
да
Tim
да тысячи их, этих способов
Constantine
из-за этой бяки нужно полностью проверять весь доступ на память
Berkus
мне кажется вы скатываетесь в лютый оффтоп
Constantine
мы еще недолго
Tim
сохранить dll в шеллкодом в темп можно, потом сделать LoadLibrary и всё
Constantine
мы просто говорим, что вы пишете на ISO C++ и не можете импортировать системные вызовы
Constantine
т.е. по сути вы выполняетесь на LLVM JIT OS
Constantine
которая не умеет LoadLibrary
Berkus
бот не обязан это знать
ну пусть майнит на своих 256КГц, удачи ему
Constantine
и сверху мы буквально должны в LLVM код сразу встроить проверку всех указателей на чтение/запись
Tim
имхо чисто плюсы имхо полностью не обезопасить - можно обезопасить всякие языки без сырого доступа к памяти - где ссылоки. раст, джавка, и все скриптоязыки
Berkus
ROP цепочка :)
ты понимаешь в чем дело. на LLVM есть деобфускаторы таких вот обфускаций, нет ничего сложного распарсить твой IR и понять что он делает, машинно это гораздо проще чем вручную.
Constantine
и потом просить оптимизатор это все переоптимизировать
Tim
ну без unsafe там же вроде нет сырых указателей. и это хорошо)
Berkus
ROP цепочка - не обфускация.
так, так, и что, думаешь нельзя задетектить?
Tim
хм. сложный вопрос)
Berkus
хм. сложный вопрос)
ну и как бы про скриптовые языки ты тоже промахнулся, можно из джаваскрипта ебнуть v8 например https://vuldb.com/?id.87300
Tim
ну это уязвимости конкретных систем
Tim
можно вспомнить все CVE и сказать что вообще ничего нельзя наверняка
Tim
универсально, чтобы любую работу с ROP задетектить в 100% случаях - думаю невозможно. Но можно добиться хороших результатов, если задаться целью.
Berkus
универсально, чтобы любую работу с ROP задетектить в 100% случаях - думаю невозможно. Но можно добиться хороших результатов, если задаться целью.
роп детектится комбинацией статического анализа и немношк динамики, но поскольку мы работаем изначально с IR то там просто статики достаточно, ты не сможешь затрешить стек
Berkus
не забывай что мы про JIT, а не arbitrary code
Tim
дада, я понимаю что jit
Tim
и что мы можем всё обернуть
Tim
ну в общем да - если call'ы все проверять в динамике
Tim
и не дать коду уйти из своего модуля
Tim
и гарантировать что в стэке адрес возврата не поменяют через какой-нить out of bound array локального массива
Berkus
out of bound array ловится прекрасно в IR
Anatoly
JIT же, а не виртуальная машина. какие еще проверки в динамике?
Tim
дада
Tim
ну с 99% уверенностью тогда можно, пожалуй)
Berkus
1% чисто на баги реализации
Tim
ну да, и на проёбы
Tim
типа условно обработчик оконных событий если можно поменять на кастомный адрес через апишку и потом он дёрнется операционкой
Constantine
1% чисто на баги реализации
еще 0.01% это закладки
Anatoly
надо на SO задать вопрос "как написать закладку в коде, чтобы её не мог найти статический анализатор"
Constantine
никто не обязывает JIT использовать статический анализатор
Constantine
JIT может просто проверки на UB воткнуть в весь С++ код
Constantine
перед компиляцией
Berkus
ты можешь перед любым getelementptr всовывать boundscheck например
Anatoly
так нету никакого UB. надо просто числа кастовать в указатели, это well-defined
Anatoly
самое страшное что может понадобиться - это прочитать сегмент кода, чтобы найти куда там перепрыгнуть
Berkus
так нету никакого UB. надо просто числа кастовать в указатели, это well-defined
ну если ты кастуешь в указатель - это отражается в IR, дальше остается проверить куда он указывает
Berkus
например читать сегмент кода нельзя
Anatoly
но это еще как-то надо задетектить. virtual char* a(intptr_t x) { return (char*)x; } - тут нету UB, стат. анализатору норм
Anatoly
можно запретить такие касты на уровне clang - но вдруг это поломает какой-нибудь std lib
Berkus
в месте вызова будет понятно
Anatoly
кому? кто это задетектит?
Berkus
тулза которую не будет писать Константин
Berkus
еще раз напомню, мы говорим про LLVM based JIT
Berkus
и его довольно неслабый IR
Anatoly
как она это задетектит?
Anatoly
char* cast(int x) { ... } decltype(&cast) pcast; ... if (now().year > 2000) pcast = &cast; ... char* y = pcast(x);
Anatoly
я в этом CS не спец, но кажется тут где-то есть halt problem и эмуляция ОС
Anatoly
и я уже говорил, это задача уровня антивируса - взять .exe , прогнать его на эмуляторе, и понять что там нету малвари. И антивирусы эту задачу не решают.