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

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

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

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

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

  1. когда -fstack-protector использоваться? (как, например, все время во время dev, или только при отслеживании ошибок?)
  2. когда -fstack-protector-all использоваться?
  3. что это -Wstack-protector говоришь мне? Это предполагает, что я уменьшаю минимальный размер буфера?
  4. если да, есть ли какие-либо недостатки в установке размера до 1?
  5. получается, что -Wstack-protector Это не тот флаг, который вы хотите включить в любое время, если вы хотите построить без предупреждения. Это правда?

2 ответов


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

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

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

как к вашему специфическому вопросы:

  1. используйте Stack protector, если вы получаете данные из неконтролируемых источников. Ответ на этот вопрос, вероятно, да. Так используй его. Даже если у вас нет данных из неконтролируемых источников, вы, вероятно, рано или поздно это сделаете и не поймете.
  2. защита стека для всех буферов может использоваться, если вы хотите дополнительную защиту в обмен на некоторую производительность. От версии gcc4.4.2 руководство:

    - fstack-protector

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

    - fstack-защитник-все

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

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

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

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