Превышение максимально возможного размера 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 ссылке [29] на 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 якобы можно нарушить работоспособность практически любой сетевой ОС. В завершение на этом сервере приводилась следующая таблица тестирования различных операционных систем, на которые данная удаленная атака якобы произвела необходимый эффект. Далее авторы хотели бы продемонстрировать вам эту таблицу с существенными сокращениями (см. табл. 4.13).
Не правда ли, эта таблица операционных систем, обладающих такой уязвимостью, производит должное впечатление!
Итак, мы начали тестирование и, честно говоря, абсолютно не удивились, когда ни одна из исследуемых операционных систем, ни IRIX, ни AIX, ни VMS, ни SunOs, ни FreeBSD, ни Linux, ни Windows NT 4.0, ни даже Windows '95 и Windows for WorkGroups 3.11, абсолютно никак не реагировали на подобный некорректный запрос и продолжали нормально функционировать! Тогда были предприняты специальные поиски ОС, которую бы действительно вывела из строя данная атака. Ею оказалась Windows 3.11 с WinQVT - эта ОС действительно зависла.
Таблица 4.13
Уязвимые операционные системы
| 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 по поводу данной атаки, является безосновательной, и ничего другого нам, видимо, не остается, как назвать эту атаку очередной программистской байкой и причислить ее к разряду практически неосуществимых.
