В компилятор Clang добавлен (https://github.com/llvm-mirror/llvm/commit/7ffec838a2b72e684...) код подсистемы SafeStack (http://dslab.epfl.ch/proj/cpi/), предназначенной для защиты от типовых ошибок, вызванных повреждением памяти в результате работы со стеком и являющихся причиной большого числа эксплуатируемых уязвимостей (например, в 2014 году в Firefox было выявлено 55 подобных уязвимостей).
SafeStack позволяет предотвратить получение контроля над помещёнными в стек указателями в программах на C/C++ через сохранение указателей (адреса возврата, указатели на функции и т.п.) в отдельной изолированной области памяти, доступ к которой производится только с использованием специальных проверок корректности обращения к памяти. Накладные расходы от дополнительных проверок несущественны и составляют 0.01-0.05%.
URL: http://blog.llvm.org/2015/06/llvm-weekly-77-jun-22nd-2015.html
Новость: http://www.opennet.me/opennews/art.shtml?num=42517
А надо ли для этого переписывать что-то в ПО или пересборка данным цлангом сама всё сделает?
-fsanitize=safe-stack
http://reviews.llvm.org/D6095
Даешь больше разных костылей.
> Даешь больше разных костылей.Благородный дон предлагает переписать весь опасный софт на управляемых языках?
Видимо да и я его в этом поддерживаю.
Разработчики того что используешь, плюнут тебе на лицо за "переписать".
И в этом я их поддерживаю.
а рано или поздно -- всё равно перепишут.(на чём-то типа Rust, или что там будет после Rust?)
так-что хоть плюйся, хоть не плюйся, а "вечного" софта можно только по пальцам перещитать :-) ..
> так-что хоть плюйсяВ твоих потных фантазиях
> В твоих потных фантазияхИ много у мусью приложений на коболе/алголе/фортране?
Ерланге Питоне Голанге
> Ерланге Питоне ГолангеИ как, много вы на этом уже написали ну хотя-бы операционок, для начала?
> Ерланге Питоне ГолангеТ.е. мусью изящно [s]слился[/s] перевел стрелки? Или мусье все еще использует базы данных на коболях? :)
На коболе в пиндосии кое-где финсофт ещё крутится, на фортране брутальные математусы осваивают гранты, размер которых высчитан на старом финсофте на коболе.
Можешь начинать, мы тебя поддерживаем.
> Видимо да и я его в этом поддерживаю.Ну вот и перепишите таким макаром хотя-бы свою операционку, для начала.
> операционку
> для начала
>> операционку
>> для началаНу да, именно так. Без операционки вы на компьютере много не наработаете. Хотя, конечно, начинать надо с бутлоадера, чтобы совсем уж для начала. Но мы же гуманисты и предоставим хипстоте подумать как запускать операционку самостоятельно :). А то они засцут еще проц из питона инициализировать, а это уже не интересно...
нет
Зачем на управляемых? С++ с контролем границ массива вполне достаточно, оптимизация любые лишние проверки просто съест. Останутся только те, которые программист не заметил. А от реализаций полагающихся на то, что где то в аргументах значение не приведёт к переполнению, нужно избавляться.
> Зачем на управляемых?
> С++ с контролем границ массива/0
Сюрприз - если писать на плюсах, а не его C-подмножестве, получить переполнение суметь надо. Но если мусью не знает, что такое vector - тем хуже для него.
> Но если мусью не знает, что такое vector - тем хуже для него.Мусью также знает что operator[] не делает проверок. И мы опять таки возвращаемся к управляемым языкам.
Мусью знает, что для вектора этот оператор лезет в кучу, а не на стек. И что в каноничном плюсовом коде в основном используются итераторы, а не []. А уж там, где идёт обработка внешних данных, [] вообще не нужен. Все проблемы начинаются, когда на плюсах пишут как на сях или когда считают себя самыми умными и вместо стандартных функций лезут в строки напрямую.
>для вектора этот оператор лезет в кучу, а не на стек.Равно как и итераторы, поскольку у классического vector память под буфер всегда выделяется в куче (если только не используется специализированный аллокатор)
> И что в каноничном плюсовом коде в основном /используются итераторы, а не []
В каноничном коде используются алгоритмы, работающие с итераторами, и если не заниматься арифметикой с итераторами, то набедокурить шансов меньше, конечно же. Вот только если нужно взять ровно одно значение по известному только во время выполнения индексу, то заменой [] может служить только at(), а итераторы только усложнят все.
В общем да, но, ситуация, когда нужно использовать одно значение - обычно совсем не та, где может быть атака. То есть бывает, конечно, но вероятность мала - обычно это разного рода переполнения. Вот и выходит, что те малые шансы, что остаются при нормальном плюсовом подходе, не особо оправдывают затраты, свойственные управляемым языкам - в том числе и затраты на проверку границ. Для особых случае есть другие подходы и другие языки, конечно.
Я понял, ты неправильно сагрился на /0. Пикантность ситуации заключаетсяв том, что проверки за выход границ в рантайме есть не что иное как управляемый язык.
Я сагрился на идею проверок в рантайме в основном. Хороший код их не требует - те же iterator/range/foreach, например.
> Даешь больше разных костылей.да уж. какой-бы полезной не была технология, всегда найдутся нытики, которых в ней будет что-то не устраивать
Грошь - цена гуманитариям называющих костыли технологиями.
Спасает только от очень ограниченного множества атак, остальные - пруцца!
> Спасает только от очень ограниченного множества атак, остальные - пруцца!А от дыр в ПоХаПе и питоне -- вообще не помогает!1
И вообще, ремни безопасности и трезвость -- спасают далеко не всегда, каски у рабочих на стройке -- не защитят от рояля (или бетонной плиты), а презерватив может в любой момент порваться ...
> и питонеКапитан О, чота ты увлекся. По сравнению с PHP Питон как армированный бетон.
> Питон как армированный бетон....после попадания в него ядерной ракеты.
Вот только недавно в убунте и дебиане разлетелись апдейты бидона закрывающие ПОЛДЮЖИНЫ CVE, включая удаленное выполнение кода. Сюрприз!
да эт понятно, непробиваемых защит пока не придумали, а всё, что придумали, имеет ограниченную эффективность
https://grsecurity.net/ очень много классов разных атак. Скажем от всех давно известных.
Так это АНБ в мэйнстримовых дистрах всё никак допуск не дает на задействование этих технологий?
Наверно. gradm конкурент selinux...
Главное производители процессоров добавляют аппаратные фичи необходимые для использования фич безопасности без потерь производительности.А в вопросе безопасности итак надо собирать всё с исходников.. Кто знает что там в бинарных дистрах накомпилили: http://www.opennet.me/opennews/art.shtml?num=42476
> фич безопасности без потерь производительности.Ага, отлично придумано - завендорлочить на новые процессоры прикрываясь безопасность :)
Никакого вендорлочества пока не заметил. Многие производители процов разных архитектур добавляют фичи для ускорения и аппаратной реализации разных аспектов безопасности.
Чтобы в более-менее приличном коде на плюсах получить ошибки такого рода - постараться надо, вообще-то. Но если правда оверхед такой малый - чего ж нет, тем более, что это всего лишь флаг компиляции - выкинуть всегда можно при надобности. Хотя мне очень интересны результаты бенчмарков не от авторов технологии.
> Но если правда оверхед такой малыйврут, конечно. Как всегда, сделали "удобный" синтетический тест и показали от него результат
Ну вот и поглядим. Мне самому не очень верится.
> SafeStack позволяет предотвратить получение контроля над помещёнными в стек указателями в программах на C/C++ через сохранение указателей (адреса возврата, указатели на функции и т.п.) в отдельной изолированной области памяти, доступ к которой производится только с использованием специальных проверок корректности обращения к памяти.А как на счёт рандомизации стека, позиционно независимых бинарей и ALSR в ядре Линукс?
Кто собирает проги gcc с флагами -f-stack-protector, -f-stack-protector-all и -pie ?
Кто использует PAX ядро с рандомизацией и защитой памяти?
Почему более 5 лет в seL4 доказали что рандомизация более быстра и не менее надёжна чем куча проверок!
Нормальные дистры линукса уже более 10 лет защищены:
https://wiki.gentoo.org/wiki/Hardened/Grsecurity2_Quickstart...
Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable shared library bss : Killed
Executable shared library data : Killed
Executable anonymous mapping (mprotect) : Killed
Executable bss (mprotect) : Killed
Executable data (mprotect) : Killed
Executable heap (mprotect) : Killed
Executable stack (mprotect) : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Writable text segments : Killed
Anonymous mapping randomisation test : 16 bits (guessed)
Heap randomisation test (ET_EXEC) : 13 bits (guessed)
Heap randomisation test (PIE) : 25 bits (guessed)
Main executable randomisation (ET_EXEC) : 16 bits (guessed)
Main executable randomisation (PIE) : 17 bits (guessed)
Shared library randomisation test : 16 bits (guessed)
Stack randomisation test (SEGMEXEC) : 23 bits (guessed)
Stack randomisation test (PAGEEXEC) : 32 bits (guessed)
Return to function (strcpy) : Killed
Return to function (memcpy) : Killed
Return to function (strcpy, RANDEXEC) : Killed
Return to function (memcpy, RANDEXEC) : Killed
У всего есть своя область применения. Рандомизация не дружит с prelink, -f-stack-protector сотоварищи (и PIE) просаживают производительность. Эти ребята заявляют, что их подход даёт практически бесплатную защиту стека.
> У всего есть своя область применения.Мы говорим о безопасности скомпиленных программ. То есть об одной области.
> не дружит с prelink
Да, prelink должен быть удалён с системы и не использоватся больше по причине безопасности!
Позиционно независимые бинари итак его игнорируют и не используют больше.
> -f-stack-protector сотоварищи (и PIE) просаживают производительность.https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity...
На каких архитектурах и процессорах?
Утверждаю что если защита памяти построена на базе страниц памяти и система работает на архитектуре alpha, avr32, ia64, parisc, sparc, sparc64, x86_64 и даже i386
с аппаратным non-executable bit то НИКАКОГО УМЕНЬШЕНИЯ ПРОИЗВОДИТЕЛЬНОСТИ ВООБЩЕ НЕ БУДЕТ!
Ну а вот эта штука с прелинком дружит и при этом от так защищает. И нет, область не одна - есть ситуации, где безопасность абсолютно критична. А есть - и гораздо больше - где, в общем-то, можно и пережить. Вон, на винде народ регулярно троянов ловит и не умер до сих пор. А есть - где вообще пофигу - например, если это твоя собственная программа, вообще не выходящая за пределы твоей машины. Поэтому сколко за какую безопасность платить - дело индивидуальное.Кстати, твой non-executable bit уже сто раз обходили. Ну да, приходится вписывать не код, а адрес перехода и параметры вызова. А рандомизация в твоём варианте, насколько я понимаю, заставляет каждое приложение держать свой набор библиотек в памяти
> Да, prelink должен быть удалён с системы и не использоватся больше по причине безопасности!+, дебильный костыль, давно пора его убить.
> Да, prelink должен быть удалён с системы и не использоватся больше по
> причине безопасности!А если в целях безопаности удалить вообще кернель - представляете себе, как обломаются хакеры?
> позиционно независимых бинарейТак собирай с -pie - и будут позиционно независимые.
> и ALSR в ядре Линукс?
Так там давно уже сделано.
> Кто собирает проги gcc с флагами -f-stack-protector, -f-stack-protector-all и -pie ?
Ну, я. И дебианщики/убунтуи, например. У них даже скриптик hardening-check есть. Покажет насколько все хорошо или плохо с вполне конкретным бинарником.
Вы кстати еще -z now забыли. Immediate binding - зарубает ряд потенциально проблемных действий с подпихиванием левых библиотечных функций.
> Почему более 5 лет в seL4 доказали что рандомизация более быстра и
> не менее надёжна чем куча проверок!А хаксоры, тем не менее, так или иначе борятся с layout randomization, в том числе и выписывая эксплойты как position-independent :)
> Stack randomisation test (PAGEEXEC) : 32 bits (guessed)
И ты думаешь, хацкеры не смогут перебрать 32 бита? Нехорошо считать их за лохов, они это не любят и глушат эксплойтами.
>> позиционно независимых бинарей
> Так собирай с -pie - и будут позиционно независимые.
>> и ALSR в ядре Линукс?
> Так там давно уже сделано.
>> Кто собирает проги gcc с флагами -f-stack-protector, -f-stack-protector-all и -pie ?
> Ну, я. И дебианщики/убунтуи, например. У них даже скриптик hardening-check есть. Покажет
> насколько все хорошо или плохо с вполне конкретным бинарником.Да, и paxtest тоже дебиановцы написали. Но замечу два момента:
1. Не все проги в дистрах собираются с этими опциями, даже в Дебе.
2. Сборка PIE бинаря сама по себе ничего не даёт! Необходимо ядро С PAX ALSR патчами которое смижет рандомно выделить этим pie бинарям пямять.
> Вы кстати еще -z now забыли. Immediate binding - зарубает ряд потенциально
> проблемных действий с подпихиванием левых библиотечных функций.Там надо ещё много необходимых опций кроме pie & ssp
>> Почему более 5 лет в seL4 доказали что рандомизация более быстра и
>> не менее надёжна чем куча проверок!
> А хаксоры, тем не менее, так или иначе борятся с layout randomization,
> в том числе и выписывая эксплойты как position-independent :)
>> Stack randomisation test (PAGEEXEC) : 32 bits (guessed)
> И ты думаешь, хацкеры не смогут перебрать 32 бита? Нехорошо считать их
> за лохов, они это не любят и глушат эксплойтами.Примеры эксплоитов в студию.
Учти есть защита памяти!
https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity...
И любой процесс который её вызвал моментально убивается ядром! Действия логируются. Возможен запуск ответных действий: убить все процессы данного пользователя и блокировать его вход в систему; можно также вызвать панику ядра и остановить систему вовсе если атака успешна и получила root.
Угадать 32бит не сложно. Но не реально сделать это с первого раза, если ошибёшся сразу летит ответка.
Rust на LLVM, его безопасность тоже увеличится? Я всегда думал это задача программиста учитывать особенности языка. А задача компилятора - всё это оптимизировать и показать ошибки.
Раньше:mov eax, 10
push eax
cmp eax,ebxТеперь:
savemov eax, 10
savepush eax
savecmp eax,ebxПрогресс, ***та.
>[оверквотинг удален]
>
> mov eax, 10
> push eax
> cmp eax,ebx
>
> Теперь:
> savemov eax, 10
> savepush eax
> savecmp eax,ebx
>Прогресс, ***та.
>
> Вот же клоун, ***та.
Радуйся, что не:Call_virtual_machine (asm_code){
Call_virtual_safe_heap (asm_code);
...
}Call_virtual_safe_heap (asm_code) {
Move_asm_to_safe_zone (asm_code);
...
}И так через дюжину жирных фреймворков и виртуализаций
> И так через дюжину жирных фреймворков и виртуализацийЭнтерпрайзники благодарят вас за отличную идею!
>> И так через дюжину жирных фреймворков и виртуализаций
> Энтерпрайзники благодарят вас за отличную идею!Загляните в код Firefox сначала.
Ну глянул бы в исходники и не порол ***ты
Кто-нибудь может объяснить, почему просто не сделать два стека - один для данных, другой - для адресов возврата? Все же уже было в 68xx...
А заодно Гарвардскую архитектуру использовать ;-)
Кстати, а можно FreeBSD и ее порты собрать с -fsafe-stack? :)
clang 3.7 еще не вышел
The SafeStack pass to protect against stack-based memory corruption errors has been added. r239761.