Скрытые каналы и повседневная практика

"Баржа с грузом трески вошла в порт. Поспешите, товар скоропортящийся."

Г. Мопассан. "Заведение Телье"

В повседневной практике скрытые каналы трактуются шире, чем в теории. Расширение происходит по четырем направлениям:

• Рассматриваются системы с произвольной дисциплиной управления доступом (а не только с многоуровневой политикой безопасности);
• Рассматриваются не только нестандартные каналы передачи информации, но и нестандартные способы передачи информации по легальным каналам (потайные каналы);
• Рассматриваются угрозы не только конфиденциальности, но и целостности;
• Рассматриваются не только однонаправленные, но и двунаправленные каналы.

В повседневной практике скрытые каналы чаще всего возникают из-за возможности доступа к данным несколькими способами. Например, если в корневом каталоге файловой системы располагается tftp-сервер, он позволит получить всем пользователям доступ на чтение ко всем файлам, независимо от установленных прав доступа. Второй пример: если есть программа со взведенным битом переустановки действующего идентификатора пользователя, владельцем root и ... уязвимостью, то обычный пользователь может проэксплуатировать уязвимость, захватить привилегии суперпользователя и нарушить конфиденциальность и целостность чего угодно. Третий пример: пароль в незашифрованном виде, хранящийся в оперативной памяти и сбрасываемый в файл с образом памяти при аварийном завершении. Очевидно, число подобных примеров можно умножать до бесконечности.

Нестандартные способы передачи информации по легальным каналам получили название "подсознательных" или потайных каналов (subliminal channels), хотя по аналогии с наложенными сетями их лучше было назвать наложенными скрытыми каналами. Потайные каналы используют тогда, когда имеется легальный коммуникационный канал, но политика безопасности запрещает передавать по нему определенную информацию; иными словами, информацию передавать можно, но она не должна выглядеть подозрительно (в соответствии с некими, обычно не очень четкими критериями). Помимо разведчиков, в потайных каналах нуждаются хозяева "троянских" программ, таких, например, как Back Orifice или Netbus; если канал взаимодействия с ними будет явным, "троянца" быстро вычислят и уничтожат. Подобные каналы, используемые для управления, должны быть двунаправленными.

Потайной канал возможен тогда, когда в передаваемых легальных данных есть незначащие или почти незначащие биты, например, некоторые биты в заголовках IP-пакетов или младшие биты интенсивности цветов в графическом файле, присоединенном к письму. (Электронная почта — идеальный легальный канал, на который удобно накладывать скрытые.) В работе [9] рассматривается другой пример: нестандартный алгоритм электронной подписи, оставляющий место для тайных сообщений, не препятствующих проверке аутентичности ЭЦП.

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

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

Формальный способ усиления безопасности состоит в попытке добавить к употребительным операционным системам, таким как Linux, возможности, реализующие требования классов B2 и старше из "Оранжевой книги", то есть реализовать в ядре ОС мандатный доступ ко всем ресурсам и провести анализ скрытых каналов. Вне зависимости от выполнимости последнего пункта, подобный путь представляется тупиковым. Одно дело анализировать скрытые каналы в операционной системе мэйнфрейма, изначально спроектированной с учетом требований безопасности и прошедшей многолетнюю апробацию (см., например, [10]) и совсем другое — в ОС, содержащей ошибки, связанные с переполнением буферов. Для подлинной безопасности нужно не только добавление принудительного управления доступом, но и существенное перепроектирование ОС.

Содержательный способ борьбы со скрытыми каналами состоит в выстраивании эшелонированной обороны; утечки информации признаются неизбежными, но их пытаются локализовать и отследить. Для иллюстрации рассмотрим следующий гипотетический пример. Банк, информационная система которого имеет соединение с Интернет, защищенное межсетевым экраном, приобрел за рубежом автоматизированную банковскую систему (АБС). Изучение регистрационной информации экрана показало, что время от времени за рубеж отправляются IP-пакеты, содержащие какие-то непонятные данные. Стали разбираться, куда же пакеты направляются, и оказалось, что идут они в форму-разработчик АБС. Возникло подозрение, что в АБС встроены "троянская" программа и скрытый канал, чтобы получать информацию о деятельности банка. Связались с фирмой и в конце концов выяснили, что один из программистов не убрал из поставленного в банк варианта отладочную выдачу, которая была организована сетевым образом (как передача IP-пакетов специфического вида, с явно заданным IP-адресом рабочего места этого программиста). Если бы не межсетевой экран, канал оставался бы скрытым, а конфиденциальная информация о платежах свободно гуляла по сетям.

Конечно, мысль о необходимости эшелонированной обороны не нова; надо только не забыть реализовать ее на практике...

Еще один практически важный в данном контексте архитектурный принцип — разнесение доменов выполнения для приложений с разным уровнем доверия на разные узлы сети. Если такие приложения будут функционировать в распределенной среде клиент/сервер, ограничить их взаимное влияние (и, следовательно, заблокировать скрытые каналы) будет существенно проще, чем в случае единых многопользовательских систем.