Во-первых, не всё что под руку попадётся, а только ПО, которое находится в репозиториях. Во-вторых, не при каждом удобном случае, а в соответствии с настройками автообновлений.
The /GS compiler option does not protect against all buffer overrun security attacks. For example, if you have a buffer and a vtable in an object, a buffer overrun could corrupt the vtable.
4.
/GS protects vulnerable parameters that are passed into a function. A vulnerable parameter is a pointer, a C++ reference, a C-structure (C++ POD type) that contains a pointer, or a GS buffer.
А также:
The compiler does not make copies of vulnerable parameters in the following situations:
Functions that do not contain a GS buffer.
Optimizations (/O options) are not enabled.
Functions that have a variable argument list (...).
Functions that are marked with naked.
Functions that contain inline assembly code in the first statement.
На счёт RTL: причём здесь все компиляторы, если я говорю конкретно про SSP, что он работает на уровне RTL? Если не понимаете о чём я говорю, то почитайте про то, как устроен SSP: www.seekline.net/misc/bachelor-thesis.pdf.
>> защита стека — Stack-Smashing Protector, интегрированный в gcc, значительно превосходит /GS из VS
> Нельзя ли подробнее?
Можно. Stack-Smashing Protector (в прошлом ProPolice) действует намного шире: он работает на уровне RTL (Register Transfer Language) — это промежуточный язык, генерируемый компилятором (расширяет возможности защиты, обеспечивает лучшую переносимость); защищает все регистры, сохранённые в прологе функции, а не только адрес возврата (в VS относительно надёжно защищается только адрес возврата); сортирует массив переменных на вершину стека, затрудняя их перезапись; защищает аргументы функций (делает их копии); защищает саму Canary Word от перезаписи.
А ведь атака на стек — это одна из самых популярных атак, поэтому необходимо уделять максимум внимания его защите. В Microsoft почему-то решили особо с этим не заморачиваться.
> Насчет «появления в линукс». PaX не был включен в состав основных дистрибутивов того времени (скорее всего из-за проблем со стабильностью).
Я о том, что об этом хотя бы решили позаботиться раньше. Например, в Ubuntu 6.06 (июнь 2006) уже точно была включена рандомизация по умолчанию, а это, примерно, на год раньше, чем в Windows.
> 2. ROP работает только в случае успешного обхода ASLR. Причем опять таки работает независимо от реализации DEP (другое название этой атаки — return-to-libc). Никаких преимуществ линукс здесь не имеет
Для реализации подобного рода атак необходимо успешно атаковать стек. Здесь Linux имеет преимущество в лице SSP, который я описал выше. Хотя соглашусь, сама реализация Non-Executable Memory в Linux преимуществ не имеет.
> Не подскажете, где посмотреть на обязательный статический анализ кода при сборке хотя бы ядра (не говоря уже о файрфоксах и пр.)? Где найти набор тестов с покрытием хотя бы 70% базовых блоков ВСЕЙ кодовой базы той жу убунту? Где fuzzer-ы (в том числе и white-box fuzzer-ы). Это о защите самого кода
> Если же говорить о механизмах безопасности в целом, то классические юникс-триплеты — идиотизм, из которого выросли костыли типа суперпользователя, suid/sgid.
Суперпользователя можно отключить и использовать настраиваемый sudo. От suid/sgid в будущем, надеюсь, откажутся.
> P.S. Безопасность линукса сосет.
Всё относительно. Например, отсносительно OpenBSD — да, где-то сосёт. А относительно Windows — сомневаюсь.
Помогаю. Правильней так: t 1z6 ;)
Робот на Suse Studio.
Всё предельно просто и понятно, даже кнопочка установки есть.
IPython + ipipe = объектный шелл на *nix
В Linux действительно с этим лучше дела обстоят — всё обновляется централизованно.
3.
4.
А также:
Подробней про всё это описано тут.
А вот примеры атак с подробным описанием.
> Иксперты атакуют. Примерно представляете, как работает sudo?
Прекрасно представляю. Не знаю что вам не понравилось.
> Вы ничего не знаете ни о линуксе ни о винде
Интересно, на основании чего сделан такой вывод?
> Нельзя ли подробнее?
Можно. Stack-Smashing Protector (в прошлом ProPolice) действует намного шире: он работает на уровне RTL (Register Transfer Language) — это промежуточный язык, генерируемый компилятором (расширяет возможности защиты, обеспечивает лучшую переносимость); защищает все регистры, сохранённые в прологе функции, а не только адрес возврата (в VS относительно надёжно защищается только адрес возврата); сортирует массив переменных на вершину стека, затрудняя их перезапись; защищает аргументы функций (делает их копии); защищает саму Canary Word от перезаписи.
А ведь атака на стек — это одна из самых популярных атак, поэтому необходимо уделять максимум внимания его защите. В Microsoft почему-то решили особо с этим не заморачиваться.
> Насчет «появления в линукс». PaX не был включен в состав основных дистрибутивов того времени (скорее всего из-за проблем со стабильностью).
Я о том, что об этом хотя бы решили позаботиться раньше. Например, в Ubuntu 6.06 (июнь 2006) уже точно была включена рандомизация по умолчанию, а это, примерно, на год раньше, чем в Windows.
> 2. ROP работает только в случае успешного обхода ASLR. Причем опять таки работает независимо от реализации DEP (другое название этой атаки — return-to-libc). Никаких преимуществ линукс здесь не имеет
Для реализации подобного рода атак необходимо успешно атаковать стек. Здесь Linux имеет преимущество в лице SSP, который я описал выше. Хотя соглашусь, сама реализация Non-Executable Memory в Linux преимуществ не имеет.
3. Про ущербность /GS в VS: habrahabr.ru/blogs/infosecurity/113091/#comment_3638126
> Не подскажете, где посмотреть на обязательный статический анализ кода при сборке хотя бы ядра (не говоря уже о файрфоксах и пр.)? Где найти набор тестов с покрытием хотя бы 70% базовых блоков ВСЕЙ кодовой базы той жу убунту? Где fuzzer-ы (в том числе и white-box fuzzer-ы). Это о защите самого кода
wiki.ubuntu.com/Security/Features#fortify-source — хотя бы так.
> Если же говорить о механизмах безопасности в целом, то классические юникс-триплеты — идиотизм, из которого выросли костыли типа суперпользователя, suid/sgid.
Суперпользователя можно отключить и использовать настраиваемый sudo. От suid/sgid в будущем, надеюсь, откажутся.
> P.S. Безопасность линукса сосет.
Всё относительно. Например, отсносительно OpenBSD — да, где-то сосёт. А относительно Windows — сомневаюсь.