Во-первых, не всё что под руку попадётся, а только ПО, которое находится в репозиториях. Во-вторых, не при каждом удобном случае, а в соответствии с настройками автообновлений.
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 — сомневаюсь.
> Нет, не предоставляется. Приведите пример подобной атаки, если Вам кажется, что это не так.
Нет, всё-таки предоставляется возможность не только вычислить, но и обойти Security Cookie, что бывает даже проще.
Вот ещё некоторые атаки на Guard Stack в Visual Studio.
1. Вызов исключения до проверки Cookie. То есть перезаписываем обработчик исключений и пролетаем мимо проверки куки.
2. Замена Cookie в стеке и в PE-секции данных (.data). Работает только при соблюдении некоторых условий.
3. Обойти Cookie можно тогда, когда указатели на объекты или структуры, передающиеся функции, находятся в стеке родительской функции (подделка виртуальной таблицы указателей).
4. Буферы, которые не содержат строки, указатели или массивы целых чисел, не защищены.
> Wishful thinking
Нет, эта защита реально ущербная, что подтвердилось конкретными фактами.
> вайн в убунте запускает екзешники как ни в чём не бывало просто с даблклика (вру, иногда нужно ещё chmod +x сделать).
Не иногда, а всегда без бита выполнения он ничего не запустит. Это если .exe на виндовом NTFS-разделе лежит, то тогда запускает сразу, потому что там по умолчанию стоит бит выполнения.
Дополнение к пункту 3: при более глубоком изучении выясняется, что в оптимизированном коде переменные адресуются через регистр ESP, поэтому дополнительный регистр им не нужен. Это фактически сводит на нет защиту кадра стека. Плюс этот Canary Word представляется возможность подобрать. В общем не защита, а чёрте что.
Робот на 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 — сомневаюсь.
Нет, всё-таки предоставляется возможность не только вычислить, но и обойти Security Cookie, что бывает даже проще.
Вот ещё некоторые атаки на Guard Stack в Visual Studio.
1. Вызов исключения до проверки Cookie. То есть перезаписываем обработчик исключений и пролетаем мимо проверки куки.
2. Замена Cookie в стеке и в PE-секции данных (.data). Работает только при соблюдении некоторых условий.
3. Обойти Cookie можно тогда, когда указатели на объекты или структуры, передающиеся функции, находятся в стеке родительской функции (подделка виртуальной таблицы указателей).
4. Буферы, которые не содержат строки, указатели или массивы целых чисел, не защищены.
> Wishful thinking
Нет, эта защита реально ущербная, что подтвердилось конкретными фактами.
Не иногда, а всегда без бита выполнения он ничего не запустит. Это если .exe на виндовом NTFS-разделе лежит, то тогда запускает сразу, потому что там по умолчанию стоит бит выполнения.