Классификация пбб по источнику появления.

 

Как следует из определения ПББ, источником ее появления является ошибка или недоработка в системе безопасности. Исследованию ошибок, тем или иным образом связанных с безопасностью, всегда уделялось много внимания. В качестве примера можно привести работы [2,3,4,11,12,13,16,17]. Исследования [1,2,4] показывают, что подобные ошибки носят неслучайный характер. Классификация ПББ по источнику появления, приведенная в работе [1] показана в таблице 3.1.

 

Под источником появления (эквивалентный перевод емкого английского термина genesis), в[1] понимается основа существования ПББ, т.е. либо характеристики ВС, которые обуславливают ее существование, либо принцип функционирования средств, использующих ПББ для осуществления атаки. С точки зрения авторов данный подход можно подвергнуть серьезной критике, т. к. он порождает некоторое противоречие между заявленным принципом классификации и полученными результатами. Действительно, (см. таблицу 3.1) классификация преднамеренных ПББ фактически представляет собой таксономию РПС по принципам функционирования, а непреднамеренных — классификацию ошибок, возникающих в ходе программной реализации системы, и являющихся основой существования ПББ. Для решения практических задач наибольший интерес представляет таксономия ПББ по причинам возникновения, поэтому авторы провели собственное исследование данной проблемы результаты которого будут представлены далее.

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

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

Хотя определенные злоумышленные, преднамеренные ошибки могут рассматриваться как случайные, трудно представить, скажем, случайно возникшую "троянскую" программу. В спорных случаях при классификации ошибок по их происхождению в работе [1] рекомендуется обратиться к другим классификационным признакам, например, к этапу внесения ошибки. Как правило, случайные ошибки вносятся в систему при разработке требований к безопасности и спецификаций системы защиты (откуда они автоматически попадут в средства, их реализующие), а также в процессе сопровождения системы (обновления версии, поставки новых утилит и т.п.). Напротив, преднамеренные ошибки внедряются в систему именно на этапе ее применения (если, конечно, среди разработчиков системы не было лица, заинтересованного в ее компрометации).

Преднамеренные и злоумышленные ошибки являются достаточно трудно обнаруживаемыми потому, что они специально скрыты, замаскированы именно с целью не быть обнаруженными. Эти являются самыми опасными: специально внесенные 'ошибки с деструктивными функциями могут серьезно нарушить функционирование системы; случайные ошибки, безобидные сами по себе, также могут быть использованы для этих же целей специально написанными программами.

	Кол-во примеров	Индексы в приложении 1
Ошибки в системах защиты, служащие источником появления ПББ.	преднамеренные	С наличием деструктивных функций	РПС	Несамовоспроизводящиеся РПС (троянские кони)		PC1, PC3, I8
Самовоспроизводящиеся РПС (вирусы)		U1, PC2, PC4, MA1, MA2, CA1, AT1
Черные ходы, люки, скрытые возможности проникновения в систему.		U1, U10
Без деструктивных функций (пассивные)	Скрытые каналы утечки информации	С использованием памяти		DT1
С использованием времени		I9, D2
другие		I7, B1, U3, U6, U10
Непреднамеренные (случайные)	Ошибки контроля допустимых значений параметров		I4, I5, MT1, MU2, MU4, MU8, U7, U11, U12, U13
Ошибки определения областей (доменов)		I3, I6, MT2, MT3, MU3, UN1, D1
Ошибки последовательности действий и использования нескольких имен для одного объекта (в т.ч. TOCTTOU)		I1, I2
Ошибки идентификации/аутентификации		MU1, U2, U4, U5, U14
Ошибки проверки границ объектов		MT4,MU5, MU6, U9
Другие ошибки в логике функционирования		MU7, MU9, U8, IN1

Таблица 3.1. Таксономия ПББ по источнику появления.

 

Преднамеренное внедрение ПББ с наличием деструктивных функций.

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

"Логические бомбы" и "часовые мины" — это РПС, которые не выполняют никаких функций до наступления определенного события в системе, после чего "срабатывают", что, как правило, заключается в серьезных нарушениях работы системы, уничтожении информации и других деструктивных действиях. Особенностью проявления данного вида преднамеренно внедренного кода является отсутствие маскировки выполнения деструктивных функций. Последствия "срабатывания" чаще всего носят катастрофический характер и могут привести к полному уничтожению системы и/или данных. С учетом сказанного в первой главе, РПС являются одним из самых опасных и самым разрушительным видом ПББ.

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

 

Преднамеренно внедренные ПББ без деструктивных функций.

 

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

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

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

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

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

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

 

Непреднамеренные (неумышленные) ошибки и ПББ.

 

