Ping of death

Ping смерті (англ. Ping of death) — це тип інформаційної атаки на комп'ютерну систему, що передбачає відправлення неправильного або шкідливого ping-трафіку на комп'ютер жертви.

Правильно сформований ping-пакет, як правило, містить 56 байтів або 64 байти у випадку використання заголовка протоколу Internet Protocol. Проте будь-який IPv4-пакет (включаючи ping) може містити 65535 байт. Деякі комп'ютерні системи ніколи не були розроблені для абсолютно правильної обробки ping пакета більшого, ніж максимальний розмір пакета взагалі, оскільки він порушує Інтернет-протокол, задокументований в стандарті RFC 791. Подібно до інших великих, але добре сформованих пакетів, перед передачею ping-пакети смерті фрагментуються у групи розміром 8 октетів. Проте, коли цільовий комп'ютер повторно об'єднує неправильну послідовність пакетів, може виникнути переповнення буфера, що призведе до аварійного завершення роботи системи і потенційно дозволить ввести шкідливий код.

Щоб виконати цей атаку, було достатньо однієї команди з Windows 95 або NT:

ping -l 65510 example.com

Більшість систем було виправлено в 1997—1998 роках, тому ця уразливість нині є історичною.

У попередніх реалізаціях TCP / IP ця помилка була проста у використанні і могла вплинути на безліч різних систем, включаючи Unix, Linux, Mac, Windows і периферійні пристрої. Оскільки системи почали фільтрувати дану атаку з допомогою брандмауерів та інших методів виявлення, пізніше з'явився інший тип ping-атаки, відомий як «ping затоплення», яке заливає жертву надзвичайно великою кількістю ping-пакетів, тому нормальний трафік не може досягти системи (основна відмова — атака на службу).

Як визначено в RFC 791, максимальна довжина IPv4-пакета, включаючи IP-заголовок, становить 65,535 (2¹⁶ — 1) байт, обмеження, що виникає при використанні 16-розрядного широкого поля заголовка IP, що описує загальну довжину пакету.

Низький рівень зв'язку майже завжди встановлює межі пакета на максимальний розмір кадру (див. MTU). У Ethernet це, як правило, 1500 байт. У такому випадку великий пакет IP буде розділений на кілька IP-пакетів (також відомих як IP-фрагменти), так що кожен IP-фрагмент відповідає встановленому ліміту. Приймач IP-фрагментів збиратиме їх у повний IP-пакет і продовжуватиме обробляти його як завжди.

Коли виконується фрагментація, кожен IP-фрагмент повинен містити інформацію про те, яку частину оригінального пакету IP він містить. Ця інформація зберігається у полі «Зсув фрагмента» у заголовку IP. Поле має довжину 13 біт і містить зміщення даних у поточному фрагменті IP щодо вихідного IP-пакету. Зсув визначається в одиницях по 8 байт. Це дозволяє збільшити максимальне зміщення до 65 528 ((213-1) * 8) байт. Тоді при додаванні 20 байтів IP-заголовка максимум буде 65548 байт, що перевищує максимальний розмір кадру. Це означає, що фрагмент IP з максимальним зміщенням має мати дані не більше 7 байтів, або ж він перевищить межу максимальної довжини пакету. Шкідливий користувач може надіслати фрагмент IP з максимальним зміщенням і набагато більше даних, ніж 8 байт (настільки великий, наскільки фізичний рівень дозволяє йому).

Коли приймач збирає всі фрагменти IP, він закінчується IP-пакетом, що перевищує 65,535 байт. Це, можливо, переповнює буфер пам'яті, який приймач виділяється для пакета, і може викликати різні проблеми.

Як видно з наведеного вище опису, проблема не має нічого спільного з ICMP, який використовується лише як корисне навантаження, досить велике, щоб використати проблему. Це проблема в процесі повторної збірки фрагментів IP, які можуть містити будь-який тип протоколу (TCP, UDP, IGMP та ін.).

Виправлення проблеми полягає в тому, щоб додати чек у процесі повторної збірки. Перевірка кожного вхідного фрагмента IP гарантує, що в полях «Фрагмент офсет» та «Загальна тривалість» у заголовку IP кожного фрагмента IP менше 65,535. Якщо сума більша, то пакет недійсний, а фрагмент IP ігнорується. Цю перевірку виконують деякі брандмауери, щоб захистити комп'ютери, у яких немає помилки. Іншим виправленням для проблеми є використання буфера пам'яті, що перевищує 65,535 байт для повторної збірки пакета. (Це, по суті, є порушенням специфікації, оскільки він додає підтримку для пакетів, більших за дозволені.)

У 2013 році в Microsoft Windows ця помилка була виявлена у ​​версії IPv6. Стек Windows TCP / IP не обробляв правильний розподіл пам'яті при обробці вхідних неправильних пакетів ICMPv6, що може спричинити віддалену відмову в обслуговуванні. Ця проблема була зафіксована в MS13-065 в серпні 2013 року. CVE-ID для цієї вразливості є CVE-2013-3183.