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

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

        1. IP-фрагментация как способ проникновения через Firewall

  Как известно из описания протокола IP (RFC 791),максимальный размер IP-пакета может достигать 216-1 байт. Однако размер пакета (дейтаграм-мы), передаваемого непосредственно по каналу передачи, зависит от типа среды передачи. Например, в среде Ethernet максимальный размер дейтаграммы 1500 байт, в среде ATM - 56 байт. Поэтому для того, чтобы IP-пакеты могли передаваться по сетям любых типов, в протоколе IP предусмотрена фрагментация пакетов.

  То есть для передачи одного большого пакета он разбивается на соответствующее количество пакетов меньших размеров (их размер обуславливается максимальным размером пакета в соответствующей среде передачи). Этот процесс разбиения IP-пакета на части называется IP-фрагментацией. Применение в сети Internet фрагментации пакетов делает ее более гибкой и инвариантной по отношению к разнообразным физическим средам передачи. На рисунке 4.12 приведен формат IP-пакета версии IPv4.

  Не будем вдаваться в подробности, что означает каждое поле в IP-заголовке (RFC 791), так как в данном случае нас будут интересовать только поля Fragment Offset и Flags. В поле Fragment Offset содержится значение, измеряемое восьмерками байт, обозначающее смещение фрагмента относительно начала дейтаграммы (именно на то, что оно измеряется в восьмерках байт, и не обратил внимание д-р F. B. Cohen в его статье Packet Fragmentation Attacks).

  Таким образом, единица в этом поле означает смещение на 8 байт от начала дейтаграммы. Поле Flags показывает фрагментирован ли пакет или нет.

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

  В случае соответствия правилам пакет пропускается дальше, в противном случае - отфильтровывается.

   Формат IP-пакета версии IPv4.

    4-bit Version 4-bit Header Length 8-bit Type of Service 16-bit Total
  Length
  16-bit Identification 3-bit Flags 13-bit Fragment Offset
  8-bit Time to Live 8-bit Protocol 16-bit Header Checksum
  32-bit Source Address
  32-bit Destination Address
  Options Padding
  Data

  Формат TCP-пакета.

     16-bit Source Port Number 16-bit Destination Port Number
  32-bit Sequence Number
  32-bit Acknowledgement Number
  4-bit Header Length 6-bit Reserved 6-bit Flags 16-bit Window Size
  16-bit TCP Checksum 16-bit Urgent Pointer
  Options Padding
  Data

 Формат UDP-пакета.

   16-bit Source Port Number 16-bit Destination Port Number
  16-bit Length 16-bit Checksum
  Data

   В своей статье Packet Fragmentation Attacks (опубликована в All.net) доктор F. B. Cohen предложил следующий сценарий предполагаемой атаки, заключающейся в прохождении фрагментированного пакета через файрвол, минуя правила фильтрации.

  Атакующий разбивает пакет на два фрагмента, первый из которых содержит фиктивный TCP- или UDP-заголовок с номером порта назначения, который не фильтруется правилами на файрволе (например, 25 порт - почтовый SMTP-сервер), а второй имеет такое смещение (равное 1) в поле Fragment Offset, что перекрывает первый пакет и записывает в поле "порт назначения" истинное значение порта той службы, к которой доступ через файрвол запрещен. В этом случае правила фильтрации на файрволе пропустят этот IP-пакет, так файрвол не занимается сборкой фрагментированных IP-пакетов.

  С этой статьей д-р Cohen'a происходили с течением времени довольно любопытные изменения. В статье, которую авторы нашли на WWW-сервере all.net в мае 1996 года, для осуществления атаки предлагалось занести в поле Fragment Offset значение

  Действительно, сборкой фрагментированных IP-па-кетов занимается операционная система конечного получателя пакета, и при сборке, как правило, не  проверяется, не накладываются ли фрагменты пакета друг на друга. Сетевая ОС собирает фрагментированный пакет и передает его соответствующей службе, основываясь на значении в поле порт назначения . На первый взгляд атака состоялась: фрагментированный пакет, направленный одной службе, прошел через файрвол и при сборке фрагментов передался другой службе, доступ на которую был запрещен правилами фильтрации файрвола. Однако, д-р F. B. Cohen не учел того важного факта, что значение в поле смещения согласно спецификации указывается в восьмерках байт, и даже если установить это значение в единицу и предположить, что сетевая ОС не проверяет наложение фрагментов, то после сборки фрагментов наложение произойдет только после первых восьми байт TCP- или UDP-заголовка, в которых, как видно из рис. 4.12, и содержатся поля портов назначения.

  Через некоторое время после опубликования статьи д-р Cohen, видимо, обнаружил описанную выше ошибку и внес в сценарий атаки одно изменение:
