19 смертных грехов, угрожающих безопасности программ
Шрифт:
ImpersonateNamedPipeClient(hPipe);
DeleteFile(szFileName);
RevertToSelf;
Проблема в том, что если процесс работает от имени LocalSystem, а вызывает этот код низкопривилегированный пользователь, то обращение к DeleteFile может завершиться с ошибкой, так как у пользователя нет доступа к файлу. Надо полагать, именно этого вы и хотели. Но если функция олицетворения возвращает ошибку, то поток продолжает работать в контексте той учетной записи, от имени которой был запущен процесс. А это LocalSystem, и у нее, скорее всего, есть право на удаление файла! Итак, низкопривилегированный
В следующем примере обрабатываются все вообще исключения. Механизм структурной обработки исключений (SEH) в Windows работает для любого языка:
char *ReallySafeStrCopy(char *dest, const char *src) {
__try {
return strcpy(dst, src);
} __except (EXCEPTION_EXECUTE_HANDLER) {
// замаскировать ошибку
}
return dst;
}
Если в strcpy происходит ошибка из–за того, что длина src больше длины dest или src равно NULL, то вы понятия не имеете, в каком состоянии осталось приложение. Содержимое dst корректно? В зависимости от того, где размещен буфер dest, каково состояние кучи или стека? Ничего не известно, но приложение будет продолжать работать, возможно, даже несколько часов, пока, наконец, с грохотом не рухнет. Поскольку разрыв во времени между моментом ошибки и окончательным сбоем так велик, никакая отладка не поможет. Не поступайте так.
Греховность С++
В следующем примере оператор new не возбуждает исключения, поскольку вы явно запретили компилятору это делать! Если внутри new возникнет ошибка, а вы попробуете воспользоваться переменной р, беды не миновать.
try {
struct BigThing { double _d[16999]; };
BigThing *p = new (std::nothrow) BigThing[14999];
// воспользуемся p
} catch(std::bad_alloc& err) {
// обработать ошибку
}
В примере ниже программа ожидает исключения std::bad_alloc, но работает с библиотекой Microsoft Foundation Classes, в которой оператор new возбуждает исключение CMemory Exception:
try {
CString str = new CString(szSomeReallyLongString);
// воспользуемся str
} catch(std::bad_alloc& err) {
// обработать ошибку
}
Греховность C#, VB.NET и Java
На примере показанного ниже псевдокода демонстрируется, как не следует обрабатывать исключения. Здесь перехватываются все возможные исключения, а это, как и приведенный выше пример Windows SEH, может замаскировать ошибки.
try {
// (1) Загрузить XML-файл с диска
// (2) Извлечь из XML-данных URI
// (3) Открыть хранилище клиентских сертификатов и достать оттуда
// сертификат в формате X.509 и закрытый ключ клиента
// (4) Выполнить запрос на аутентификацию к серверу, определенному
// на шаге (2), используя сертификат и ключ из шага (3)
} catch (Exception e) {
// Обработать все возможные ошибки,
// включая и те, о которых я ничего не знаю
}
Упомянутые в этом примере функции могут возбуждать самые разнообразные исключения. Если речь идет о каркасе .NET, то к ним относятся: SecurityEx–ception, XmlException, IOException, ArgumentException, ObjectDisposedExcep–tion, NotSupportedException, FileNotFoimdException
и SocketException. Ваша часть программы действительно знает, как все их корректно обработать?Не поймите меня неправильно. Иногда перехват всех исключений – вещь совершенно нормальная, только убедитесь, что вы понимаете то, что делаете.
Родственные грехи
Этот грех стоит особняком, никакие другие с ним не связаны. Впрочем, первая его разновидность обсуждается более подробно в грехе 13.
Где искать ошибку
Так просто и не скажешь, нет характерных признаков. Самый эффективный способ – провести анализ кода.
Выявление ошибки на этапе анализа кода
Обращайте особое внимание на следующие конструкции:
Тестирование
Как отмечено выше, лучший способ обнаружить проявления греха заключается в анализе кода. Тестирование затруднительно, поскольку предполагается, что вы должны заставить функцию систематически возвращать ошибку. С точки зрения экономичности и затраченных усилий анализ кода – это самое дешевое средство.
Существуют некоторые инструменты, аналогичные lint, которые обнаруживают отсутствующие проверки кода возврата.
Примеры из реальной жизни
Следующий пример взят из базы данных CVE .
CAN–2004–0077 do_mremap в ядре Linux
Это, наверное, самая известная в недавней истории ошибка из разряда «забыл проверить возвращенное значение». Из–за нее были скомпрометированы многие Linux–машины, подключенные к сети Интернет. Обнаружившие ее люди подняли шумиху в прессе, а пример эксплойта можно найти по адресуvulnerabilities/isec–0014–mremap–unmap.txt.
Примечание. В конце 2003 – начале 2004 года в менеджере памяти, являющемся частью ядра Linux, был обнаружен целый ряд ошибок, в том числе две, относящиеся к теме этой главы. Не путайте эту ошибку с другой, касающейся механизма отображения адресов: CAN–2003–0985.
Искупление греха
Искупить грех можно, лишь выполняя следующие предписания:
□ Обрабатывайте в своем коде все относящиеся к делу исключения.
□ Не «глотайте» исключения.
□ Проверяйте возвращаемые значения, когда это необходимо.
Искупление греха в C/C++
В следующем фрагменте мы вместо использования макросов assert явно проверяем все аргументы функции и значение, возвращенное fopen.
Утверждения (assert) следует применять лишь для проверки условий, которые никогда не должны встречаться.
DWORD OpenFileContents(char *szFileName) {
if (szFileName == NULL || strlen(szFileName) <= 3)
return ERROR_BAD_ARGUMENTS;
FILE *f = fopen(szFileName, "r");
if (f == NULL)
return ERROR_FILE_NOT_FOUND;
// Можно работать с файлом
return 1;
}
Включенная в Microsoft Visual Studio .NET 2005 технология аннотирования исходного текста (Source code Annotation Language – SAL) помогает в числе прочих обнаружить и ошибки, связанные с проверкой возвращаемых значений. При компиляции показанного ниже кода будет выдано предупреждение: