19 смертных грехов, угрожающих безопасности программ

Виега Джон

Отыскав все вхождения этих ключевых слов, определите, передаются ли данные какой–нибудь функции вывода, которая может сообщить их противнику.

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

трудно. Ясно, что если имеются ветвления, то вариации во времени будут почти наверняка. Но есть множество неочевидных способов вызвать зависимость от времени, мы об этом уже говорили выше. Реализации криптографических алгоритмов следует подвергать сомнению, если в них не предприняты явные меры против атак с хронометражем. Удаленное проведение таких атак может и не привести к успеху, на практике их обычно проводят локально. Так что если у приложения есть локальные пользователи, то лучше перестраховаться, чем потом кусать локти.

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

Тестирование

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

Чтобы выяснить, возможна ли на практике атака с хронометражем, в общем случае придется прибегнуть к динамическому тестированию. К тому же надо разбираться в математической статистике. Мы не будем затрагивать здесь эту тему, а отошлем вас к работе Дэна Бернстайна (Dan Bernstein) по атакам с хронометражем на криптографические алгоритмы (см. раздел «Другие ресурсы»).

Имитация кражи ноутбука

Любопытства ради попробуйте сымитировать похищение ноутбука. Попросите кого–нибудь поработать с приложением, которое вы тестировали несколько недель, а потом сядьте за тот же компьютер и попытайтесь изучить данные, применяя различные бесчестные приемы, как то:

□ загрузка из другой операционной системы;

□ установка на одну машину двух ОС;

□ установка системы с выбором загрузчика (dual boot);

□ подбор какого–нибудь распространенного пароля для входа в систему.

Примеры из реальной жизни

Начнем с примеров атак с хронометражем, а затем перейдем к более традиционным способам утечки информации, о которых есть сообщения в базе данных CVE .

Атака с хронометражем Дэна Бернстайна на шифр АЕS

Дэн Бернстайн сумел провести удаленную атаку с хронометражем на реализацию AES в OpenSSL 0.9.7. Оказалось, что использованные в ней большие таблицы вытесняются из кэша, в результате чего время исполнения кода перестает быть постоянным. Операции и до некоторой степени поведение кэша зависят от ключа. Бернстайну удалось вскрыть защищенное соединение после просмотра примерно 50 Гб зашифрованных данных. Впрочем, нелишним будет одно предупреждение. Во–первых, он мог бы сделать атаку более изощренной и не собирать так много данных. Разумно предположить, что ключ можно было бы получить уже после анализа нескольких гигабайтов данных, а быть может, и того меньше.

Во–вторых, условия атаки были несколько надуманными. А именно предполагалось, что протокол

содержит незашифрованные временные метки высокого разрешения, включаемые сразу до и после выполнения операций алгоритма AES. Но искусственность примера еще не означает отсутствия реальной проблемы. Такая модель была принята лишь для минимизации «шума», чтобы получить как можно более чистый «сигнал». В реальной ситуации, когда на удаленной машине есть собственный генератор тактовой частоты, уровень шума будет выше, но провести подобную атаку все же возможно. Статистически противнику нужно лишь набрать такую выборку, чтобы можно было ясно отличить сигнал от шума.

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

Но если противник имеет доступ к физической машине, все становится гораздо серьезнее. Особенно при наличии аппаратуры гипертрединга. Атака Бернстайна работает на машине с гипертредингом не только против AES, но и против реализации шифра RSA, имеющего дело с открытым ключом (см. бюллетень CAN–2005–0109 в базе данных CVE).

Если вас беспокоят удаленные атаки против реализации AES, то Бернстайн предложил контрмеры против всех известных атак с хронометражем. Популярная реализация Брайана Гладмана защищена против таких атак (см. раздел «Другие ресурсы»). Насколько нам известно, другие реализации AES пока еще недоработаны в этом направлении.

CAN–2005–1411

ICUII – это программа для организации видеочата в реальном времени. В версии 7.0.0 есть ошибка, позволяющая неавторизованному пользователю увидеть пароли из–за слабого списка управления доступом (ACL) некоторым файлом, который разрешено читать всем.

CAN–2005–1133

Этот дефект в операционной системе IBM AS/400 дает классический пример утечки информации – система возвращает разные коды ошибок в зависимости от того, была ли попытка установить сеанс с РОРЗ–сервером неудачной из–за неверного имени пользователя или пароля. Подробное описание ошибки можно найти в статье «Enumeration of AS/400 users via РОРЗ» (www.veneracom/downloads/ Enumeration_of_AS400_users_via_pop3.pdf), а мы ограничимся простым примером:

...

+OK POP server ready

USER notauser

+OK POP server ready

PASS abcd

–ERR Logon attempt invalid CPF2204

USER mikey

+OK POP server ready

PASS abcd

–ERR Logon attempt invalid CPF22E2

Обратите внимание: код CPF2204 означает, что такого пользователя нет, а код CPF22E2 – что пользователь есть, но пароль неверен. Разные сообщения об ошибках очень полезны для противника, поскольку теперь он знает, что пользователя notauser не существует, а пользователь mikey имеется.

Искупление греха

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