Непреднамеренные ПББ могут возникнуть в системе изза наличия ошибок на этапе разработки требований к безопасности, при разработке спецификаций и на этапе их реализации, т.е. в процессе написания программ. Ошибки такого типа были подробно исследованы и классифицированы в работах [2,4]. Хотя большинство из них обнаруживается и устраняется во время тестирования, ряд ошибок может остаться незамеченным и вызвать определенные проблемы на этапе эксплуатации системы. Наиболее трудно выявляются такие ошибки в сложных системах, состоящих из многочисленных компонент, разработанных при участии большого коллектива специалистов. Одна из неотъемлемых проблем таких систем — невозможность исчерпывающего описания их спецификаций, то есть невозможность адекватного документирования. Недостатки проектной документации в процессе сопровождения и эксплуатации приводят к тому, что при попытке устранения одних ошибок в нее вносятся другие. И хотя наличие неумышленных ошибок не приводит к немедленному их использованию и нарушению безопасности системы, это является лишь вопросом времени.

Неумышленные ПББ могут быть классифицированы в соответствии со следующими группами ошибок, предопределяющих их существование:

1. Ошибки контроля допустимых значений параметров.

2. Ошибки определения областей (доменов).

3. Ошибки последовательности действий и использования нескольких имен для одного объекта.

4. Ошибки идентификации/аутентификации.

5. Ошибки проверки границ объектов.

6. Ошибки в логике функционирования.

 

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

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

Наличие ошибок последовательности действий предопределяется асинхронным функционированием компонент системы, которое может быть использовано для нарушения безопасности. Выявить такие ошибки в системе достаточно трудно. Их суть заключается в том, что в силу невозможности представления каждой из функций системы единственной атомарной операцией, многие из функций выполняются как некоторая асинхронная последовательность действий (операций), возможно осуществляемых несколькими компонентами системы. Например, одной из операций может быть проверка идентификатора процесса, а второй — установка для него соответствующих полномочий, или, проверка допустимости параметра, а затем — его использование. Асинхронность может быть использована злоумышленником для обмана механизмов контроля путем подмены параметра на другой, запрещенный, после проверки его допустимости, но перед использованием. Данная ошибка носит название TOCTTOU[16](time-of-check to time-of-use) — возможность подмены параметра между моментом проверки и моментом использования (смотри 11 в Приложении 1).

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

Ошибки проверки границ объектов и связанные с ними каналы утечки обычно возникают из-за игнорирования проверок того, что определенный объект пересек границы области памяти, отведенной для его хранения (контроль длины строки, размера массива, размера и положения файла и т.д.). Самый известный пример — программа Finger в ОС Unix (смотри пример U12 в Приложении 1).

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

 

3.3.2. Классификация ПББ по этапам внедрения.

 

В отличие от исследования вопроса о том, каким образом в защищенных системах возникают ПББ, анализу этапа появления ошибок уделяется недостаточное внимание. Результаты исследования данного вопроса подробно изложены в нескольких работах, наибольший интерес из которых представляет [2], в которой проблема выявления этапа внедрения ошибок рассматривается по отношению к жизненному циклу программного обеспечения.

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

На самом верхнем уровне представления жизненного цикла систем можно выделить три фазы:

— фазы разработки, которая охватывает весь период создания исходной рабочей версии системы;

— фазы сопровождения, в ходе которой происходит модификация, совершенствование, развитие системы и появление ее очередных версий;

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

			Количество примеров	Индексы в приложении 1
Этап внедрения ошибки и возникновения ПББ	На стадии разработки	Ошибки в требованиях и спецификациях		I1, I2, I3, I4, I5, I6
Ошибки в исходных текстах программ		MT1, MT4, MU1, MU2, MU5, MU7, MU8, DT1, U2, U3, U4
Ошибки в исполняемом коде		U1
В ходе сопровождения		D1, MU3, MU9
В ходе эксплуатации		I8, PC1, PC2, PC3, PC4, MA1, MA2, CA1, AT1

Таблица 3.2. таксономия ПББ по этапу возникновения.

 

Возникновение ПББ в процессе разработки системы.

 

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

 

Составление требований и спецификаций.

 

Требования к программному обеспечению описывают что должна делать каждая из программ в составе системы Спецификации же определяют то, каким образом эти действия должны выполняться. Требования и спецификации взаимосвязаны настолько тесно, что относить обусловленные ими ПББ к разным категориям представляется нецелесообразным.

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

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

 

Создание исходных текстов программ.

 

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

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

Преднамеренные ошибки могут быть внесены в система по целому ряду причин. Программист может внедрить в систему код, не предусмотренный ее спецификациями, но нужный ему для отладки и тестирования разрабатываемой программы. Однако, если по завершению разработки этот код не будет удален из программы, он превратится в реальный канал утечки информации и может быть использован злоумышленником. Самый известный пример такого рода—программа Sendmail, позволившая широко распространиться сетевому вирусу Морриса (смотри пример U10 в Приложении 1).

 

