 |
|
|
|
Можно ли защититься от переполнения буферов?
Можно ли защититься от переполнения буферов? Умные в споре ищут истину, глупцы – выясняют, кто умнее. Народное На рынке имеется множество средств как коммерческих, так и бесплатных, обещающих решить проблему переполняющихся буферов раз и навсегда, но хакеры ломают широко разрекламированные защитные комплексы один за другим. Почему? Давайте заглянем под капот Stack-Guard, Stack-Shield, Pro-Police и Microsoft Visual Studio .NET, сравнив заявленные возможности с реальными. Ошибки переполнения вездесущи – это факт. Буквально каждые несколько дней обнаруживается новая дыра, а сколько дыр остаются необнаруженными – приходится только гадать. Как с ними борются? Арсенал имеющихся средств довольно разнообразен и простирается от аппаратных защит типа NX/XD-битов до статических анализаторов наподобие Spilnt. В последнее время в обиход вошел термин «secure programming» и издано множество книг по безопасности, настоятельно рекомендующих использовать динамические средства защиты типа Stack-Guard, внедряющие в компилируемую программу дополнительный код, проверяющий целостность адреса возврата перед выходом из функции и предпринимающий другие действия, затрудняющие атаку. Расплатой за «безопасность» становятся снижение производительности (впрочем, довольно незначительное) и необходимость перекомпиляции всего кода. Но это только внешняя сторона проблемы. Понадеявшись на широко разрекламированные защитные средства, разработчики расслабляются и… начинают строчить небрежный код, который StackGuard (StackShield/Pro-Police) все равно «исправит». Но что именно он правит? Давайте задвинем рекламу в сторону и посмотрим на защиту глазами хакера, который ломится не в дверь (там замок), и не в окно (там – сигнализация), а проникает через никем не охраняемую вентиляционную/канализационную трубу или даже дымоход. Все защитные механизмы, имеющиеся на рынке, спроектированы так, что дрожь берет. Сразу видно, что их создатели никогда не атаковали чужие системы, не писали shell-код и даже не общались с теми, кто всем этим занимается. Защита не только не останавливает атакующего, но в некоторых случаях даже упрощает атаку! Типы переполнения и типы защит Существует множество типов ошибок переполнения, подробно рассмотренных в статье [1]. Это:
Стековое переполнение – не только не единственное, но даже не самое популярное. Оператор new языка Си++ размещает переменные в динамической памяти, поэтому актуальность атак на кучу все растет, а к стеку интерес снижается. Ложка дорога к обеду. После драки кулаками не машут. Защитники стека явно опоздали и теперь подтасовывают факты и разводят рекламу. Вот цитата из документации на StackGuard: «…emits programs hardened against «stack smashing» attacks. Stack smashing attacks are the most common form of penetration attack. Programs that have been compiled with StackGuard are largely immune to stack smashing attack» («Stack-Guard закаляет программы против срыва стека – наиболее популярного типа удаленных атак. Программы, откомпилированные со Stack-Guard приобретают крепкий иммунитет против этого»). На самом деле Stack-Guard всего лишь затрудняет подмену адреса возврата, то есть противодействует подклассу стековых атак, причем противодействует весьма неумело. То же самое можно сказать и про остальные защиты, устанавливая которые мы не должны забывать, что они сражаются лишь с определенным типом атак, а на остальные просто не обращают внимания. Поскольку из рекламных проспектов (по недоразумению называемых «технической документацией») ничего конкретного выяснить невозможно, используем дизассемблер, достоверно показывающий, что делает та или иначе защита и чем она реально занимается. Stack-Guard Первым, кто бросил вызов переполняющимся буферам, был Stack-Guard, представляющий собой заплатку для компиляторов gcc и eggs, распространяемую по лицензии GPL. Раньше его было можно скачать с http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard или immunix.org, но сейчас эти ссылки мертвы, а проект заброшен. C тех пор как Immunix скупила Novell, Stack-Guard больше не поддерживается, во всяком случае найти какие бы то ни было упоминания о нем на официальном сайте мне не удалось. Исходный код сохранился только у «коллекционеров», как, например: http://www.packetstormsecurity.org/UNIX/utilities/stackguard. Тут может возникнуть вопрос: «Если Stack-Guard устарел и мертв, какой смысл его исследовать?». На самом деле смысл есть. Stack-Guard – простейший защитный механизм, расковыряв который, мы сможем разобраться и со всеми остальными, тем более что между ними наблюдается стройная эволюционная преемственность. Возьмем следующую программу с умышленно допущенной ошибкой переполнения и посмотрим, сможет ли StackGuard ее защитить. Листинг 1. Демонстрационная программа с переполняющимся буфером, которую мы будем защищать // дочерняя функция f(char *msg) { // объявляем локальные переменные int a; char buf[0x66]; // копируем аргумент в буфер без контроля длины, // что на определенном этапе приводит к его переполнению a = *strcpy(buf, msg); // выходим из функции return a; } // материнская функция int main(int argv, char **argc) { int x; x = f(argc[1]); } Откомпилируем файл компилятором gcc с настройками по умолчанию (то есть без оптимизации) и загрузим полученный elf в дизассемблер, чтобы посмотреть, как выглядит стандартный пролог/эпилог функции f(). Листинг 2. Дизассемблерный листинг исходной функции f с моими комментариями function_prologue: push ebp ; // сохраняем старый указатель кадра mov ebp, esp ; // открываем новый кадр стека sub esp, 98h ; // резервируем место под локальные переменные ; // тело программы mov eax, [ebp+arg_0] ; // копируем аргумент в регистр eax mov [esp+98h+var_94], eax ; // кладем eax в стек (выглядит как засылка eax ; // в локальную переменную но в действительности – ; // это такая передача аргументов, необычно, но компилятору удобно) lea eax, [ebp+var_88] ; // получаем указатель на локальную переменную var_88 mov [esp+98h+var_98], eax ; // кладем его в стек call _strcpy ; // вызываем _strcpy(&arg_0[0], &var_88[0]) movsx eax, byte ptr [eax] ; // eax = *((signed char*) eax); mov [ebp+var_C], eax ; // копируем eax в локальную переменную var_C mov eax, [ebp+var_C] ; // копируем содержимое var_C в eax function_epilogue: leave ; // mov esp, ebp/pop ebp retn ; // выходим в материнскую функцию Содержимое стека на момент вызова f() представляет конгломерат локальных переменных и служебных данных. На вершине стека лежит буфер, под ним располагается целочисленная переменная «a» (на самом деле порядок размещения переменных не стандартизован и целиком зависит от воли компилятора, то есть может быть любым). За локальными переменными следует сохраненный регистр указателя кадра стека (в x86 процессорах его роль обычно играет EBP), а за ним – адрес возврата и аргументы, переданные функции. Короче говоря, все это выглядит так: Листинг 3. Состояние стека на момент вызова функции f [ buf ] ; <-- переполняющийся буфер [ a ] ; <-- прочие локальные переменные [ ebp ] ; <-- сохраненный указатель кадра [ retaddr ] ; <-- адрес возврата в материнскую функцию [ arg 1 ] ; <-- аргументы, переданные функции [ --------- ] ; <-- \ [ --------- ] ; <-- +- кадр стека материнской функции [ --------- ] ; <-- / Переполняющийся буфер может воздействовать на следующие объекты:
Все эти атаки подробно описаны в моей статье [1], поэтому не будем повторяться, а лучше пропустим программу через Stack-Guard 1.0 и посмотрим, что это даст. Листинг 4. Дизассемблерный листинг функции f(), защищенной Stack-Guard (добавленные защитой строки выделены красным шрифтом) function_prologue: push 000AFF0Dh ; // забрасываем canary word на стек ; // (следовало это делать после сохранение ebp) push ebp ; // сохраняем старый указатель кадра в стеке mov ebp, esp ; // открываем новый кадр sub esp, 98h ; // резервируем место под локальные переменные ; // тело функции (точно такое же, как и в прошлый раз) function_epilogue: leave ; // закрываем кадр стека cmp esp,AFF0Dh ; // проверяем целостность canary word jne canary_changed ; // если canary изменено, прыгаем на canary_changed add esp,4 ; // удаляем canary из стека ret ; // возвращаемся в материнскую процедуру canary_changed: ; // завершаем выполнение программы call __canary_death_handler jmp . ; // если завершить не удалось — зацикливаемся Листинг 5. Состояние стека функции f() на момент завершения выполнения пролога и начала выполнения ее тела [ buf ] [ a ] [ ebp ] [ 000aff0dh ] [ retaddr ] [ arg 1 ] [ --------- ] [ --------- ] [ --------- ] После защиты Stack-Guard перед адресом возврата располагается константа 000AFF0Dh (в терминологии StackGuard – canary word), целостность которой проверяется перед выходом из функции. Суть в том, что комбинацию символов, слагающих canary word – \x00\x0A\xFF\x0D, очень трудно «воспроизвести» с помощью строковых функций, поскольку в языке Си символ нуля трактуется как «конец строки». Функция gets – одна из тех немногих, что обрабатывает ноль как обыкновенный символ, поскольку в качестве завершителя строки использует символ «возврата каретки». При работе с ASCIIZ-строками «подделать» canary word невозможно! Адрес возврата можно считать надежно защищенным. Ведь чтобы «дотянуться» до него, переполняющемуся буферу необходимо пересечь (и затереть) canary word! Разработчики торжествуют, а хакеры стреляются. Или… все-таки нет? Начнем с того, что на Unicode все эти ограничения не распространяются и canary word подделывается без труда (кстати говоря, пилотная версия Stack-Guard в качестве сторожевого слова использовала 00000000h, что в Unicode уже не воспроизводится, но может быть введено с помощью функции gets, которая сегодня практически никем и нигде не используется). К тому же приложения, обрабатывающие двоичные данные функциями типа memcpy, также остаются беззащитными. Локальные переменные и указатель кадра стека вообще никак не защищены и могут быть беспрепятственно атакованы. Если среди этих переменных присутствует хотя бы один указатель на функцию, вызываемую после переполнения, хакер сможет подменить его адрес, передавая управление на свой shell-код. Конструкция типа «int *x; int a; … x = a;», которая к числу экзотических никак не относится, позволяет атакующему модифицировать любые указатели на функции, в том числе и адрес возврата, и защита canary word уже не срабатывает, поскольку сторожевое слово остается в неприкосновенности. Образно говоря, это как положить «перед шматком сала грозный капкан». Тот, кто идет напрямую (классическое последовательное переполнение), попадет в него прежде, чем успеет полакомиться. Но если десантироваться прямо на сало путем воздействия на переменные-указатели – капкан отдыхает (правда, в этом случае необходимо знать точное положение вершины стека на момент атаки, что не всегда возможно, поэтому хакеры предпочитают модифицировать таблицу импорта в Windows, а в UNIX – секцию got). Рассмотрим самый сложный случай, когда никаких переменных в нашем распоряжении нет, а есть только сохраненный регистр кадра стека, который мы и будем атаковать. Фатальной ошибкой Stack-Guard явилось то, что он не учел «побочных эффектов» инструкции leave, которая работает так: «mov esp, ebp/pop ebp», позволяя хакеру воздействовать на кадр материнской функции. Если в каком-то месте стека или кучи атакующему удастся «сложить» конструкцию «000AFF0Dh &shell-code», (что в переводе на русский звучит как: canary-word за которым следует указатель на shell-код), ему остается всего лишь подменить сохраненный EBP на адрес «своего» canary-word. Тогда при выходе из материнской функции управление будет передано на shell-код! Атаки этого типа называются ret2ret и давно описаны в хакерской литературе, однако какого-либо практического приложения они так и не получили, поскольку в оптимизированных эпилогах (ключ -O2) вместо инструкции leave компилятор использует более быстродействующую конструкцию «add esp,x/pop ebp», и побочный эффект воздействия на ESP исчезает. В оптимизированном эпилоге хакер может воздействовать только на стековый кадр материнской функции, «подсовывая» ей те значения локальных переменных, которые он захочет. Для успешной реализации атаки этого обычно оказывается вполне достаточно. В версии 2.0 защита адреса возврата была как бы усилена – в нем появился случайный canary word, хранящийся в read-only памяти и «шифрующий» адрес возврата по XOR. Угадать 32-битный canary word – нереально, но это и не нужно! Достаточно подсунуть заведомо ложное значение. Тогда, убедившись, что стек переполнен и хакеры хакерствуют, как крысы в амбаре, Stack-Guard передаст управление функции __canary_death_handler, которая завершает выполнение программы, устраивая настоящий DoS. Но лучше DoS, чем захват управления!
Рисунок 1. Адрес возврата по XOR случайным canary Весь фокус в том, что указатель на __canary_death_handler размещается в глобальной таблице смещений – GOT и может быть атакован путем воздействия на локальные переменные через уязвимый указатель кадра стека. Если такие переменные действительно есть (а куда бы они подевались?), хакер просто перенаправляет __canary_death_handler на свой shell-код! В последующих версиях Stack-Guard canary world «переехал» на одну позицию вверх, взяв под свою защиту и указатель кадра, однако дальнейшего развития проект не получил и постепенно сдулся. Microsoft Visual Studio .NET Озабоченная последними хакерскими атаками, Microsoft реализовала в своем новом компиляторе Visual Studio .NET (бывший Visual C++) некоторую разновидность Stack-Guard в далеко не лучшей его «инаугурации». Никогда не разрабатывающая собственных продуктов, а только «ворующая» уже готовые (авторитетный товарищ Берзуков в своей софт-панораме об этом только и говорит, сходите на www.softpanorama.org/Bulletin/News/Archive/news078.txt, почитайте – там много интересного), Microsoft, как это часто и бывает, сама не поняла, что стащила и у кого. Ладно, все это лирика. Перейдем к фактам. При компиляции с ключом /GS компилятор добавляет в код security cookie – так в терминологии Microsoft называется случайный 32-битный canary word, хранящийся в writable-памяти и инспектируемый функцией check_canary при выходе из функции: Листинг 6. Дизассемблерный листинг функции f(), откомпилированной Microsoft .NET с ключом /GS (добавленные защитой строки выделены красным шрифтом) function _prologue: push ebp ; // сохраняем прежний указатель кадра mov ebp, esp ; // открываем новый кадр sub esp, 9Ch ; // резервируем место для локальных переменных и canary push edx ; \ push esi ; + - сохраняем регистры, которые будут изменены push edi ; / mov eax, [canary] ; // копируем глобальный canary в eax xor eax, [esp+10h]; ; // сравниваем адрес возврата с canary mov [ebp-10h],eax ; // кладем результат на стек, защищая указатель кадра ; // тело функции ; (не совсем такое же, как и в прошлый раз, но различия между компиляторами к делу не относятся) function_epilogue: mov ecx, [epb-10h] ; // копируем сравненный canary в ecx xor ecx, [ebp+10h] ; // сравниваем адрес возврата и кладем его в ecx call check_canary ; // вызываем функцию проверки canary pop edi ; \ pop esi ; + - восстанавливаем регистры pop ebx ; / mov esp, ebp ; // закрываем кадры стека небезопасным путем pop ebp ; // (Microsoft повторяет ошибку Stack Guard) ret ; // выходим в материнскую функцию check_canary: ; // функция проверки canary cmp ecx, [canary] ; // сравниваем переданный ecx с глобальным canary jnz canary_changed ; // если не совпадают – завершаем программу ret ; // все ок, продолжаем выполнение программы Canary word защищает не только адрес возврата, но и кадр, что очень хорошо, правда, в оптимизированном коде, генерируемый этим же самым компилятором, локальные переменные адресуются непосредственно через ESP, и дополнительный регистр им не нужен, поэтому фактически защищается только один адрес возврата. Остальные переменные остаются незащищенными, что открывает простор для махинаций с указателями. В частности, хакер может перезаписать глобальную переменную canary своим значением – тогда его проверка пройдет нормально. Это даже упрощает (!) атаку: в незащищенной системе существует проблема ввода «запрещенных» символов, которую не всегда возможно обойти. Операция XOR позволяет генерировать любые символы! В частности, чтобы сформировать символ нуля, достаточно положить в canary и зашифрованный адрес возврата два одинаковых символа. Как известно «X XOR X = 0». Остальные символы генерируются аналогичным способом. Самое интересное, что Microsoft переняла ошибку ранних версий Stack-Guard, причем даже не его ошибку, а особенность поведения компилятора gcc, позволяющую атакующему воздействовать на регистр ESP через модификацию указателя кадра стека. Microsoft Visual C++ 6.0 закрывал кадр стека безопасной конструкций «ADD ESP,XXX», а .NET вместо этого использует «MOV ESP, EBP». И хотя указатель кадра защищен canary word, это еще не повод ослаблять защиту! Canary word генерируется не совсем случайным путем, и угадать его с нескольких попыток вполне реально, ну а инструкция XOR позволит подделать любой символ. Короче говоря, если бы в Microsoft думали головой… Stack-Shield Несмотря на схожесть в названии со своим собратом, ShackShield действует совсем по другому принципу. Это еще одно расширение к gcc, последнюю версию которого можно скачать с http://www.angelfire.com/sk/stackshield, но иного типа. Если Stack-Guard реализован как патч к компилятору, «исправляющий» function_prologue и function_epilogue, то Stack-Shield «захватывает» ассемблерные файлы, сгенерированные компилятором (в UNIXмире они имеют расширение .S), обрабатывает их, выплевывая защищенный ассемблерный файл, возвращаемый компилятору для окончательной трансляции в двоичный код. Такая схема дает Stack-Shiled намного большие возможности, и мне сразу же захотелось посмотреть, как он ими воспользовался и можно ли его одолеть. Соблазненный процессорными архитектурами с разнесенным стеком (один стек для хранения адресов возврата, другой – для локальный переменных), создатель StackGuard попытался «проэмулировать» на x86 нечто подобное. Для этой цели он использовал глобальный массив retarray на 256 адресов: эпилог копирует текущий адрес на вершину массива, определяемую указателем retprt, а пролог «стягивает» этот адрес с вершины и передает ему управление. Эта эмуляция далека от идеала, но сохраненный в стеке адрес возврата в ней вообще не используется, и выполнение программы продолжится даже после того, как он будет затерт, что предотвращает DoS (впрочем, поскольку локальные переменные искажены, программа все равно рухнет). Листинг 7. Дизассемблерный листинг функции f(), защищенной Stack-Shield с настройками по умолчанию (добавленные защитой строки выделены красным шрифтом) function_prologue: push eax ; // сохраняем регистры, которые изменяет Stack-Shied push edx mov eax, offset retpt ; // копируем в eax смещение указателя массива retpt cmp rettop, eax ; // смотрим – есть ли еще место? jbe .LSHIELDPROLOG ; // если места нет, отказываемся от записи нового адреса mov edx, [esp+8] ; // заносим в edx адрес возврата со стека mov [eax], edx ; // сохраняем его в массиве адресов возврата .LSHIELDPROLOG: add [retptr],4 ; // увеличиваем указатель массива возвратов ; // на первый взгляд это явный баг, ; // но на самом деле – оптимизация! pop edx ; // восстанавливаем регистры назад pop eax ; push ebp ; // сохраняем старый указатель кадра стека mov ebp, esp ; // открываем новый кадр sub esp, 98h ; // резервируем место под локальные переменные ; // тело функции (такое же как в случае с Stack-Guard) function_epilogue: leave ; // закрываем кадр стека небезопасным путем push eax ; // сохраняем регистры push edx add [retptr], -4 ; // уменьшаем указатель массива возвратов mov eax, offset retptr ; // заносим в eax смещение массива возвратов cmp eax, rettop ; // как на счет свободного места? jbe .LSHIELDEPILOG ; // если места нет, значит и выталкивать нечего mov edx, [eax] ; // снимаем сохраненный адрес со стека возвратов mov [esp+8],edx ; // восстанавливаем стековый адрес не проверяя его .LSHIELDEPILOG: pop edx ; // восстанавливаем регистры pop eax ; ret ; // выходим в материнскую функцию При компиляции с ключом -d, Stack-Shiled вставляет дополнительную проверку, сравнивая адреса возврата на стеке и retarray. В случае расхождения вызывается функция SYS_exit, завершающая программу в аварийном режиме. Ключи -r и -g задействуют механизм «Ret Range Checking», проверяющий границы адресов возврата и останавливающий программу, если они выходят за пределы некоторой заранее заданной величины (т.е. находятся в куче или стеке). Таким образом, даже если хакер перезапишет retarray (а он находится в записываемой области памяти), подсунуть указатель на shell-код ему уже не удастся, правда, он может беспрепятственно вызывать функции библиотеки libc, передавая им любые аргументы (атака типа return-to-libc). Листинг 8. Дизассемблерный код, раскрывающий сущность механизма Ret Range Checking function_epilogue: leave ; // закрываем кадр стека небезопасным путем cmp [esp], offset shielddatabase ; // ^ проверяем границы адреса возврата jbe .LSHIELDRETRANGE ; // если все ок, то переходим на ret movl eax,1 ; // если мы здесь, то адрес возврата вышел movl ebx,-1 ; // за допустимые пределы, возможно он был изменен int 80h ; // завершаем выполнение программы .LSHIELDRETRANGE: ret ; // возвращаемся в материнскую процедуру Усилилась и защита локальных переменных. Теперь перед вызовом функции по указателю, Stack-Shield убеждается, что она находится в пределах сегмента кода: Листинг 9. Дизассемблерный код, показывающий как Stack-Shield контролирует указатели на функции ; // в eax находится указатель на функцию cmp eax, offset shielddatabase ; // проверяем границы указателя jbe .LSHIELDCALL ; // если указатель в границах, перехрдим на вызов функции mov eax,1 ; // указатель на функцию выходит за допустимые границы movl ebx,-1 ; // возможно, он был хакнут int 80h ; // завершаем выполнение программы .LSHIELDCALL: call [eax] ; // вызываем функцию по указателю Контроль за указателями на функции препятствует непосредственной передаче управления на shell-код, но не мешает хакеру использовать функции стандартной библиотеки libc и функции самой уязвимой программы. Указатели на данные также остаются незащищенными. Кроме того, при исчерпании массива адреса возвратов (что при глубокой вложенности функций имеет место быть) он автоматически переходит в «обычный» режим, в котором проверяет только границы адресов возврата, но не сами адреса. Хорошая новость, нечего сказать! Pro-Police Протектор Pro-Police, зародившийся в недрах японского отделения IBM (http://www.research.ibm.com/trl/projects/security/ssp), – это без преувеличения самый сложный и самый совершенный механизм, реализующий модель безопасного стека (Safe Stack Usage Model), который действительно защищает, а не разводит пропаганду, чтобы выбить очередной грант. Сражение с такой защитой любой самурай почтет за честь. Pro-Police зарывается намного глубже, чем Stack-Guard и работает на уровне RTL. Это не библиотека времени исполнения, это – промежуточный системно-независимый язык, генерируемый компилятором gcc и расшифровываемый как register transfer language. Абстрагирование от оборудования существенно упрощает портирование и Pro-Police поддерживает практически все современные платформы: x86, powerpc, alpha, sparc, mips, vax, m68k, amd64. Самая главная инновация – переупорядочивание локальных переменных. Pro-Police разбивает переменные на две группы: массивы и все остальные. На вершину кадра стека попадают обычные скалярные переменные. Массивы идут за ними. Переполняющиеся буферы могут воздействовать друг на друга, но до указателей уже не достать, во всяком случае не таким простым путем. Адрес возврата и указатель кадра защищены сторожевой константой guard, генерируемой произвольном образом. Это все тоже canary word, только в обличии новой терминологии. Листинг 10. Псевдокод уязвимой функции до защиты Pro-Police foo() { char *p; // локальная переменная-указатель char buf[128]; // локальный буфер gets (buf); // функция, которая этот буфер и переполняет } Листинг 11. Псевдокод функции, защищенной Pro-Police (добавленные защитой строки выделены красным шрифтом) Int32 random_number; // глобальный canary, генерируемый случайным образом foo () { volatile int32 guard; // локальная копия canary, охраняющая кадр char buf[128]; // буфер идет перед всеми локальными переменными! char *p; // локальная переменная-указатель guard = random_number; // копируем глобальный canary в лок. переменную gets (buf); // вызываем уязвимую функцию if (guard != random_number) /* program halts */ } Состояние стека на момент вызова функции f из листинга 1 под Pro-Police выглядит так: Листинг 12. Состояние стека функции foo() на момент завершения выполнения пролога, обратите внимание, что при переполнении буфера buf затирания локальных переменных уже не происходит! [ p ] [ buf ] [ guard ] [ ebp ] [ retaddr ] [ arg 1 ] [ --------- ] [ --------- ] [ --------- ] Сравните это с листингом 5. Разница незначительная, но принципиальная! По соображениям производительности, Pro-Police внедряет защиту адреса возврата только функции, содержащие буферы, которые потенциально могут быть переполнены. То есть Pro-Police совмещает в себе защитный механизм с системой аудита кода (рис. 2)!
Рисунок 2. Безопасная модель стека Pro-Police Pro-Police предусматривает даже такую неочевидную ситуацию, как подмена указателей, переданных в качестве аргументов, и надежно защищает их. В прологе аргументы копируются в промежуточные переменные, расположенные «над» переполняющимся буфером, а не «под» ним (где находятся оригинальные аргументы). В дальнейшем все обращения к аргументам осуществляются через промежуточные переменные следующим образом: Листинг 13. Псевдокод уязвимой функции, вызывающей функцию по указателю, передаваемому в качестве аргумента, до защиты Pro-Police foo (int a, void (*fn)()) { char buf[128]; // локальный буфер gets (buf); // функция, переполняющая буфер (*fn)(); // вызов функции по указателю, переданному // в качестве аргумента и затираемому при переполнении } Листинг 14. Псевдокод функции, защищенной Pro-Police (добавленные строки выделены красным шрифтом) Int32 random_number; // глобальный canary, генерируемый случайным образом foo (int a, void (*fn)()) // уязвимый аргумент-указатель { volatile int32 guard; // локальная копия canary, охраняющая кадр char buf[128]; // буфер идет перед переменными, но после аргументов (void *safefn)() = fn; // копируем аргумент во временную переменную guard = random_number; // копируем глобальный canary в локальную переменную gets (buf); // вызываем уязвимую функцию (*safefn)(); // вызываем функцию по скопированному указателю if (guard != random_number) /* program halts */ } При всей надежности Pro-Police отсутствие сторожевых слов между массивами делает атаку по-прежнему возможной, поскольку затирание нижеследующих массивов порождает целый каскад вторичных переполнений (особенно целочисленных), да и массивы из указателей не такая уж большая редкость. Тем не менее такая проверка (кстати говоря, обещанная в следующих версиях Pro-Police) приведет к существенному падению производительности, что явно пойдет не на пользу ее популярности. Сводная таблица различных защитных методов
Заключение Так все-таки можно защититься от переполняющихся буферов или нет? Pro-Police отсекает большое количество атак, но… все это атаки на стек, а помимо стека у нас еще есть целочисленное переполнение, спецификаторы и куча, которые Pro-Police даже не пытается охранять, поскольку они находятся вне его «департамента». Это не упрек, а скорее констатация факта. Личное наблюдение – прочитав несколько популярный статей и установив могучий Pro-Police, большинство знакомых мне программистов упускают из виду, что необходимо установить что-то еще. Безопасное программирование требует целого комплекса совокупных мер, жестоко карая за малейшие ошибки. Использовать Pro-Police, безусловно, стоит, равно как и компилировать программы с ключом /GS, однако необходимо помнить, что эта мера отнюдь не гарантирует защищенности, а всего лишь уменьшает вероятность атаки. Литература:
|
Крис Касперски
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
