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

Атака с хронометражем Дэна Бернстайна на шифр АЕ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 имеется.

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

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

Разумеется, конфиденциальные данные нужно защищать с помощью подходящих средств, например списков АСЕ в Windows и Apple MAC OS X 10.4 Tiger или прав доступа в *nix.

Есть и другие защитные меры, такие, скажем, как шифрование (с корректной политикой управления ключами) и управление цифровыми правами (Digital Rights Management – DRM). Механизм DRM в этой книге не рассматривается, но вкратце его суть в том, что пользователь может явно определить, кому разрешено открывать, читать, модифицировать и передавать другим лицам содержимое документов, в частности электронной почты. Организация может создать шаблоны политик управления правами, которые определяют правила, применимые к содержимому документов. Конечно, надо быть готовым к тому, что кто–то окажется достаточно настойчив, чтобы обойти механизм DRM, но на практике немного найдется людей, способных на это.

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

Искупление греха в С# (и других языках)

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

try {

// код обращения к SQL-серверу опущен

} catch (SqlException se) {

Status = sqlstring + " failedrn";

foreach (SqlError e in se.Errors)

Status += e.Message + "rn";

WindowsIdentity user = WindowsIdentity.GetCurrent();

WindowsPrincipal prin = new WindowsPrincipal(user);

if (prin.IsInRole(WindowsBuiltInRole.Administrator))

Response.Write("Error" + Status);

else {

Response.Write("An error occured, please bug your admin");

// Записать данные в протокол Windows Application Event Log

EventLog.WriteEntry("SQLApp", Status.EventLogEntryType.Error);

}

}

Отметим, что некоторые приложения самостоятельно определяют привилегированных и доверенных пользователей, тогда нужно пользоваться встроенными в них или в среду исполнения механизмами управления доступом.

Учет локальности

Иногда имеет смысл выводить информацию об ошибках только локальным пользователям. Чтобы решить этот вопрос, взгляните на IP–адрес, по которому вы собираетесь отправлять данные. Если он отличается от 127.0.0.1 или его эквивалента в IPv6 (::1), не посылайте данные. Даже если это открытый IP–адрес самой текущей машины, отправленные на него пакеты обычно видны всем машинам в локальной сети.

Дополнительные защитные меры

Если приложение состоит из нескольких процессов, то некоторую помощь вам могут оказать такие защищенные ОС, как SE Linux, Trusted Solaris, или надстройки над ОС типа Argus PitBull (работает для Linux, Solaris и AIX). Обычно вы можете пометить данные на уровне файла, и система будет отслеживать их передачу между процессами.

Несколько более практичная рекомендация заключается в том, чтобы хранить все данные в зашифрованном виде, пока не возникнет необходимость показать их. Большинство операционных систем имеют средства для защиты данных на носителях. Так, Windows может автоматически шифровать файлы, размещенные в файловой системе EFS (Encrypted File System).

Можно также выполнять «контроль на выходе», то есть проверять корректность выводимых данных. Так, если некоторая часть приложения может выводить только числа, проверьте, что, кроме цифр, в выходном потоке ничего нет. О проверке входных данных мы слышим постоянно, но иногда имеет смысл проверять и выходные.

Другие ресурсы

□ «СасЬе–timing attacks on AES» by Daniel J. Bernstein: http://cr.yp.to/ antiforgery/cachetiming–20050414.pdf

□ «Cache for fun and profit» (атака на RSA на машинах с гипертредингом, аналогичная атака Бернстайна на AES) by Colin Percival: www.daemonology.net/ papers/htt.pdf

□ Computer security: Art and Science by Matt Bishop (Addison–Wesley, 2002), Chapter 5, «Confidentiality Policies»

□ Default Passwords: www.cirt.net/cgi–bin/passwd.pl

□ Windows Rights Management Services: www.microsoft.com/resources/ documentation/windowsserv/2003/all/rms/en–us/default.mspx

□ XrML (extensible Rights Markup Language): www.xrml.org

□ Encrypting File System overview: www.microsoft.com/resources/documentation/ windows/xp/all/proddocs/en–us/encrypt–overviewmspx

Резюме

Рекомендуется

□ Решите, кто должен иметь доступ к информации об ошибках и состоянии.

□ Пользуйтесь средствами операционной системы, в том числе списками ACL и разрешениями.

□ Пользуйтесь криптографическими средствами для защиты секретных данных.

Не рекомендуется

□ Не раскрывайте информацию о состоянии системы не заслуживающим доверия пользователям.

□ Не передавайте вместе с зашифрованными данными временные метки высокого разрешения. Если без временных меток не обойтись, уменьшите разрешение или включите их в состав зашифрованной полезной нагрузки (по возможности).