Безопасность UNIX

Ø В этой главе:

Ø Механизм разделения привилегий

Ø Реализация и защита процессов

Ø Режимы выполнения процессов

Ø Механизмы вызова системных функций

Ø Средства межпроцессорного взаимодействия

Ø Пакет IPC (Interposes Communication)

Ø Ошибки реализации механизма разделяемой памяти

Ø Механизмы отладки приложений

Ø Идентификаторы процессов

"Прибор, защищаемый быстродействующим плавким предохранителем, сумеет защитить этот предохранитель, перегорев первым."

Пятый закон Мэрфи

На протяжении большинства своей истории Unix был исследовательской повозкой для университетских и промышленных исследователей. С взрывом дешевых рабочий станций Unix вступил в новую эру, эру распространяемой платформы. Это изменение легко датировать: это случилось, когда поставщики рабочих станций выделили свои компиляторы языка C из своего стандартного комплекта программного обеспечения для того, чтобы понизить цены для не разработчиков. Точная запись границ этого изменения слегка неясна, но в основном это произошло в 1990.

«Unix-haters handbook» Simson Garfinkel

В одно-пользовательских, однозадачных системах (наподобие MS-DOS) понятие «безопасность» обычно отсутствует в силу полной бессмысленности самой постановки вопроса. Одна машина, – один процесс и один супр-пользователь.

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

Ни у кого не вызывает удивления способность некорректно работающей программы, исполняющейся с наивысшими привилегиями, пустить злоумышленника в систему. Но возможно ли пользовательскому приложению захватить контроль над системой? Можно ли получить доступ к остальным пользовательским процессам? Вопросы не так глупы, как кажется.

Невозможно написать защищенную операционную систему без соответствующей аппаратной поддержки со стороны процессора. Иначе, очередная выполняемая инструкция может нейтрализовать или блокировать программный защитный механизм. Первые версии UNIX исполняли все задачи в одном адресном пространстве, и одна из них могла «дотянуться» до другой и произвольным образом вмешаться в ее работу. Современные микропроцессоры спроектированы с учетами требований безопасности и поддерживают логические адресные пространства, обеспечивают защиту отдельных регионов памяти и имеют, так называемые, «кольца защиты». С каждым кольцом связан набор инструкций определенных привилегий, подобранных таким образом, чтобы код, исполняющийся в менее привилегированном кольце, не мог повлиять на более привилегированное. Поэтому, в правильно спроектированной операционной системе при условии отсутствия ошибок реализации, пользовательский код не может получить привилегированного доступа.

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

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

Минимальной единицей исполнения в UNIX является процесс. Процесс (в простейшем определении) это последовательность операций выполнения программы. Но кроме машинных инструкций еще существуют данные и стек, причем каждый процесс выполняется в собственном адресном пространстве. Поэтому, технически более правильно говорить о процессе, как экземпляре выполняемой программы.

Каждый процесс в UNIX обладает собственным адресным пространством, набором регистров процессора и стеком, - все они определяют состояние процессора, иначе называемое контекстом. В адресном пространстве расположены: сегмент[111] исполняемого кода (в терминологии UNIX называемый «текстом» – text), сегмент данных (BSS – сокращение, позаимствованное из ассемблера для компьютера IBM 7090, расшифровывающиеся как " block started by symbol " – блок, начинающийся с символа) и сегмента стека (STACK). Сегменты “text” и “BSS” соответствуют одноименным секциям исполняемого файла, а сегмент стека формируется операционной системой автоматически, при создании процесса.

Врезка «замечание»

Названия секций “text” и “BBS” благополучно перекочевали в среду Windows. Убедиться в этом можно, запустив утилиту dumpbin (входит в SDK, поставляемый с любым Windows-компилятором), например, таким образом:

· dumpbin /SUMMARY C:\WINDOWS\SYSTEM\Netbios.dll

·

· Microsoft (R) COFF Binary File Dumper Version 6.00.8168

· Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

·

· Dump of file NETBIOS.DLL

·

· File Type: DLL

·

· Summary

·

· 1000 bss

· 1000 data

· 1000 edata

· 1000 idata

· 1000 rdata

· 1000 reloc

· 1000 text

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

