Представлена (http://permalink.gmane.org/gmane.comp.security.oss.general/1...) новая надстройка над GCC - Watchman (https://github.com/ewimberley/Watchman), нацеленная на выявление выходов за допустимые границы памяти и блокирование переполнений буферов в приложениях. Принцип действия Watchman сводится к добавлению дополнительных случайных данных в кучу и стек, с последующей их периодической проверкой. Подобные проверки негативно влияют на производительность, но оправданы в ситуациях, когда безопасности уделяется первостепенное внимание.
URL: http://permalink.gmane.org/gmane.comp.security.oss.general/1...
Новость: http://www.opennet.me/opennews/art.shtml?num=37841
Как оно по сравнению с SSP-патчами и защитой на уровне malloc в glibc ? На первый взгляд только проверяет чаще и рандомных данных пишет больше.
От кривых рук ни один патч не спасёт, особо в С. Так что, foreach in <limits.h> do ... вперед с песней.
> От кривых рук ни один патч не спасёт, особо в С.
> Так что, foreach in <limits.h> do ... вперед с песней.Павлик, переходи на C++, пользуй STL и BOOST, включи максимальный уровень предупреждений и спасёшься, ибaвaистину...
Эм, а использовать онное только для поиска выходов в процессе тестирования/дебага, не? Или виндус вей, выпускаем debug-версию, ибо в релизе падает xD
> ... Или виндус вей, выпускаем debug-версию, ибо в релизе падает xDВован, это ты клёво придумал, такой незамысловатый подход наверняка сберёг очень много твоего личного времени и нервов.
grsecurity с PaX все исправитРешать проблему нужно на уровне ядра а не софта, хотя оба варианта хороши
Ядро может контролировать поведение, но не всегда и не все. Очень упрощенно, вы запросили 1k памяти для массива, ядро в силу страничной организации выделило 4к, все, выход за пределы 1к это сугубо дело вашей программы. Так же не забываем что еще есть static, область стека, ядро сможет проконтроллировать сколько памяти выделить (а точнее отобразить) под стек и static, но все что происходит внутри уже выделенных страниц памяти ядру неподконтрольно.
>Ядро может контролировать поведение, но не всегда и не все.Всегда и все, или ядро не ядро.
> Очень упрощенно, вы запросили 1k памяти для массива, ядро в силу страничной организации выделило 4к, все, выход за пределы 1к это сугубо дело вашей программы.
Чего, чего?
>Так же не забываем что еще есть static, область стека, ядро сможет проконтроллировать сколько памяти выделить (а точнее отобразить) под стек и static, но все что происходит внутри уже выделенных страниц памяти ядру неподконтрольно.
Гуглить на тему дефрагментации памяти, менеджеров памяти, и т.д, и т.п. Много думать.
>>Ядро может контролировать поведение, но не всегда и не все.
> Всегда и все, или ядро не ядро.
>> Очень упрощенно, вы запросили 1k памяти для массива, ядро в силу страничной организации выделило 4к, все, выход за пределы 1к это сугубо дело вашей программы.
> Чего, чего?Не путаем выделение памяти в ядре и оптимизации которые может сделать malloc, или другой распределитель памяти в пространстве пользователя.
>>Так же не забываем что еще есть static, область стека, ядро сможет проконтроллировать сколько памяти выделить (а точнее отобразить) под стек и static, но все что происходит внутри уже выделенных страниц памяти ядру неподконтрольно.
> Гуглить на тему дефрагментации памяти, менеджеров памяти, и т.д, и т.п. Много
> думать.То же самое на тему mmu и страничной адресации.
Простите, влезу.> Всегда и все, или ядро не ядро.
Hint: почему корректность входящих параметров не проверяется во всех-всех функциях ядра (и не только его)?
> Чего, чего?
А что неясного?
> Гуглить на тему дефрагментации памяти, менеджеров памяти, и т.д, и т.п. Много думать.
Всегда приятно видеть образованных людей. Которые про гугл знают, в смысле.
Ничего, что эти вещи и в юзерспейсе расположены?
научите gcc не делать трамплины на стеке и будет вам радость с PAX.
> grsecurity с PaX все исправит
> Решать проблему нужно на уровне ядра а не софта, хотя оба варианта
> хороши17.12 Trampolines for Nested Functions
A trampoline is a small piece of code that is created at run time when the address of a nested function is taken. It normally resides on the stack, in the stack frame of the containing function. These macros tell GCC how to generate code to allocate and initialize a trampoline.
после чего запасаемся покорном когда часть софта перестает работать.
>> grsecurity с PaX все исправит
>> Решать проблему нужно на уровне ядра а не софта, хотя оба варианта
>> хороши
> 17.12 Trampolines for Nested Functions
> A trampoline is a small piece of code that is created at
> run time when the address of a nested function is taken.
> It normally resides on the stack, in the stack frame of
> the containing function. These macros tell GCC how to generate code
> to allocate and initialize a trampoline.
> после чего запасаемся покорном когда часть софта перестает работать.Делаем ставки на clang + MemorySanitizer + AddressSanitizer + valgrind и не используем gcc
А можно несколько примеров, когда без Nested Functions вообще никак? Которые gcc extension и отсутствуют в стандарте С.
> А можно несколько примеров, когда без Nested Functions вообще никак?можно и вооще без си. и даже без ассемблера — напрямую машинный код фигачить. только зачем? nested functions и compound statements — мегаудобные штуки. ну, нет их в стандарте — что ж теперь, кровью харкать?
>Принцип действия Watchman сводится к добавлению дополнительных случайных данных в кучу и стек, с последующей их периодической проверкойСлучайности не случайны. Это может защитить от ошибок переполнения буфера из за некорректных данных, но от целенаправленной атаки скорей всего не защитит.
Грабли Си такие грабли. И это вместо того, чтоб использовать адекватный(е) язык(и).