26147-1 (607725), страница 2

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

Текст из файла (страница 2)

Превышение максимально возможного размера IP-пакета, или Ping Death

В максимальный размер IP-пакета (65 535 байт) включаются длина IP-заголовка и длина ноля данных в IP-пакете. Так как минимальный раз­мер IP-заголовка - 20 байт (максимальный - 60), то соответственно раз­мер данных, передаваемых в одном IP-пакете, не может превышать 65 535- 20 = 65 515 байт. А что будет, если превысить это число? Тестировать свои программы на предельных критических значениях -стандартный для любого программиста ход. Подобные тесты позволяют выявить такие неприятные ошибки, как всевозможные переполнения (бу­фера, стека, переменной и т. д.). Но вернемся к IP. В принципе ничто не мешает атакующему сформиро­вать набор фрагментов, которые после сборки превысят максимально воз­можный размер IP-пакета. Собственно в этой фразе и сформулирована основная идея данной атаки.

Итак, 18 декабря 2000 года на информационном сервере СЕКТ появи­лись сообщения о том, что большинство сетевых операционных систем, поддерживающих протоколы TCP/IP, обладают следующей уязвимостью: при передаче на них IP-пакета длиной, превышающей максимально допу­стимое значение, в этих ОС переполняется буфер или переменная, в ре­зультате система «зависает» или перезагружается, то есть налицо отказ в обслуживании. Был приведен и список потенциально опасных платформ:

• Berkeley Software Design, Inc. (BSD);

• Computer Associates, Intl. (products for NCR);

• Cray Research;

• Digital Equipment Corporation;

• FreeBSD, Inc.; ' Hewlett-Packard Company;

• IBM Corporation;

• Linux Systems;

• NEC Corporation;

• Open Software Foundation (OSF);

• The Santa Cruz Operation, Inc. (SCO);

• Sun Microsystems, Inc.

