Кратко

  • RFC 3128 объединила атаку малым фрагментом и перекрытие, чтобы фильтр проверял один TCP-заголовок, а узел мог собрать другой порт назначения.
  • Исправление потребовало полного минимального TCP-заголовка во фрагменте с нулевым смещением и сохранило запрет смещения один.
  • Результат зависел от правил и реализации сборки; прохождение фрагментов не доказывало завершённого соединения, взлома службы или общей уязвимости всех систем.

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

Однако это ещё не был окончательный заголовок.

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

Если стек назначения отдавал приоритет байтам короткого перекрытия, итоговый заголовок складывался из двух вариантов. Порт брался из второго, а флаги — из первого, прошедшего проверку. Фильтр разрешил одно сочетание полей, а TCP получил другое.

Комбинация была направлена против прежней меры RFC 1858. Та различала атаку малым фрагментом, выносящую важные поля за первую часть, и атаку перекрытием, использующую разный выбор повторяющихся байтов. «Косвенный метод» предлагал отбрасывать TCP-фрагменты с Fragment Offset, равным единице.

Смещение IPv4 измеряется блоками по восемь байтов. Позиция один начинается сразу после первых восьми байтов TCP. Её запрет перекрывал известный способ отделить управляющие флаги от начала заголовка и скрыть их от совместной проверки.

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

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

Поверхность управления была разделена. Отправитель выбирал границы, смещения, порядок и перекрытия. Фильтр управлял допуском видимого представления. IP-стек назначения выбирал результат сборки. TCP решал, принимать ли сегмент, а служба — что делать дальше. Запись одного слоя не могла служить доказательством всей цепочки.

Поэтому RFC 3128 прямо ограничивала вывод точной реализацией сборки на целевом узле. RFC 791 определила поля фрагментации и обязанность получателя, а RFC 815 предложила практический алгоритм обработки дыр и перекрытий. Но универсального обещания, что каждый промежуточный узел и каждый хост выберут одинаковый повторный байт, не существовало.

Эта зависимость не позволяет объявить уязвимыми все узлы. Она также не позволяет фильтру предположить, что конечная система разделит его трактовку. Устройство, которое не нормализует и не собирает полностью, передаёт окончательный выбор другому коду.

Исправление RFC 3128 вводило проверяемый инвариант длины. Если протокол TCP, смещение равно нулю, а транспортная часть короче полного минимального заголовка, пакет отбрасывается. Смещение один тоже остаётся запрещённым. Решение по портам и флагам допускается лишь тогда, когда весь минимальный набор полей присутствует в первой части.

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

Позднейшие документы усилили границы в отдельных архитектурах. RFC 5722 потребовала для IPv6 отбрасывать всю датаграмму при перекрытии. RFC 7112 потребовала полной цепочки заголовков в первом IPv6-фрагменте. RFC 6274 вернулась к безопасности IPv4, а RFC 8900 описала эксплуатационную хрупкость фрагментации между несогласованными узлами и промежуточными устройствами.

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

Та же структура возникает при разной нормализации URL, повторном декодировании и неодинаковом объединении дублирующихся полей. Это не одна и та же атака, но общий разрыв контроля: поле, оправдавшее разрешение, ещё может измениться после решения.

Историческая дисциплина RFC 3128 состоит и в границах доказательства. Журнал фильтра подтверждает временный заголовок и применённое правило. Он сам по себе не подтверждает порт, переданный TCP, завершение соединения или ущерб. Для перехода от допуска к результату нужны исходные фрагменты, фактическое правило сборки и последующие состояния протокола.

Источники