Дэвид Лебланк - 19 смертных грехов, угрожающих безопасности программ

• Название: 19 смертных грехов, угрожающих безопасности программ
• Автор: Дэвид Лебланк
• Жанр: Программирование

Эта книга необходима всем разработчикам программного обеспечения, независимо от платформы, языка или вида приложений. В ней рассмотрены 19 грехов, угрожающих безопасности программ, и показано, как от них избавиться. Рассмотрены уязвимости на языках C/C++, C#, Java, Visual Basic, Visual Basic.NET, Perl, Python в операционных системах Windows, Unix, Linux, Mac OS, Novell Netware. Авторы издания, Майкл Ховард и Дэвид Лебланк, обучают программистов, как писать безопасный код в компании Microsoft. На различных примерах продемонстрированы как сами ошибки, так и способы их исправления и защиты от них. Если вы программист, то вам просто необходимо прочесть эту книгу.

Перевод: А. Слинкин

---

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

...

type Age is new Integer range 0..200;

Нюансы разнятся в языках. В С и С++ применяются настоящие целые типы. В современных версиях Visual Basic все числа представляются типом Variant, где хранятся как числа с плавающей точкой; если объявить переменную типа int и записать в нее результат деления 5 на 4, то получится не 1, а 1.25. У Perl свой подход. В С# проблема усугубляется тем, что в ряде случаев этот язык настаивает на использовании целых со знаком, но затем спохватывается и улучшает ситуацию за счет использования ключевого слова «checked» (подробности в разделе «Греховный С#»).

Подверженные греху языки

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

Как происходит грехопадение

Результатом переполнения целого может быть все, что угодно: логическая ошибка, аварийный останов программы, эскалация привилегий или исполнение произвольного кода. Большинство современных атак направлены на то, чтобы заставить приложение допустить ошибку при выделении памяти, после чего противник сможет воспользоваться переполнением кучи. Если вы работаете на языках, отличных от C/C++, то, возможно, считаете себя защищенным от переполнений целого. Заблуждение! Логический просчет, возникший в результате усечения целого, стал причиной ошибки в сетевой файловой системе NFS (Network File System), из–за которого любой пользователь мог получить доступ к файлам от имени root.

Греховность С и С++

Даже если вы не пишете на С и С++, полезно взглянуть, какие грязные шутки могут сыграть с вами эти языки. Будучи языком сравнительно низкого уровня, С приносит безопасность в жертву быстродействию и готов преподнести целый ряд сюрпризов при работе с целыми числами. Большинство других языков на такое не способны, а некоторые, в частности С#, проделывают небезопасные вещи, только если им явно разрешить. Если вы понимаете, что можно делать с целыми в C/C++, то, наверное, отдаете себе отчет в том, что делаете нечто потенциально опасное, и не удивляетесь, почему написанное на Visual Basic .NET–приложение досаждает всякими исключениями. Даже если вы программируете только на языке высокого уровня, то все равно приходится обращаться к системным вызовам и внешним объектам, написанным на С или С++. Поэтому ваши ошибки могут проявиться как ошибки в вызываемых программах.

Операции приведения

Есть несколько типичных ситуаций, приводящих к переполнению целого. Одна из самых частых – незнакомство с порядком приведений и неявными приведениями, которые осуществляют некоторые операторы. Рассмотрим, например, такой код:

...

const long MAX_LEN = 0x7fff;

short len = strlen(input);

if (len < MAX_LEN)

// что-то сделать

Если даже не обращать внимания на усечение, то вот вопрос: в каком порядке производятся приведения типов при сравнении len и MAX_LEN? Стандарт языка гласит, что повышающее приведение следует выполнять перед сравнением; следовательно, len будет преобразовано из 16–разрядного целого со знаком в 32–разрядное целое со знаком. Это простое приведение, так как оба типа знаковые. Чтобы сохранить значение числа, оно расширяется с сохранением знака до более широкого типа. В данном случае мог бы получиться такой результат:

...

len = 0x100;

(long)len = 0x00000100;

ИЛИ

...

len = 0xffff;

(long)len = 0xfffffffff;

Поэтому если противник сумеет добиться того, чтобы len превысило 32К, то len станет отрицательным и останется таковым после расширения до 32 битов. Следовательно, после сравнения с MAX_LEN программа пойдет по неверному пути.

Вот как формулируются правила преобразования в С и С++:

Целое со знаком в более широкое целое со знаком. Меньшее значение расширяется со знаком, например приведение (char)0x7f к int дает 0x0000007f, но (char)0x80 становится равно 0xffffff80.

