>> защита стека — 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 представляется возможность подобрать. В общем не защита, а чёрте что.
Напомню, началось всё с того, что ccrypt заявил, что механизмы безопасности Linux не допустят полного контроля за системой. А не допустит этого банальное разграничение прав и работа из ограниченной учётной записи. Плюс те механизмы (по ссылке), которые предотвращают потенциальную эксплуатацию уязвимостей (атака на стек, кучу, перезапись указателей и т.д.), что сразу срезает целый спектр атак. Перечислю основное: защита стека — Stack-Smashing Protector, интегрированный в gcc, значительно превосходит /GS из VS; защита кучи; обфускация указателей; ASLR действует шире, чем в Windows (об этом ниже), Fortify Source, Non-Executable Memory и т.д.
Теперь про виндовые средства защиты.
1) ASLR. Во-первых, в «безопасном» Windows ASLR появился на 2 года позже, чем в Linux (что уже не важно, но как бы намекает). Во-вторых, по умолчанию ASLR в Windows распространяется только на исполняемые файлы и библиотеки, непосредственно прилинкованные с поддержкой ASLR, то есть сторонний софт остаётся незащищённым. В-третьих этот ASLR научились уже успешно обходить (JIT Spray).
2) Атаки на DEP (при помощи техники ROP): отключение DEP, вызовы VirtualProtеct/VirtualAlloc и memcp. Плюс всё тот же JIT Spray. Подробно.
3) Buffer overrun protection. Это вообще не совсем удачная попытка скопировать Stack Guard в Visual Studio. Canary Word защищает только адрес возврата и кадр стека. Остальные переменные остаются незащищёнными, что также позволяет перезаписывать указатели. По сути это позволяет переписать саму Canary Word, которая как раз-таки и защищает стек. К тому же, этот самый флаг компиляции /GS касается только защиты стека. А как же куча, целочисленные переполнения и прочее?
Давай-ка вопросом на вопрос отвечать и «стрелки переводить» не будем?
А про «buffer overrun protection, DEP, ASLR, ACL-ы, Code Integrity» рассказывать не надо. В Linux некоторые из этих технологий появились даже раньше, при чём в более лучшем исполнении.
> Ну давайте уже сравнительный анализ. Какие именно «механизмы безопасности линукс» не допустят, ага.
Возьмём самый популярный дистрибутив Linux'а — Ubuntu: wiki.ubuntu.com/Security/Features. А теперь объясните, какие преимущества перед этим имеет система безопасности Windows? Давайте проведём сравнительный анализ, если уж так хотите, вот только аналогичный списочек секьюрити-фич в Windows предоставьте.
И даже то, что некоторые технологии защиты появились раньше в Linux, чем в Windows вам тоже не о чём не говорит. В пример — ASLR и работа из ограниченного пользователя по умолчанию. Интересно, зачем разработчики этим занимаются, если, как вы говорите, никакой угрозы пока нет?
Я уже кидал ссылку, на которую вы ничего не смогли ответить: wiki.ubuntu.com/Security/Features. С каждым новым релизом дистрибутива количество возможностей обеспечения безопасности только увеличивается. Как минимум это говорит о том, что разработчики уже заботятся о безопасности системы. Так в чём же безопасность Ubuntu уступает Windows? Хотя бы приведите аналогичный список возможностей безопасности Windows — сравним.
> Более того ложное чувство неуязвимости будет толкать пользователей таких псевдозащищенных ОС на разные глупые поступки потому что они думают что правила безопасности не для них.
Может быть это проблема в пользователях, а не в ОС? Linux наоборот приучает ставить софт только из доверенных источников (репозиториев). А чтобы запустить скачанный бинарник, нужно сначала поставить бит выполнения. Как-то неудобно получается заразить свою систему, да?
> Ваш взгляд на широту системы защиты Linux не подтвержден ничем.
См. ссылку выше.
> Опять же никнейм и история о том как вас поймали за взломом, тоже на многое намекает.
Что не так с никнеймом? На что намекает та история? Якобы на мою некомпетентность? А свидетельства вашей компетентности в вопросах безопасности можете предоставить? И, вообще, как связано то, что меня поймали, с моими познаниями в области безопасности операционных систем? Вы ведь даже подробностей той истории не знаете. Так что не надо на личности переходить, а пишите по существу вопроса.
> Прошу показать исследования систем безопасности Linux которые неоспоримо подтвердят вашу точку зрения о превосходстве этой системы. До тех пор пока вы их не предоставите считаю ваши заявления сказками.
Вот вы любите просить ссылки на всякие исследования, и в то же время ваши слова на счёт будущего Linux — это не более чем ваши догадки. Я тоже считаю ваши ничем не подкреплённые заявления не более чем пророчествами.
> А под Windows вместо антивируса можно использовать DEP и UAC. Пока не дашь разрешения ничего не запустится. :)
Ага, теперь под Windows можно и без антивируса, а Linux'у, при наличии схожих систем защиты (даже более широких, на мой взгляд), вы предрекаете кучу атак и необходимость иметь антивирус?
Возникает противоречие и видится некая предвзятость.
> Нельзя ли подробнее?
Можно. 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-разделе лежит, то тогда запускает сразу, потому что там по умолчанию стоит бит выполнения.
Теперь про виндовые средства защиты.
1) ASLR. Во-первых, в «безопасном» Windows ASLR появился на 2 года позже, чем в Linux (что уже не важно, но как бы намекает). Во-вторых, по умолчанию ASLR в Windows распространяется только на исполняемые файлы и библиотеки, непосредственно прилинкованные с поддержкой ASLR, то есть сторонний софт остаётся незащищённым. В-третьих этот ASLR научились уже успешно обходить (JIT Spray).
2) Атаки на DEP (при помощи техники ROP): отключение DEP, вызовы VirtualProtеct/VirtualAlloc и memcp. Плюс всё тот же JIT Spray. Подробно.
3) Buffer overrun protection. Это вообще не совсем удачная попытка скопировать Stack Guard в Visual Studio. Canary Word защищает только адрес возврата и кадр стека. Остальные переменные остаются незащищёнными, что также позволяет перезаписывать указатели. По сути это позволяет переписать саму Canary Word, которая как раз-таки и защищает стек. К тому же, этот самый флаг компиляции /GS касается только защиты стека. А как же куча, целочисленные переполнения и прочее?
P.S. Безопасность Windows всё-таки сосёт.
А про «buffer overrun protection, DEP, ASLR, ACL-ы, Code Integrity» рассказывать не надо. В Linux некоторые из этих технологий появились даже раньше, при чём в более лучшем исполнении.
Возьмём самый популярный дистрибутив Linux'а — Ubuntu: wiki.ubuntu.com/Security/Features. А теперь объясните, какие преимущества перед этим имеет система безопасности Windows? Давайте проведём сравнительный анализ, если уж так хотите, вот только аналогичный списочек секьюрити-фич в Windows предоставьте.
Можно поподробнее?
Также ознакомьтесь: www.symantec.com/avcenter/reference/Address_Space_Layout_Randomization.pdf
> Более того ложное чувство неуязвимости будет толкать пользователей таких псевдозащищенных ОС на разные глупые поступки потому что они думают что правила безопасности не для них.
Может быть это проблема в пользователях, а не в ОС? Linux наоборот приучает ставить софт только из доверенных источников (репозиториев). А чтобы запустить скачанный бинарник, нужно сначала поставить бит выполнения. Как-то неудобно получается заразить свою систему, да?
> Ваш взгляд на широту системы защиты Linux не подтвержден ничем.
См. ссылку выше.
> Опять же никнейм и история о том как вас поймали за взломом, тоже на многое намекает.
Что не так с никнеймом? На что намекает та история? Якобы на мою некомпетентность? А свидетельства вашей компетентности в вопросах безопасности можете предоставить? И, вообще, как связано то, что меня поймали, с моими познаниями в области безопасности операционных систем? Вы ведь даже подробностей той истории не знаете. Так что не надо на личности переходить, а пишите по существу вопроса.
> Прошу показать исследования систем безопасности Linux которые неоспоримо подтвердят вашу точку зрения о превосходстве этой системы. До тех пор пока вы их не предоставите считаю ваши заявления сказками.
Вот вы любите просить ссылки на всякие исследования, и в то же время ваши слова на счёт будущего Linux — это не более чем ваши догадки. Я тоже считаю ваши ничем не подкреплённые заявления не более чем пророчествами.
Обход DEP и ASLR, используя технологию JIT Spray: www.exploit-db.com/exploits/14514/
www.exploit-db.com/exploits/14599/
Точно такую же атаку применяли, чтобы взломать IE8 и Firefox:
исследование.
Ага, теперь под Windows можно и без антивируса, а Linux'у, при наличии схожих систем защиты (даже более широких, на мой взгляд), вы предрекаете кучу атак и необходимость иметь антивирус?
Возникает противоречие и видится некая предвзятость.