The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"В LLVM/Clang добавлена техника защиты стека SafeStack"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"В LLVM/Clang добавлена техника защиты стека SafeStack"  +2 +/
Сообщение от opennews on 28-Июн-15, 09:36 
В компилятор 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
Новость: https://www.opennet.ru/opennews/art.shtml?num=42517

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от торкман on 28-Июн-15, 09:36 
А надо ли для этого переписывать что-то в ПО или пересборка данным цлангом сама всё сделает?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +4 +/
Сообщение от Ku Klux Klan on 28-Июн-15, 10:38 
-fsanitize=safe-stack
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

6. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +1 +/
Сообщение от Ku Klux Klan on 28-Июн-15, 11:03 
http://reviews.llvm.org/D6095
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "В LLVM/Clang добавлена техника защиты стека SafeStack"  –18 +/
Сообщение от Аноним (??) on 28-Июн-15, 10:04 
Даешь больше разных костылей.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +5 +/
Сообщение от bav (ok) on 28-Июн-15, 10:50 
> Даешь больше разных костылей.

Благородный дон предлагает переписать весь опасный софт на управляемых языках?

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

5. "В LLVM/Clang добавлена техника защиты стека SafeStack"  –9 +/
Сообщение от Аноним (??) on 28-Июн-15, 10:59 
Видимо да и я его в этом поддерживаю.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

8. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +10 +/
Сообщение от Ku Klux Klan on 28-Июн-15, 11:32 
Разработчики того что используешь, плюнут тебе на лицо за "переписать".
И в этом я их поддерживаю.
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

13. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +1 +/
Сообщение от Xasd (ok) on 28-Июн-15, 13:04 
а рано или поздно -- всё равно перепишут.

(на чём-то типа Rust, или что там будет после Rust?)

так-что хоть плюйся, хоть не плюйся, а "вечного" софта можно только по пальцам перещитать :-) ..

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

17. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +1 +/
Сообщение от Ku Klux Klan on 28-Июн-15, 13:57 
> так-что хоть плюйся

В твоих потных фантазиях

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

19. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Аноним (??) on 28-Июн-15, 14:13 
> В твоих потных фантазиях

И много у мусью приложений на коболе/алголе/фортране?

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

20. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Ku Klux Klan on 28-Июн-15, 14:14 
Ерланге Питоне Голанге
Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

24. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Аноним (??) on 28-Июн-15, 14:33 
> Ерланге Питоне Голанге

И как, много вы на этом уже написали ну хотя-бы операционок, для начала?

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

36. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Аноним (??) on 28-Июн-15, 15:00 
> Ерланге Питоне Голанге

Т.е. мусью изящно [s]слился[/s] перевел стрелки? Или мусье все еще использует базы данных на коболях? :)

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

51. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от anonnymous on 28-Июн-15, 18:32 
На коболе в пиндосии кое-где финсофт ещё крутится, на фортране брутальные математусы осваивают гранты, размер которых высчитан на старом финсофте на коболе.
Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

9. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +1 +/
Сообщение от bav (ok) on 28-Июн-15, 11:46 
Можешь начинать, мы тебя поддерживаем.
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

22. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Аноним (??) on 28-Июн-15, 14:31 
>  Видимо да и я его в этом поддерживаю.

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

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

45. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Аноним (??) on 28-Июн-15, 15:51 
> операционку
> для начала
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

61. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Аноним (??) on 29-Июн-15, 04:13 
>> операционку
>> для начала

Ну да, именно так. Без операционки вы на компьютере много не наработаете. Хотя, конечно, начинать надо с бутлоадера, чтобы совсем уж для начала. Но мы же гуманисты и предоставим хипстоте подумать как запускать операционку самостоятельно :). А то они засцут еще проц из питона инициализировать, а это уже не интересно...

Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

11. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Аноним (??) on 28-Июн-15, 11:58 
нет
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

15. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +2 +/
Сообщение от none7 (ok) on 28-Июн-15, 13:24 
Зачем на управляемых? С++ с контролем границ массива вполне достаточно, оптимизация любые лишние проверки просто съест. Останутся только те, которые программист не заметил. А от реализаций полагающихся на то, что где то в аргументах значение не приведёт к переполнению, нужно избавляться.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

18. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от bav (ok) on 28-Июн-15, 14:01 
> Зачем на управляемых?
> С++ с контролем границ массива

/0

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

21. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Crazy Alex (ok) on 28-Июн-15, 14:31 
Сюрприз - если писать на плюсах, а не его C-подмножестве, получить переполнение суметь надо. Но если мусью не знает, что такое vector - тем хуже для него.
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

31. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +1 +/
Сообщение от bav (ok) on 28-Июн-15, 14:47 
> Но если мусью не знает, что такое vector - тем хуже для него.

Мусью также знает что operator[] не делает проверок. И мы опять таки возвращаемся к управляемым языкам.

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

35. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +2 +/
Сообщение от Crazy Alex (ok) on 28-Июн-15, 14:59 
Мусью знает, что для вектора этот оператор лезет в кучу, а не на стек. И что в каноничном плюсовом коде в основном используются итераторы, а не []. А уж там, где идёт обработка внешних данных, [] вообще не нужен. Все проблемы начинаются, когда на плюсах пишут как на сях или когда считают себя самыми умными и вместо стандартных функций лезут в строки напрямую.
Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

43. "В LLVM/Clang добавлена техника защиты стека SafeStack"  –1 +/
Сообщение от Школьник (ok) on 28-Июн-15, 15:32 
>для вектора этот оператор лезет в кучу, а не на стек.

Равно как и итераторы, поскольку у классического vector память под буфер всегда выделяется в куче (если только не используется специализированный аллокатор)

> И что в каноничном плюсовом коде в основном /используются итераторы, а не []

В каноничном коде используются алгоритмы, работающие с итераторами, и если не заниматься арифметикой с итераторами, то набедокурить шансов меньше, конечно же. Вот только если нужно взять ровно одно значение по известному только во время выполнения индексу, то заменой [] может служить только at(), а итераторы только усложнят все.

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

48. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Crazy Alex (ok) on 28-Июн-15, 16:56 
В общем да, но,  ситуация, когда нужно использовать одно значение - обычно совсем не та, где может быть атака. То есть бывает, конечно, но вероятность мала - обычно это разного рода переполнения. Вот и выходит, что те малые шансы, что остаются при нормальном плюсовом подходе, не особо оправдывают затраты, свойственные управляемым языкам - в том числе и затраты на проверку границ. Для особых случае есть другие подходы и другие языки, конечно.
Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

32. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от bav (ok) on 28-Июн-15, 14:50 
Я понял, ты неправильно сагрился на /0. Пикантность ситуации заключаетсяв том, что проверки за выход границ в рантайме есть не что иное как управляемый язык.
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

37. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Crazy Alex (ok) on 28-Июн-15, 15:02 
Я сагрился на идею проверок в рантайме в основном. Хороший код их не требует - те же iterator/range/foreach, например.
Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

27. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +1 +/
Сообщение от Нанобот (ok) on 28-Июн-15, 14:37 
> Даешь больше разных костылей.

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

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

39. "В LLVM/Clang добавлена техника защиты стека SafeStack"  –1 +/
Сообщение от Аноним (??) on 28-Июн-15, 15:08 
Грошь - цена гуманитариям называющих костыли технологиями.
Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

14. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Аноним (??) on 28-Июн-15, 13:07 
Спасает только от очень ограниченного множества атак, остальные - пруцца!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

16. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Аноним (??) on 28-Июн-15, 13:30 
> Спасает только от очень ограниченного множества атак, остальные - пруцца!

А от дыр в ПоХаПе и питоне -- вообще не помогает!1

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

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

34. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +4 +/
Сообщение от Аноним (??) on 28-Июн-15, 14:55 
> и питоне