Мы с удивлением прочитали этот перечень операционных систем на различных платформах, а потом принялись за эксперименты. Наше глу­бочайшее изумление вызвал тот факт, что элементарную ошибку пере­полнения буфера в модуле IP ядра ОС за почти 20 лет активного функ­ционирования протокола IP разработчики сегодняшних систем до сих пор не замечали. Поэтому мы позволили себе не поверить столь уважае­мой организации, как CERT. Но прежде чем начать эксперименты, было решено посмотреть по указанной в CERT ссылке (http://www.sophist.demon.co.uk/ping) на WWW-сервер, где экспертами прово­дились подобные исследования на различных ОС. На WWW-сервере предлагалось реализовать такое воздействие следующим образом: необ­ходимо выполнить на рабочей станции с ОС Windows 95 или Windows NT следующую команду: ping -l 65527 victim.destination.IP.address (по этой команде атака и получила свое название - Ping Death).

Так как обычный размер IP-заголовка составляет 20 байт, а размер 1СМР-заголовка - 8 байт, то подобный ICMP-пакет будет превышать максималь­но возможный размер IP-пакета на 20 байт: 65 527 +20+8-65 535 = 20.

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

Операционная система	Версия ПО	Симптомы
Solaris (x86)	2.4, 2.5, 2.5.1	Перезагрузка
Minix	1.7.4, v2.0 и другие	Сбой
HP3000 MPE/iX	4.0, 5.0, 5.5	Сброс системы
Convex SPP-UX	Все версии	Сбой
Apple Mac	MacOs 7.x.x	Сбой
Windows 3.11 with Trumpet winsock	?	Смешанные отчеты
Novell Netware	3.x	Смешанные отчеты
Windows 95	Все версии	Сбой
AIX	3 и 4	Сброс системы
Linux	2.0.23	Спонтанная перезагрузка или зависание (kernel panic)
DEC UNIX / OSF1	2.0 и выше	зависание (kernel panic)
Open VMS for AXP	Различные	Смешанные отчеты
HP-UX	9.0 по 10.20	Сбой, перезагрузка, зависание.
Windows NT	3.5.1	Смешанные результаты
Irix	5.3	зависание (kernel panic)
Windows NT	4	Сбой
SCO Openserver	4.2, 5.0.x	Уязвима
DEC TOPS-20, TOPS-10	Все	Ошибки
Digital Firewall	?	Уязвима
AltaVista Firewall for UNIX	?	Уязвима

(здесь она приводит­ся в сокращении), на которые данная удаленная атака якобы произвела необходимый эффект. Итак, мы начали тестирование и, честно говоря, абсолютно не удивились, когда исследуемые ОС - IRIX, AIX, VMS, SunOs, FreeBSD, Linux, Windows NT 4.0, даже Windows 95 и Windows for WorkGroups 3.11- абсолютно не реагировали на подобный некоррект­ный запрос, продолжая нормально функционировать. Тогда были пред­приняты специальные поиски операционной системы, которую бы дей­ствительно вывела из строя данная атака. Ей оказалась Windows 3.11 с WinQVT - эта ОС действительно «зависла».

Этим «экспертам», которым столь доверяют CERT и С1АС, мы послали запрос, где попросили прояснить возникшую ситуацию, а также уточнить сведения из вышеприведенной таблицы. В полученном нами ответе гово­рилось, что успех данной атаки зависит от многих факторов, а именно: программного и аппаратного обеспечения, установленного на компьюте­ре, и, самое главное, от фазы Луны. Как говорится, без комментариев. Для полноты картины мы хотели бы привести описание exploit, созданного для Windows NT 4.0, задача которого, используя ping, «завесить» собственный компьютер (!). Сначала предлагалось запустить Web Browser, затем-taskmgr (Task Manager): так Ping Death якобы лучше работает (еще не хва­тает шаманского бубна!). И наконец, требовалось запустить 18 ping-про­цессов (почему не 100?). Если вы думаете, что после всего этого ваша ОС немедленно «повиснет», то ошибаетесь! В комментариях к exploit до по­лучения эффекта предлагалось ждать примерно 10 минут, а может быть, несколько больше или несколько меньше.

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

причины усПЕХА УДАЛЕННЫХ АТАК

«То, что изобретено одним человеком,

может быть понято другим», - сказал Холме.

А. Конан Доил. Пляшущие человечки

Использование нестойких алгоритмов идентификации

К сожалению, взаимодействие объектов по виртуальному каналу в распре­деленной ВС не является панацеей от всех проблем, связанных с иденти­фикацией объектов РВС. ВК - необходимое, но не достаточное условие безопасного взаимодействия. Чрезвычайно важным в данном случае стано­вится выбор алгоритма идентификации при создании виртуального кана­ла. Основное требование, предъявляемое к этим алгоритмам, состоит в сле­дующем: перехват ключевой информации, которой обмениваются объекты РВС при создании ВК, не должен позволить атакующему получить итого­вые идентификаторы канала и объектов. Однако в базовых алгоритмах идентифика­ции, используемых при создании ВК в большинстве существующих сетевых ОС, это требование практически не учитывается.

Отсутствие контроля за виртуальными каналами связи

Объекты распределенной ВС, взаимодействующие по виртуальным кана­лам, могут подвергаться типовой атаке «отказ в обслуживании». Особен­ность этого воздействия состоит в том, что, действуя абсолютно легальны­ми средствами системы, можно удаленно добиться нарушения ее работоспособности. В чем причина успеха данной атаки? В отсутствии необхо­димого контроля над соединением. При этом задача контроля распадается на две подзадачи:

• контроль за созданием соединения;

• контроль за использованием соединения.

Если пути решения второй задачи понятны - обычно соединение раз­рывается по тайм-ауту, определенному системой, - так сделано во всех из­вестных сетевых ОС (однако тут возникает серьезная проблема выбора конкретного значения тайм-аута), то контроль за созданием ВК достаточ­но сложен: в системе, где отсутствует статическая ключевая информация обо всех ее объектах, невозможно отделить ложные запросы на создание соединения от настоящих. Очевидно также, что если один субъект сетево­го взаимодействия будет иметь возможность анонимно занимать неогра­ниченное число каналов связи с удаленным объектом, то подобная систе­ма может быть полностью парализована данным субъектом. Таким образом, если лю­бой объект в распределенной системе способен анонимно послать сооб­щение от имени другого объекта (например, в Internet маршрутизаторы не проверяют IP-адрес отправителя), то в подобной распределенной ВС практически невозможен контроль за созданием виртуальных соедине­ний. Поэтому основная причина типовой угрозы «отказ в обслужива­нии» - это отсутствие приемлемого решения задачи контроля за маршру­том сообщений.

Отсутствие возможности контролировать маршрут сообщений

Если в РВС не предусмотреть контроля за маршрутом сооб­щения, то адрес отправителя сообщения оказывается ничем не подтверж­денным. Таким образом, в системе будет существовать возможность ра­боты от имени любого объекта путем указания в заголовке сообщения чужого адреса отправителя (IP Spoofing). В подобной РВС затруднитель­но определить, откуда на самом деле пришло сообщение, а следовательно - вычислить координаты атакующего (в Internet невозможно найти ини­циатора однонаправленной удаленной атаки).

Отсутствие полной информации об объектах РВС

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

Отсутствие криптозащиты сообщений

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

Отсутствие выделенного канала связи между объектами сети Internet

Глобальная сеть не может быть построена по принципу прямой связи между объектами, поскольку для каждого объекта невозможно обеспечить вы деленный канал связи с любым другим объектом. Поэтому в Internet связь осуществляется через цепочку маршрутизаторов, а следовательно, сообщение, проходя через большое количество промежуточных подсетей, может быть перехвачено. Также к Internet подключено большое число локальных Ethernet-сетей, использующих топологию «общая шина»; в сетях с такой

топологией несложно программно осуществлять перехват сообщений.

Недостаточные идентификация и аутентификация

В базовых протоколах обмена идентификация и аутентификация объек­тов практически отсутствуют. Так, например, в прикладных протоколах . FTP, TELNET, РОРЗ имена и пароли пользователей передаются по сети в виде открытых незашифрованных сообщений.

Использование нестойких алгоритмов идентификации объектов при создании виртуального TCP-соединения

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

Характеристики

Список файлов курсовой работы