Ta luka istniała od zawsze. Niedawna publikacja dowodząca tego, że błąd ten umożliwia zakłócenie pracy całego Internetu, spowodowała, iż został on naprawiony, i to praktycznie w ciągu kilku dni!

Właśnie ta szybkość reakcji oraz fakt, że autorami dokumentu są specjaliści firm Juniper i Cisco, każą przypuszczać, że rozwiązanie to zostało już dawno wymyślone w laboratoriach obu firm. Naiwnością bowiem byłoby sądzić, że firmy utrzymujące się głównie z popularności Internetu nie pracują nad rozwiązaniem problemów, które mogą spowodować zahamowanie jego popularności.

Czy możemy więc spać spokojnie, wiedząc, że wielcy Internetu przyjdą z gotową receptą na podobne problemy w przyszłości? Aby odpowiedzieć na to pytanie, przyjrzyjmy się, jakie zmiany w TCP proponują nam dzisiaj i co z nich wynika.

Oto, co mówi oryginalna specyfikacja TCP o przerywaniu istniejącego połączenia za pomocą pakietu RST:

• Jeśli otrzymasz pakiet RST z numerem sekwencyjnym niemieszczącym się w oknie transmisji, po cichu odrzuć pakiet.

• Jeśli otrzymasz pakiet RST z numerem sekwencyjnym mieszczącym się w oknie transmisji, natychmiast zerwij połączenie.

  Proponowane przez Cisco i Juniper zmiany w specyfikacji protokołu nakazują następujące zachowanie:

• Jeśli otrzymasz pakiet RST z numerem sekwencyjnym niemieszczącym się w oknie transmisji, po cichu odrzuć pakiet.

• Jeśli otrzymasz pakiet RST z numerem sekwencyjnym dokładnie odpowiadającym oczekiwanemu numerowi, natychmiast zerwij połączenie.

• Jeśli otrzymasz pakiet RST z numerem sekwencyjnym mieszczącym się w oknie transmisji, wyślij potwierdzenie (pakiet z flagą ACK) i poczekaj na odpowiedź.

Takie zachowanie TCP sprawi, że "tylko" trafienie we właściwe okno spowoduje tylko wysłanie pakietu ACK do drugiej maszyny uczestniczącej w transmisji, a nie faktyczne zerwanie połączenia. Pakiet RST musi od tej pory zawierać numer sekwencyjny dokładnie odpowiadający oczekiwanemu. Nie wystarczy już tylko "trafić w okno".

Istniejące połączenia TCP można też zrywać za pomocą pakietów z flagą SYN. To bardzo istotna cecha protokołu w sytuacji, gdy jeden z komputerów biorących udział w danej transmisji zawiesi się bądź zostanie np. zresetowany bez wcześniejszego zerwania połączenia. W takim przypadku próba nawiązania połączenia na tych samych portach musi spowodować przerwanie wcześniejszej komunikacji.

Do tej pory protokół TCP radził sobie w tej sytuacji w następujący sposób:

• Jeśli otrzymany pakiet SYN ma numer sekwencyjny niemieszczący się w oknie transmisji, wyślij potwierdzenie (pakiet z flagą ACK).

• Jeśli otrzymany pakiet SYN ma numer sekwencyjny mieszczący się w oknie transmisji, wyślij pakiet RST do nadawcy i zerwij połączenie.

Oto proponowane zmiany w specyfikacji protokołu:

• Jeśli otrzymany pakiet SYN ma numer sekwencyjny niemieszczący się w oknie transmisji, wyślij potwierdzenie (pakiet z flagą ACK).

• Jeśli otrzymany pakiet SYN ma numer sekwencyjny dokładnie odpowiadający oczekiwanemu numerowi, wyślij pakiet ACK z numerem sekwencyjnym pomniejszonym o jeden.

• Jeśli otrzymany pakiet SYN ma numer sekwencyjny mieszczący się w oknie transmisji, wyślij pakiet z flagą ACK.

Dzięki takiemu podejściu w każdej sytuacji istnieje potrzeba, aby komputer na drugim końcu połączenia zawsze potwierdził swój zamiar, wysyłając pakiet RST (bierze się to stąd, że wysłany w celu potwierdzenia pakiet ACK trafi na nieistniejące już połączenie i spowoduje wygenerowanie pakietu RST). W połączeniu z poprzednim zabiegiem otrzymujemy ulepszoną wersję protokołu TCP, który jest odporny na problem resetowania połączeń przy wykorzystaniu okien.

Takie rozwiązanie zapobiegnie omawianemu atakowi albo przynajmniej go utrudni. Podnoszą się jednak głosy, że może ono sprawiać problemy np. przy konfigurowaniu firewalli. Zaproponowane recepty mogąĘwięc doprowadzić do jeszcze większych powikłań. Mimo to powyższe zalecenia uwzględnili już np. twórcy systemu FreeBSD, a kolejne implementacje pojawią się wkrótce. Życie szybko zweryfikuje nowe propozycje.

Tomasz Grabowski