Понять это можно, разобравшись в механизме переключения из режима задачи в режим ядра. В UNIX для перехода в привилегированный режим используются прерывания. Инструкция, вызывающая прерывание, автоматически переводит процессор в привилегированный режим и передает управление подпрограмме обработки прерывания. Существует специальная таблица прерываний (доступная только ядру операционной системы) в которой индекс каждой ячейки численно равен номеру прерывания и содержит адрес, на который будет передано управление в случае возникновения данного прерывания. Более подробно о прерываниях можно прочитать в любой толковой книге по ассемблеру и технической документации процессора.

Врезка «замечание»

В операционной системе LINUX для вызова системных функций используется прерывание 0x80, а в операционных системах, совместимых с System V для той же цели необходимо передать управление по фиксированному адресу 0007:00000000 (сегмент семь, смещение ноль). Номер вызываемой функции и передаваемые ей аргументы задаются в регистрах (в LIUX) или заталкиваются в стек (в системах, совместимых с System V).

Таким образом, использование прерываний (или фиксированного адреса) позволяет пользовательской задаче передать управление только на предусмотренные ядром подпрограммы, а не произвольный адрес памяти. Однако стек ядра прикладному коду не доступен, и передать аргументы функции обычным путем невозможно. Тем не менее, ядру доступно пространство памяти всех задач и оно в состоянии «вытащить» требуемые параметры самостоятельно. Конкретная реализация зависит от выбранной аппаратной платформы и поэтому не будет рассмотрена. Достаточно понять – прикладные программы не могут пагубно воздействовать на ядро (конечно при отсутствии в нем ошибок реализации).

В операционных системах наподобие MS-DOS (и первых версиях UNIX) существовала возможность обращаться с оборудованием в обход операционной системы, манипулируя непосредственно с портами ввода-вывода[112]. Современные процессоры при попытке пользовательского кода обратиться к порту, генерируют исключение, передавая управление операционной системе, предоставляя ей возможность самой расправиться со злоумышленником. В результате, доступ может быть отвергнут, а приложение, нарушившие субординацию – закрыто, или же ядро может эмулировать чтение (запись) в порт, не выполняя ее на самом деле.

На бумаге броне UNIX позавидовал бы любой крейсер средних размеров, но в действительности все не так гладко[113]. Многие системы оказались взломаны «благодаря» умению UNIX в аварийных ситуациях сбрасывать дамп памяти (core dump – на жаргоне русскоязычных программистов звучащий кора) в общедоступный файл на диск. Достаточно часто в нем удается обнаружить пароли или другую информацию, облегчающую проникновение в систему. Приверженцы UNIX уверяют, – уязвимость устраняется правильным администрированием. Но сколько на свете существует неопытных администраторов? Справедливо оценивать защищенность системы с настройками по умолчанию. А по умолчанию, посредством дампа памяти, один процесс может получать доступ к адресному пространству другого процесса, по крайней мере, на чтение.

Врезка «замечание» *

У Кена Томпсона есть автомобиль, который он помогал сконструировать. В отличие от большинства автомобилей, у него нет ни спидометра, ни указателя бензина, никаких из тех многочисленных лампочек, которые отравляют жизнь современному водителю. Взамен, если водитель делает ошибку, гигантский вопросительный знак загорается в центре приборной доски. "Опытный водитель", говорит Томпсон, "обычно узнает, что не так".

Аноним

Впрочем, ситуация действительно исправляется правильным администрированием системы и скорее относится к разряду проблем социальных (где найти каждому компьютеру хорошего администратора?) и психологических (оставлю-ка я все настойки по умолчанию!), не представляя никакой технической проблемы.

Хуже обстоит дело с разделяемыми областями памяти и именованными каналами, – то есть средствами межпроцессорного взаимодействия. Ведь система, в которой не существует никаких механизмов обмена данными между процессами, – никому не нужна. А если UNIX поддерживает механизмы межпроцессорного взаимодействия, не приводит ли это к нарушению политики безопасности?

Успех UNIX в частности объяснялся наличием удобного и простого средства межпроцессорного взаимодействия – конвейера (позаимствованного из операционной системы DTSS - Dartmouth time-sharing System), подробно описанного в главе «Устройство конвейера и перенаправление ввода-вывода». Но таким способом могли общаться между собой лишь родственные процессы, и это сильно ограничивало возможные области применения (впрочем, существовали и так называемые, именованные каналы, доступные всем остальным процессам).

В UNIX System V появился пакет IPC (interposes communication), значительно расширяющий возможности межпроцессорного взаимодействия. Поддерживались: механизм передачи сообщений, разделяемая память и семафоры, необходимые для синхронизации процессоров. Все трое могли взаимодействовать с любыми, не обязательно родственными процессами, поэтому остро стал вопрос обеспечения безопасности.