Целое со знаком в целое без знака того же размера. Комбинация битов сохраняется, значение может измениться или остаться неизменным. Так, (char)0xff (-1) после приведения к типу unsigned char становится равно 0xff, но ясно, что–1 и 255 – это не одно и то же.

Целое со знаком в более широкое целое без знака. Здесь сочетаются два предыдущих правила. Сначала производится расширение со знаком до знакового типа нужного размера, а затем приведение с сохранением комбинации битов. Это означает, что положительные числа ведут себя ожидаемым образом, а отрицательные могут дать неожиданный результат. Например, (char) -1 (0xff) после приведения к типу unsigned long становится равно 4 294 967 295 (0xffffffff).

Целое без знака в более широкое целое без знака. Это простейший случай: новое число дополняется нулями, чего вы обычно и ожидаете. Следовательно, (unsigned char)0xff после приведения к типу unsigned long становится равно

0x000000ff.

Целое без знака в целое со знаком того же размера. Так же как при приведении целого со знаком к целому без знака, комбинация битов сохраняется, а значение может измениться в зависимости от того, был ли старший (знаковый) бит равен 1 или 0.

Целое без знака в более широкое целое со знаком. Так же как при приведении целого без знака к более широкому целому без знака, значение сначала дополняется нулями до нужного беззнакового типа, а затем приводится к знаковому типу. Значение не изменяется, так что никаких сюрпризов в этом случае не бывает.

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

Преобразования при вызове операторов

Большинство программистов не подозревают, что одного лишь обращения к оператору достаточно для изменения типа результата. Обычно ничего страшного не происходит, но граничные случаи могут вас неприятно удивить. Вот код на С++, иллюстрирующий проблему:

...

template <typename T>

void WhatIsIt(T value)

{

if((T)-1 < 0)

printf("Со знаком");

else

printf("Без знака");

printf(" – %d бит\n", sizeof(T)*8);

}

Для простоты оставим в стороне случай смешанных операций над целыми и числами с плавающей точкой. Правила формулируются так:

□ если хотя бы один операнд имеет тип unsigned long, то оба операнда приводятся к типу unsigned long. Строго говоря, long и int – это два разных типа, но на современных машинах тот и другой имеют длину 32 бита, поэтому компилятор считает их эквивалентными;

□ во всех остальных случаях, когда длина операнда составляет 32 бита или меньше, операнды расширяются до типа int, и результатом является значение типа int.

Как правило, ничего неожиданного при этом не происходит, и неявное приведение в результате применения операторов может даже помочь избежать некоторых переполнений. Но бывают и сюрпризы. Во–первых, в системах, где имеется тип 64–разрядного целого, было бы логично ожидать, что коль скоро unsigned short и signed short приводятся к int, а операторное приведение не нарушает корректность результата (по крайней мере, если вы потом не выполняете понижающего приведения до 16 битов), то unsigned int и signed int будут приводиться к 64–разрядному типу (_int64). Если вы думаете, что все так и работает, то вынуждены вас разочаровать – по крайней мере, до той поры, когда стандарт C/C++ не станет трактовать 64–разрядные целые так же, как остальные.

Вторая неожиданность заключается в том, что поведение изменяется еще и в зависимости от оператора. Все арифметические операторы (+, – ,*,/,%) подчиняются приведенным выше правилам. Но им же подчиняются и поразрядные бинарные операторы (&,|,А); поэтому (unsigned short) | (unsigned short) дает int! Те же правила в языке С распространяются на булевские операторы (&&,|| и !), тогда как в С++ возвращается значение встроенного типа bool. Дополнительную путаницу вносит тот факт, что одни унарные операторы модифицируют тип, а другие–нет. Оператор дополнения до единицы (~) изменяет тип результата, поэтому -((unsigned short)0) дает int, тогда как операторы префиксного и постфиксного инкремента и декремента (++, – ) типа не меняют.

Один программист с многолетним стажем работы предложил следующий код для проверки того, возникнет ли переполнение при сложении двух 16–разрядных целых без знака:

...

bool IsValidAddition(unsigned short x, unsigned short y)

{

if(x + y < x)

return false;

return true;

}

Вроде бы должно работать. Если результат сложения двух положительных чисел оказывается меньше какого–то слагаемого, очевидно, что–то не в порядке. Точно такой же код должен работать и для чисел типа unsigned long. Увы, программист не учел, что компилятор оптимизирует всю функцию так, что она будет возвращать true.