единица в поле Fragment Offset теперь была им заменена на 0!

  Проанализируем, насколько это изменение сделает возможным осуществление данной атаки.

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

   Однако, анализ исходных текстов ядра операционных систем Linux и FreeBSD показал, что IP-пакет будет воспринят этими ОС как фрагмент только в том случае, если значение в поле Fragment Offset не равно 0! Тем не менее, так как в алгоритме сборки фрагментов, описанном в RFC 791, не требуется обязательная проверка значения этого поля, то возможно, что некоторые сетевые ОС ее не производят (что маловероятно!) и, следовательно, атака может иметь успех.

  Как нам кажется, сама идея наложения фрагментов является достаточно любопытна. Другое дело, что применение ее для проникновения пакетов атакующего через Firewall в существующем стандарте IPv4 представляется маловероятным.

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

   В максимальный размер IP-пакета (65535 байт) включается длина IP-заголовка и длина поля данных в IP-пакете.

  Так как IP-заголовок имеет минимальный размер в 20 байт (максимальный в 60), то, соответственно, размер передаваемых в одном IP-пакете данных не может превышать 65535- 20 = 65515 байт. А что будет, если превысить этот максимальный размер IP-пакета?

   Тестировать свои программы на минимальных и, самое главное, на максимальных значениях, то есть на предельных критических значениях - стандартный для любого программиста ход.

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

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

  Итак, 18 декабря 1996 года на информационном сервере CERT появились сообщения о том, что большинство сетевых ОС, поддерживающих протоколы TCP/IP, обладают следующей уязвимостью:

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

Berkeley Software Design, Inc. (BSDI); 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 ссылке на WWW-сервер, где экспертами проводились подобные исследования на различных ОС. Там, собственно как и в CERT, эта атака называлась Ping Death . На этом WWW-сервере предлагалось реализовать такую атаку следующим образом: на рабочей станции с ОС Windows '95 или Windows NT необходимо выполнить следующую команду:

ping -l 65527 victim.destination.IP. address (поэтому - Ping Death ).
Так как обычный размер IP-заголовка составляет 20 байт, размер
ICMP-заголовка - 8 байт, то подобный ICMP-пакет будет превышать
максимально возможный размер IP-пакета на 20 байт (65527 + 20 +8 - 65535 = 20).

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

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

  Итак, мы начали тестирование и, честно говоря, абсолютно не удивились, когда ни одна из исследуемых операционных систем, ни IRIX, ни AIX, ни VMS, ни SunOs, ни FreeBSD, ни Linux, ни Windows NT 4.0, ни даже Windows '95 и Windows for WorkGroups 3.11, абсолютно никак не реагировали на подобный некорректный запрос и продолжали нормально функционировать! Тогда были предприняты специальные поиски ОС, которую бы действительно вывела из строя данная атака.

  Ею оказалась Windows 3.11 с WinQVT - эта ОС действительно зависла.

  Уязвимые операционные системы

Operating system Version Symptoms
Solaris (x86) 2.4, 2.5, 2.5.1
Reboot
Minix 1.7.4, v2.0 and probably others Crash
HP3000 MPE/iX 4.0, 5.0, 5.5
System abort
Convex SPP-UX All version Crash
Apple Mac MacOs 7.x.x Crash
Windows 3.11 with Trumpet Winsock ?
Mixed reports
Novell NetWare 3.x Mixed results
Windows '95 All of 'em Crrrash
AIX
3 and 4 Operating system dump.

Linux ? 2.0.23
Spontaneous reboot or kernel panic
DEC Unix/OSF1 2.0 and above Kernel Panic
Open VMS for AXP various Mixed reports
Open VMS for VAX v6.2, UCX v4.0 and others Reboot
HP-UX
9.0 to 10.20 Crash, Reboot, Hang ...

Windows NT 3.5.1
Mixed results
Irix 5.3
Panic
Windows NT 4.0
Crash
SCO Openserver 4.2, 5.0.x Vulnerable
DEC TOPS-20, TOPS-10
All Errors
Digital Firewall ?
Vulnerable
AltaVista Firewall for UNIX ?
Vulnerable

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

  Согласитесь, полный бред! Для полноты картины мы хотели бы далее привести описание exploit'а, созданного для Windows NT 4.0, задача которого, используя ping, завесить собственный компьютер.

  Первым шагом предлагалось запустить Web Browser (?). На втором шаге требовалось запустить taskmgr (Task Manager)
(??). В комментариях к этому шагу говорилось, что так Ping Death работает лучше (еще не хватает шаманского бубна!). И, наконец, требовалось
запустить 18 ping-процессов (???) (не больше и не меньше; может быть, лучше сразу 100 - чего мелочиться!). Если вы думаете, что далее ваша ОС немедленно повиснет, то вы ошибаетесь! В комментариях к exploit'у до получения эффекта предлагалось ждать примерно 10 минут, с философским замечанием о том, что ожидание может продлиться несколько больше (интересно на сколько больше - час, месяц, год ?!) или несколько меньше.

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