Каждый совместно используемый объект (например, регион памяти) связан со структурой данных, описывающей права доступа и перечисляющей пользовательские и групповые коды идентификации. Права доступа в чем-то сходны с атрибутами файлов, – можно выборочно разрешать запись, чтение, назначаемые как отдельным пользователям, так и целым группам. При условии отсутствия ошибок реализации такая система выглядит внутренне не противоречивой и как будто бы надежа.

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

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

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

Взять, к примеру, процесс отладки [114] (debug) приложений. Наличие такого механизма многократно облегчает поиск ошибок в программе, но вместе с тем позволяет изучать и контролировать ее работу. Поэтому, необходимо должным образом позаботиться о безопасности, включив в код ядра множество проверок. Существующая в UNIX схема отладки достаточно защищена, но крайне неудобна для разработчиков, поэтому не так редко приходится слышать о преднамеренной модификации ядра и переписывании системной функции ptrace, заведующей отладкой.

Традиционно в UNIX отлаживать процесс можно только с его собственного согласия. Для этого он должен вызвать функцию ptrace, разрешая ядру трассировку. Но на самом деле это ограничение эфемерно – системный вызов exec в UNIX не создает новый процесс (как это происходит, например, в Windows), а замешает текущий. Последовательные вызовы ptrace и exec позволили бы получить доступ к адресному пространству любой задачи и произвольным образом вмешиваться в ее работу, если бы не дополнительные проверки…

В UNIX вообще запрещено отлаживать setuid-программы (бедные, бедные разработчики!), иначе было бы возможно запустить, скажем, ту же программу login и, нейтрализовав защитный механизм, войти в систему с привилегиями root. Но, ведь любой процесс может исполняться не только в режиме пользователя, но и ядра! Возможность же отладки ядра позволила бы с легкостью проникнуть в систему, поэтому оказалась «заботливо» блокирована создателями UNIX. Словом, разработчики ради достижения безопасности пошли вразрез с интересами программистов!

Точно так невозможно отлаживать уже запущенные процессы. Это вызывает большое недовольство разработчиков, вынужденных удалять процесс и перезапускать его вновь (в Windows, кстати, с этим справляется на раз).

Итак, ядро перед отладкой должно позаботиться о следующих проверках: подтвердить у отладчика наличие потомка с указанным идентификатором (pid), затем убедиться находится ли отлаживаемый процесс в состоянии трассировки, не является ли эта задача stupid-программой – и только после этого приступить к отладке.

Возникает вопрос, – что такое идентификатор процесса, где он хранится и можно его подделать? В начале этой главы уже отмечалось, – состояние процесса сохраняется в его контексте, расположенном в доступном для процесса адресном пространстве и посему не защищенным от модификации. Поэтому, критические к изменению атрибуты (например, привилегии) должны быть вынесены за пределы досягаемости процесса. В UNIX для этой цели используется ядро, в котором содержится структура, именуемая таблицей процессов. Каждая запись ассоциирована с одним процессом и среди прочей информации содержит «магическое» число, называемое идентификатором процесса. Магическое – потому что интерпретировать его не может никто, кроме ядра. Идентификатор в зависимости от реализации может представлять собой индекс записи или одно из ее полей – прикладные приложения не имеют об этом никакого представления. Все что они могут – запомнить возращенное функцией fork значение и передавать его остальным системным функциям в качестве аргумента, которое ядро интерпретирует самостоятельно.

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

Точно так, процесс можно отлаживать и без его согласия – достаточно вспомнить о срыве стека. Это позволит от имени процесса выполнить ptrace, и… правда, если ошибки программы приводят к возможности срыва стека и выполнению любого кода, вряд ли это приложение кому-нибудь взбредет в голову отлаживать.

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

"Мусульмане и христиане хоронят своих мертвых в земле в гробах, чтобы их защитить. Это плохо, это просто глупость, потому что, если мы не можем защитить жизнь, так как же мы сможем защитить смерть? Мы не можем защитить ничего, ничего нельзя защитить.

Жизнь уязвима, а вы пытаетесь сделать неуязвимой даже смерть. Хотите сохранить, спасти."

Чжуан Цзы

Windows NT

Ø В этой главе:

Ø История возникновения и эволюции Windows

Ø Атака на Windows NT

Ø Атаки на Windows 95 (Windows 98)

Дата добавления: 2015-11-14