Капитан О, чота ты увлекся. По сравнению с PHP Питон как армированный бетон.

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

62. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Аноним (??) on 29-Июн-15, 04:15 
> Питон как армированный бетон.

...после попадания в него ядерной ракеты.

Вот только недавно в убунте и дебиане разлетелись апдейты бидона закрывающие ПОЛДЮЖИНЫ CVE, включая удаленное выполнение кода. Сюрприз!

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

25. "В LLVM/Clang добавлена техника защиты стека SafeStack"  –3 +/
Сообщение от Нанобот (ok) on 28-Июн-15, 14:35 
да эт понятно, непробиваемых защит пока не придумали, а всё, что придумали, имеет ограниченную эффективность
Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

30. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Аноним (??) on 28-Июн-15, 14:44 
https://grsecurity.net/ очень много классов разных атак. Скажем от всех давно известных.
Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

38. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Аноним (??) on 28-Июн-15, 15:04 
Так это АНБ в мэйнстримовых дистрах всё никак допуск не дает на задействование этих технологий?
Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

42. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Аноним (??) on 28-Июн-15, 15:31 
Наверно. gradm конкурент selinux...
Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

44. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Аноним (??) on 28-Июн-15, 15:40 
Главное производители процессоров добавляют аппаратные фичи необходимые для использования фич безопасности без потерь производительности.

А в вопросе безопасности итак надо собирать всё с исходников.. Кто знает что там в бинарных дистрах накомпилили: https://www.opennet.ru/opennews/art.shtml?num=42476

Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

63. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Аноним (??) on 29-Июн-15, 04:17 
> фич безопасности без потерь производительности.

Ага, отлично придумано - завендорлочить на новые процессоры прикрываясь безопасность :)

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

68. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Аноним (??) on 29-Июн-15, 11:28 
Никакого вендорлочества пока не заметил. Многие производители процов разных архитектур добавляют фичи для ускорения и аппаратной реализации разных аспектов безопасности.
Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

26. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +1 +/
Сообщение от Crazy Alex (ok) on 28-Июн-15, 14:37 
Чтобы в более-менее приличном коде на плюсах получить ошибки такого рода - постараться надо, вообще-то. Но если правда оверхед такой малый - чего ж нет, тем более, что это всего лишь флаг компиляции - выкинуть всегда можно при надобности. Хотя мне очень интересны результаты бенчмарков не от авторов технологии.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

53. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 28-Июн-15, 20:39 
>  Но если правда оверхед такой малый

врут, конечно. Как всегда, сделали "удобный" синтетический тест и показали от него результат

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

57. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Crazy Alex (ok) on 28-Июн-15, 21:45 
Ну вот и поглядим. Мне самому не очень верится.
Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

28. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Аноним (??) on 28-Июн-15, 14:38 
> 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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

33. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +3 +/
Сообщение от Crazy Alex (ok) on 28-Июн-15, 14:53 
У всего есть своя область применения. Рандомизация не дружит с prelink, -f-stack-protector сотоварищи (и PIE) просаживают производительность. Эти ребята заявляют, что их подход даёт практически бесплатную защиту стека.
Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

41. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Аноним (??) on 28-Июн-15, 15:28 
> У всего есть своя область применения.

Мы говорим о безопасности скомпиленных программ. То есть об одной области.

> не дружит с 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 то НИКАКОГО УМЕНЬШЕНИЯ ПРОИЗВОДИТЕЛЬНОСТИ ВООБЩЕ НЕ БУДЕТ!

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

49. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Crazy Alex (ok) on 28-Июн-15, 17:04 
Ну а вот эта штука с прелинком дружит и при этом от так защищает. И нет, область не одна - есть ситуации, где безопасность абсолютно критична. А есть - и гораздо больше - где, в общем-то, можно и пережить. Вон, на винде народ регулярно троянов ловит и не умер до сих пор. А есть - где вообще пофигу - например, если это твоя собственная программа, вообще не выходящая за пределы твоей машины. Поэтому сколко за какую безопасность платить - дело индивидуальное.

