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

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

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

Иногда имеет смысл выводить информацию об ошибках только локальным пользователям. Чтобы решить этот вопрос, взгляните на 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: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 и разрешениями.

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

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

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

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

Стоит подумать

□ О применении менее распространенных защитных механизмов, встроенных в операционную систему, в частности о шифровании на уровне файлов.

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

□ Об использовании модели Белла–ЛаПадулы, предпочтительно в виде готового механизма.

Грех 14. Некорректный доступ к файлам

В чем состоит грех

Найти в программе грех некорректного доступа к файлам довольно трудно, он легко может ускользнуть от внимания. В этом направлении можно выделить три типичные проблемы безопасности. Первая – это «гонки»: между моментом проверки условий защиты для файла и моментом использования этого файла часто есть некоторое окно, когда файл уязвим. Гонка обычно проистекает из–за ошибок синхронизации, вследствие чего один процесс может вмешаться в работу другого, открывая брешь для атаки.

Иногда противнику удается манипулировать путями, чтобы стереть важный файл или изменить параметры его защиты в промежуток времени между проверкой и действиями, основанными на результатах проверки. Целый ряд проблем безопасности возникает при удаленном доступе к файлам, например по протоколу SMB (Server Message Block) или NFS (Network File System). Чаще такого рода ошибки возникают при работе с временными файлами, поскольку каталоги, в которые создаются временные файлы, обычно открыты для всех. Поэтому, воспользовавшись гонкой, противник может обманом заставить вас открыть файл, который он будет контролировать, даже если вы предварительно убедились, что такого файла нет. Если вы вообще ничего не проверяете, а просто полагаетесь на уникальность имени файла, то будете неприятно удивлены, обнаружив, что противник контролирует файл с таким же именем. Раньше это была серьезная проблема в некоторых библиотечных функциях в UNIX, поскольку они генерировали детерминированные имена временных файлов, которые противник мог предсказать.

Вторая распространенная ошибка получила название «а это вовсе не файл». Суть ее в том, что программа открывает нечто, считая, что это файл на диске, тогда как фактически это нечто является ссылкой на другой файл, именем устройства или канала.

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

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

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

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

Как мы сказали, есть три возможные ошибки. Глубинная причина первой – «гонки» – заключается в том, что в большинстве современных операционных систем (Windows, Linux, Unix, Max OS X и прочих) приложение не изолировано, как может показаться. В любой момент его работу может прервать другой процесс, а приложение к этому может оказаться не готовым. Другими словами, некоторые файловые операции не являются атомарными. Гонка может привести к эскалации привилегий или отказу от обслуживания из–за краха или взаимной блокировки.

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

Другой вариант греха – открыть файл с переданным именем, не проверив, к чему это имя относится. В операционных системах типа Linux, Unix и Max OS X такая уязвимость проявляется обычно при неправильной работе с символическими ссылками. Программа думает, что открывает файл, тогда как на самом деле противник подсунул ей символическую ссылку. Это может привести к печальным последствиям, если процесс работает от имени пользователя root, так как root может удалить любой файл.