Уважаемые хабро-читатели, прежде чем перейти к сути хочу сразу сказать, что автор не является каким бы то ни было хакером или зловредным программером, исследующим со свечкой каждый темный угол драйвера или чего-либо другого программного, поэтому если об этой уязвимости уже известно, то не судите строго, а лучше посоветуйте патч.
Итак, в процессе отладки стека протоколов для сетей MANET, где тестировалось модифицированное ТСР-соединение радиосети с компьютером через Ethernet-шлюз, было случайно выявлено, что путем некорректного закрытия соединения клиентом на стороне сервера возможно удерживание ресурсов сокета бесконечно долго!
Началось всё с этого:
На скрин-шоте представлено ТСР-соединение между клиентом 192.168.0.108 (Ethernet шлюз) и сервером 192.168.0.187 (OS Windows Vista).
Как видно, при неправильном указании номера последовательности в пакете FIN ACK клиента, Windows сервер не закрыл сокет и не освободил ресурсы. Попытка соединиться еще раз с того же порта клиента (source port 40400) на порт сервера (destination port 31000) оказалась неуспешной. Сервер упорно требовал ACK в ответ на новый SYN от клиента.
Сначала, я решил что это просто какой-то баг на стороне стека MANET (помимо, конечно же, неправильного seqno в FIN ACK), но проанализировав поток по номерам sequence / acknowledgement и повторив этот же эксперимент для других портов оказалось, что таки да, Windows…
Пример другого порта сервера (30000):
Потом, перегрузив комп и повторили все еще раз. На этот раз соединение закрывал клиент, а сервер слушал порт 32000.
Результат тот же.
Потом посмотрели командой netstat состояние сокетов и ужаснулись…
Сервер держит открытым сокеты, которых нет в природе уже много часов!!!
И скорее всего, только принудительное убийство процессов или перезагрузка, спасет положение, т.к. очевидно в состоянии FIN_WAIT_2 у Windows нет таймера для сокета и он не переходит в состояние TIME_WAIT для очистки ресурсов.
Резюме
1. Убедительная просьба сообщить об известности этой уязвимости.
Если это вновь открытый баг, то это ставит под угрозу многие сетевые продукты на OS Windows.
2. Было бы интересно исследовать данную проблему на других серверах и ОС, в первую очередь Linux.
3. Изучайте сетевые протоколы!
P.S.
прошли сутки со дня открытия проблемы — ресурсы выделены до сих пор…
Автор: YuriiVoitenko