Генерация исполняемого кода.

Исполняемый код генерируется компиляторами из исходных текстов программ и представляет собой инструкции, предназначенные для выполнения процессором. Поскольку компиляторы предназначены только для формального преобразования исходных текстов в исполняемый код, они автоматически переносят ошибки из первых во второй. Однако если ошибки содержатся в самом компиляторе, они могут использоваться злоумышленниками для получения в компилируемых программах нужных им фрагментов кода (смотри пример U1 в приложении 1).

Возникновение ПББ в процессе сопровождения и развития системы.

 

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

 

Возникновение ПББ в процессе функционирования системы.

 

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

Хорошо известные случаи вирусных атак являются наиболее ярким обоснованием необходимости постоянного контроля и анализа состояния системы и исполняемых файлов[18] Основной задачей такого анализа в процессе функционирования системы является выявление несанкционированной модификации каких-либо фрагментов исполняемого кода. Очевидно, что целью РПС является не просто модификация кода, а нарушение функционирования системы и возможно доступ к конфиденциальным данным, перехват паролей, создание скрытых каналов утечки информации и т.д.

 

3.3.3. классификация ПББ по размещению в системе.

 

ПББ можно классифицировать по их размещению в ВС, в зависимости от того, в каких компонентах системы они находятся. Большинство ошибок, приводящих к возникновению ПББ и нарушению требований защиты, присутствует в программном обеспечении; в тоже время они встречаются и в аппаратуре. Хотя в данной работе основное внимание уделено исследованию таксономии ПББ в программном обеспечении вообще и в операционных системах в частности, программы, которые их содержат, в своем функционировании всецело зависят от аппаратной платформы. Этот факт, а также то, что ПББ может использовать ошибки аппаратуры, определяет необходимость внесения в разрабатываемую классификацию соответственно категорий "ошибки в программном обеспечении" и "ошибки аппаратных платформ" — смотри Таблицу 3.3.

			Кол-во примеров	Индексы в приложении 1
Размещение в ВС	Программное обеспечение	Операционные системы	Инициализация ОС (загрузка)		U5, U13, PC2, PC4, MA1, MA2, AT1, CA1
Управление выделением памяти		MT3, MU5
Управление процессами		I6, I9, MT1, MT2, MU2, MU3, MU4, MU6, U7, UN1
Управление устройствами		I2, I3, I4
Управление файловой системой		I1, I5, MU8, U2, U3, U9
Средства идентификации и аутентификации		MU1, DT1, U6, U11, D1
Другие (неизвестные)		MT4
Сервисные программы и утилиты	Привилегированные утилиты		I7, B1, U4, U7, U8, U10, U12, U14, PC1, PC3
Непривилегированные утилиты		U1
Прикладные программы		I8
Аппаратное обеспечение		MU9, D2, IN1

Таблица 3.3. Таксономия ПББ по размещению в вычислительной системе.

 

Ошибки и каналы утечки в программном обеспечении.

 

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

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

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

 

Системное программное обеспечение.

 

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

Таким образом, ПББ в операционной системе могут быть разделены по следующим категориям:

- инициализация (загрузка) системы;

- управление распределением памяти;

- управление устройствами;

- управление процессами;

- управление файловой системой;

- идентификация и аутентификация.

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

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

Управление процессами и управление распределением памяти — основные задачи операционной системы, и ошибки в данных механизмах приводят к получению злоумышленником контроля над всей системой и свободному доступу к любой информации.

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

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

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

 

Сервисное программное обеспечение.

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

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

Наличие ошибок в реализации систем защиты привилегированных утилит или каналов утечки информации в них

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

 

Прикладное программное обеспечение.

 

Нарушения в функционировании вычислительных систем, вызванные неумышленными ошибками в прикладном программном обеспечении, обычно ограничиваются только содержащим эту ошибку процессом, который некорректно функционирует либо саморазрушается. Однако это не означает, что все ошибки в прикладном программном обеспечении столь же безобидны. Преднамеренно внесенные программные закладки, вирусы, троянские кони и логические бомбы находятся именно на уровне прикладного программного обеспечения. Объектами их атак потенциально могут стать любые компоненты вычислительной системы, и в результате такого воздействия могут стать очень серьезными — вплоть до выведения операционной системы из строя. В этом случае успех атаки зависит от того, насколько защищена конкретная ОС от разрушительных действий прикладных программ. Многопользовательские многозадачные ОС (такие как Unix) сравнительно легко справляются с подобной проблемой, а широко распространенные DOS и Windows в этой ситуации оказываются практически бессильными.