ошибки TCP-соединений в результате передачи сбойных ACK-пакетов

•	Главная
•	Архив новостей
•	Безопасность в Unix
•	Безопасность в Windows
•	Сборник FAQ'ов
•	Телефония, фрикинг
•	Кредитные карты
•	Криптография
•	Истории о хакерах
•	Программы, утилиты

_el@sp.sz.ru

ошибки TCP-соединений в результате передачи сбойных ACK-пакетов

Wietse Venema, IBM T.J. Watson Research Center, Hawthorne, NY, USA.

Недавно несколько лиц сообщили о ошибках доставки почты, поскольку управляющие последовательности символов (к примеру, ^A^A^H) были переданы в составе сообщения, в результате чего произвошли сбои SMTP-транспорта и неотправка почты.

Эта проблема не зависит от системы, установленной на хосте - они наблюдались и при использовании систем Linux, и BSD/OS, и при передаче почты средствами Postfix, Sendmail и qmail.

Были произведены съёмы дампов траффика, соответствующего ошибочным SMTP-сессиям, и данный рапорт базируется на этих данных.

Вкратце, проблема с "лишним" ACK-пакетом создаётся системой, являюейся звеном в цепочке передачи данных от хоста к хосту. При неких условиях, включающих прибытие пакетов с задержкой и их форвардинг, система делает копию настоящего ACK-пакета, меняет местами поля SRC_ADDR и DEST_ADDR и посылает его далее.

Проблемаа возникает, когда в результате ошибки поле с опциями из оригинального TCP-пакета посылаются как поле данных скопированного ACK-пакета. Это и приводит с сбою в потоке данных TCP, потому как "кривые" данные посылаются в виде пакета с правильными контрольными суммами заголовков IP и TCP. Тот факт, что следующий пакет перекроет ошибочный, не может помешать тому, что "кривые" данные передаются приложению.

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

Итак, базируясь на времени, в течении которого порченый пакет возвращался обратно, и на анализе систем ан пути его следования, стало возможным свести проблему к небольшому количеству роутеров CISCO - IOS 11.3.11a и 12.08. По крайней мере известно, что сбои происходят на определённом берегу Атлантического океана

Выяснилось, что один из случаев повреждения данных был спровоцирован системой управления пропускной способностью канала. Данная система работает, как bridge, и не показана в результатах работы traceroute. Но информация в временах прохождения и стала фактом, по которому мы смогли отследить место возникновения проблемы.

Эта система управления траффиком переводит поле опций TCP в данные, к примеру - опции NOP. Данная опция упоминалась в RFC 973, в далёком 1981 году. Итак, мы пришли к тому, что данная система переводит опции в данные (Control-A, к примеру).

Только недавние версии Linux используют поле timestamp пакета, что приводит к тому, что последовательности 01 01 08 0a в пакетах интерпретируются как данные ^A^A^H^J.

ПРИМЕР ОШИБКИ ПЕРЕДАЧИ ДАННЫХ

Ниже следует фрагмент SMTP-сессии, одной из тех, которые были записаны на обоих хостах - отправителе и получателе. Первый пример показывает одну строчку результатов работы tcpdump, после чего следует расшифровка поля IP header, 20 байт TCP header и 12 байт поля TCP header options: 12:28:37.051883 195.52.11.4.25 > 194.25.134.80.1730: . ack 86 win 32120 <nop,nop,timestamp 1105397 766737219> (DF) IP_HDR=20 IP_OPT=0 TCP_HDR=20 TCP_OPT=12 DATA=0 FLAGS=ACK IP_HDR 45 00 00 34 52 2f 40 00 40 06 vhl tos len len id id off off ttl pro IP_HDR d1 f2 c3 34 0b 04 c2 19 86 50 sum sum src src src src dst dst dst dst TCP_HDR 00 19 06 c2 f5 22 60 dd f4 ce src src dst dst seq seq seq seq ack ack TCP_HDR fc e1 80 10 7d 78 0d 1a 00 00 ack ack off flg win win sum sum urp urp TCP_OPT 01 01 08 0a 00 10 dd f5 2d b3 opt opt opt opt opt opt opt opt opt opt TCP_OPT 7b 43 opt opt А ниже слдедует расшифровка того самого злочастного "extra ACK", который был сгенерирован роутером-посредником, а не системой-получателем. Заметьте, что в поле IDENT то же самое значение 0x522F, что и в поле инициировавшего сбой пакета. В поле TCP options те же самые 12 байт, что и в предшествовавшем ему корректном пакете. Но в результате сбоя опции передаются как данные, и они воспринимаются приложением как ^A^A^H .. 12:28:37.056438 194.25.134.80.1730 > 195.52.11.4.25: . 86:98(12) ack 112 win 2920 (DF) IP_HDR=20 IP_OPT=0 TCP_HDR=20 TCP_OPT=0 DATA=12 FLAGS=ACK IP_HDR 45 00 00 34 52 2f 40 00 3c 06 vhl tos len len id id off off ttl pro IP_HDR d5 f2 c2 19 86 50 c3 34 0b 04 sum sum src src src src dst dst dst dst TCP_HDR 06 c2 00 19 f4 ce fc e1 f5 22 src src dst dst seq seq seq seq ack ack TCP_HDR 60 d5 50 10 0b 68 af 32 00 00 ack ack off flg win win sum sum urp urp DATA 01 01 08 0a 00 10 dd f5 2d b3 ^A ^A ^H ^J ^@ ^P dd f5 - b3 DATA 7b 43 { C Полный текст статьи на английском языке доступен по адресу ftp://ftp.porcupine.org/pub/debugging/ack-corruption.README, и, несомненно, заинтересует системную администрацию больших провайдеров верхних уровней.
duke.

Team Void