Когда и как использовать функцию защиты стека GCC?

Я включил предупреждение -Wstack-protector при компиляции проекта, над которым я работаю (коммерческий многоплатформенный движок С++, который компилируется в Mac OS X 10.6 с GCC 4.2). Этот флаг предупреждает о функциях, которые не будут защищены от разбития стека, даже если -fstack-protector включен. GCC генерирует некоторые предупреждения при создании проекта:

не защищающая функция: без буфера длиной не менее 8 байтов
не защищая локальные переменные: буфер переменной длины

Для первого предупреждения я обнаружил, что можно настроить минимальный размер, который должен иметь буфер при использовании в функции, чтобы эта функция была защищена от разбиения стека: --param ssp-buffer-size=X можно использовать, где X равно 8 по умолчанию и может быть как 1.

Во втором предупреждении я не могу подавить его вхождения, если я не остановлю использование -Wstack-protector.

  • Когда следует использовать -fstack-protector? (как, например, во время dev или просто при отслеживании ошибок?)
  • Когда следует использовать -fstack-protector-all?
  • Что мне говорит -Wstack-protector? Является ли это предположением, что я уменьшаю минимальный размер буфера?
  • Если да, есть ли какие-либо недостатки, чтобы положить размер в 1?
  • Похоже, что -Wstack-protector - это не тот флаг, который вы хотите включить всегда, если вы хотите построить без предупреждения. Правильно ли это?

Ответы

Ответ 1

Защита стека - это упрочняющая стратегия, а не стратегия отладки. Если ваша игра поддерживает сеть или имеет данные, поступающие из неконтролируемого источника, включите ее. Если у него нет данных, поступающих откуда-то неконтролируемым, не включайте его.

Вот как это происходит: если у вас есть ошибка и сделайте изменение буфера на основе того, что может контролировать злоумышленник, этот злоумышленник может перезаписать обратный адрес или аналогичные части стека, чтобы заставить его выполнить свой код вместо вашего код. Защита стека прервет вашу программу, если она обнаружит это. Ваши пользователи не будут счастливы, но они тоже не будут взломаны. Это не та хакерская азартная игра, которая касается обмана в игре, это своего рода взлом, который касается кого-то, использующего уязвимость в вашем коде, чтобы создать эксплойт, который потенциально может заразить вашего пользователя.

Для решений, ориентированных на отладку, посмотрите на такие вещи, как mudflap.

Что касается ваших конкретных вопросов:

  • Используйте стековый защитник, если вы получаете данные из неконтролируемых источников. Ответ на это, вероятно, да. Так что используйте его. Даже если у вас нет данных из неконтролируемых источников, вы, вероятно, в конце концов или уже сделаете это и не осознаете этого.

  • Защита стеков для всех буферов может быть использована, если вы нуждаетесь в дополнительной защите в обмен на некоторый удар производительности. Из руководства gcc4.4.2:

      

    -fstack-протектор

             

    Извлеките дополнительный код, чтобы проверить переполнение буфера, например атаки с разбивкой по стеклу. Это делается путем добавления защитной переменной к функциям с уязвимыми объектами. Сюда входят функции, которые вызывают alloca, и функции с буферами размером более 8 байтов. Охранники инициализируются, когда функция вводится, а затем проверяется, когда функция выходит. Если проверка безопасности не удалась, выводится сообщение об ошибке, и программа завершает работу.

             

    -fstack-протектор-все

             

    Как -fstack-протектор, за исключением того, что все функции защищены.

      

  • Предупреждения сообщают вам, какие буферы защита стека не может защитить.

  • Не обязательно указывать, что вы уменьшаете свой минимальный размер буфера, а при размере 0/1 это то же самое, что и для стека-защитника. Это только указывает на это, чтобы вы могли, если вы решите переконфигурировать код, чтобы защитить буфер.
  • Нет, эти предупреждения не представляют проблемы, они просто указывают вам на информацию. Не используйте их регулярно.

Ответ 2

Вы действительно не должны заботиться о предупреждении для обычных сборок. Это действительно информационное сообщение. Я надеюсь, что очевидно, что у вас есть неотъемлемая проблема безопасности с буферами с переменным размером в стеке; неправильно вычисляйте размер, и вы открываете большую дыру.