Кстати, твой non-executable bit уже сто раз обходили. Ну да, приходится вписывать не код, а адрес перехода и параметры вызова. А рандомизация в твоём варианте, насколько я понимаю, заставляет каждое приложение держать свой набор библиотек в памяти

Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

54. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 28-Июн-15, 20:41 
> Да, prelink должен быть удалён с системы и не использоватся больше по причине безопасности!

+, дебильный костыль, давно пора его убить.

Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

65. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +1 +/
Сообщение от Аноним (??) on 29-Июн-15, 04:31 
> Да, prelink должен быть удалён с системы и не использоватся больше по
> причине безопасности!

А если в целях безопаности удалить вообще кернель - представляете себе, как обломаются хакеры?

Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

64. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Аноним (??) on 29-Июн-15, 04:25 
> позиционно независимых бинарей

Так собирай с -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 бита? Нехорошо считать их за лохов, они это не любят и глушат эксплойтами.

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

69. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Аноним (??) on 29-Июн-15, 11:49 
>> позиционно независимых бинарей
> Так собирай с -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бит не сложно. Но не реально сделать это с первого раза, если ошибёшся сразу летит ответка.

Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

29. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Аноним (??) on 28-Июн-15, 14:43 
Rust на LLVM, его безопасность тоже увеличится? Я всегда думал это задача программиста учитывать особенности языка. А задача компилятора - всё это оптимизировать и показать ошибки.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

55. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от клоун on 28-Июн-15, 21:02 
Раньше:

mov eax, 10
push eax
cmp eax,ebx

Теперь:
savemov eax, 10
savepush eax
savecmp eax,ebx

Прогресс, ***та.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

56. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +1 +/
Сообщение от Аноним (??) on 28-Июн-15, 21:43 
>[оверквотинг удален]
>
> mov eax, 10
> push eax
> cmp eax,ebx
>
> Теперь:
> savemov eax, 10
> savepush eax
> savecmp eax,ebx
>

Прогресс, ***та.
>
> Вот же клоун, ***та.

Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

58. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Dz on 28-Июн-15, 23:27 
Радуйся, что не:

Call_virtual_machine (asm_code){
  Call_virtual_safe_heap (asm_code);
  ...
}

Call_virtual_safe_heap (asm_code) {
  Move_asm_to_safe_zone (asm_code);
  ...
}

И так через дюжину жирных фреймворков и виртуализаций

Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

59. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Аноним (??) on 29-Июн-15, 01:59 
> И так через дюжину жирных фреймворков и виртуализаций

Энтерпрайзники благодарят вас за отличную идею!


Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

74. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Аноним (??) on 30-Июн-15, 17:31 
>> И так через дюжину жирных фреймворков и виртуализаций
> Энтерпрайзники благодарят вас за отличную идею!

Загляните в код Firefox сначала.

Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

66. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от z (??) on 29-Июн-15, 10:46 
Ну глянул бы в исходники и не порол ***ты
Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

67. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Аноним (??) on 29-Июн-15, 10:59 
Кто-нибудь может объяснить, почему просто не сделать два стека - один для данных, другой - для адресов возврата? Все же уже было в 68xx...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

71. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Crazy Alex (ok) on 29-Июн-15, 14:04 
А заодно Гарвардскую архитектуру использовать ;-)
Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

70. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Аноним (??) on 29-Июн-15, 13:48 
Кстати, а можно FreeBSD и ее порты собрать с -fsafe-stack? :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

72. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Аноним (??) on 29-Июн-15, 14:13 
clang 3.7 еще не вышел
Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

73. "В LLVM/Clang добавлена техника защиты стека SafeStack"  +/
Сообщение от Аноним (??) on 29-Июн-15, 14:16 
The SafeStack pass to protect against stack-based memory corruption errors has been added. r239761.
Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру