Операционная система Burroughs 6700

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

Индекс: В1. Система: Burroughs 6700

Источник информации: A.L. Wilkinson et al. «A pene­tration analysis of a Burroughs large system», ACM SIGOPS Operating Systems Review 15, Jan. 1981, pp. 14—25.

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

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

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

Система Univac 1108

Компьютеры Univac 1108, предоставлявшие собой вы­сокопроизводительные мейнфреймы, в 70-х годах обеспе­чивали вычислительными ресурсами исследовательские лаборатории и университеты. Их основная память была поделена на два банка, каждый из которых состоял из со­вокупности 512-байтных элементов. Адресное простран­ство программ также состояло из двух банков: банк I (банк инструкций) содержал код программы, банк D (банк данных) — данные. Аппаратные средства защиты были организованы таким образом, что программы мог­ли либо использовать оба банка как для чтения, так и для записи, либо установить запрет на запись в оба банка.

Индекс: UN1. Система: Univac 1108/Exec 8

Источник информации: D. Stryker. «Subversion os a «Secure» Operating System», NRL Memorandum Report 2821. June 1974.

Операционная система мейнфреймов Univac —Exec 8 поддерживала одновременное использование несколькими пользователями ряда системных утилит (редакторы. компиляторы и СУБД) с помощью их реализации в виде процессов с повторным вхождением (re-entrant process, или REPs). Эти процессы хранили данные пользователей в принадлежащих им D-банках и совместно использовали одну копию исполняемого кода, находящуюся в общем 1-банке, который был защищен от записи.

Кроме того, Exec 8 содержала схему обработки ошибок, которая позволяла любой программе перехватывать прерывание, генерируемое при возникновении ошибки (например, при делении на ноль или выходе за границы памяти). Когда установленная пользователем процедура обработки ошибок получала управление, она получала доступ к контексту возникновения ошиб­ки. Системные процессы должны были устанавливать свои собственные процедуры обработки ошибок, однако многие процессы типа REP этого не делали. Это позволяло злоумышленнику установить собственную про­грамму обработки ошибок, создать ошибочную ситуа­цию в REP-процессе (например, организовав для него D-банк слишком маленького размера) и перехватить прерывание. Получившая управление пользовательская программа обработки ошибок получала возможность доступа как по чтению, так и по записи к банкам I и D процесса типа REP. Это означало, что она могла моди­фицировать его код, который имел доступ к D-банкам многих пользователей, — например, внедрить «троян­ского коня», копирующего чужие данные. Несмотря на то что подобная «троянская» программа будет рабо­тать только до тех пор, пока существует соответствую­щий процесс, возможность даже временного получения злоумышленником информации от процесса типа REP является чрезвычайно опасной, так как дает ему неог­раниченный доступ к данным всех остальных пользова­телей этого процесса.

Системы DEC PDP-10 и VAX

Системы DEC PDP-10 были компьютерами средней производительности, ставшими стандартным средством поддержки распределенной интерактивной обработки данных в 70-х годах. Эти системы функционировали под управлением ОС TENEX, разработанной фирмой BBN. Компьютеры DEC VAX могли функционировать под управлением операционной системы VMS, Unix-подоб­ной системы Ultrix и под управлением операционных систем, разработанных самой DEC. В системе VMS имелся т. н. файл авторизации, в котором находились записи о правах и привилегиях пользователей. Пользо­ватель, который получил доступ к этому файлу, получал неограниченные возможности управления системой.

Индекс: DT1. Система: TENEX

Источники информации: A. S. Tanenabum. «Opera­ting System Design and Implementation». Prentice-Hall, Englewood Cliffs, NJ, 1987., и R. P. Abbott et al, «Security Analysis and Enhancements of Computer Operating Systems, Final Report of RISOS Project». National Bureau of Standards NBSIR-76-1041, Apr. 1976, pp. 49—50.

Как и многие другиеОС, TENEX использовала сис­тему паролей для контроля доступа к файловой системе. Процедура проверки правильности пароля была реали­зована таким образом, что позволяла злоумышленнику подобрать пароль за небольшое количество попыток. Проверка пароля осуществлялась символ за символом, причем выборка символов осуществлялась из области памяти пользовательского процесса, а как только обнаруживался неверный символ — проверка прекращалась. Так как пользователь контролировал область памяти, откуда считывались символы пароля, он мог использовать для радикального ускорения процесса перебора механизм подкачки виртуальных страниц памяти. Для этого вариант пароля помещался на границу виртуальной страницы таким образом, что подбираемый символ размещался в ее последнем байте, а следующая страница от­сутствовала в физической оперативной памяти. После этого, если при проверке пароля возникала ситуации полгрузки страницы, это означало, что символ подобран верно (процедура проверки обращалась к следующему символу только в том случае, если текущий был верен), и противном случае процесс подбора этого символа продолжался. После подбора первого символа можно было перейти к подбору второго и т. д. Таким образом, вместе того чтобы проверять для подбора пароля, состоящего из N символов алфавита мощностью М, MN комбинаций, злоумышленник мог проверить всего M*N комбинаций. Это полностью дискредитировало всю парольную систему защиты данной ОС.