W pierwszym biuletynie bezpieczeństwa za 2019 rok firma Netflix ostrzega przed opartymi o protokół TCP zdalnymi atakami typu DoS, które dotyczą zarówno systemu Linux, jak i FreeBSD. Ich poziom jest określany jako “krytyczny”. Luki odkryte przez Jonathana Looneya dotyczą w szczególności maksymalnego rozmiaru segmentu (ang. Maximum Segment Size (MSS)) oraz potwierdzeń selektywnych (ang. Selective Acknowledgments (SACK)). Najpoważniejszą jest luka “SACK Panic”, które pozwala na zdalne wywołanie paniki jądra systemu Linux.

CVE-2019-11477: SACK Panic

Specjalnie spreparowana sekwencja pakietów SACK może wywołać błąd przekroczenia zakresu liczb całkowitych (ang. integer overflow), co doprowadza do paniki jądra i zawieszenia lub zrestartowania systemu Linux (w zależności, na jaką wartość mamy ustawiony parametr: kernel.panic w systcl). Problem tkwi w centralnej strukturze danych używanej w implementacji TCP/IP Linuksa o nazwie SKB (ang. Socket Buffer). Jest to połączona liczba buforów, która przechowuje pakiety sieciowe. Taka lista może pełnić rolę: kolejki do wysyłki, kolejki do odbioru, kolejki SACK, kolejki retransmisji itd. SKB może przechowywać dane pakietów w fragmentach, a dokładniej jest w stanie pomieścić ich 17:

linux/include/linux/skbuff.h
define MAX_SKB_FRAGS (65536/PAGE_SIZE + 1)  => 17

Po przekroczeniu tego limitu może dojść do paniki jądra. Drugim czynnikiem jest parametr maksymalnego rozmiaru segmentu – MSS, który określa całkowitą ilość danych zawartych w zrekonstruowanym segmencie TCP. Zdalny użytkownik może doprowadzić do przekroczenia tego limitu ustawiając maksymalny rozmiar segmentu połączenia TCP na najniższy limit 48 bajtów i wysłać sekwencję specjalnie spreparowanych pakietów SACK. Najniższy MSS pozostawia zaledwie 8 bajtów danych na segment, zwiększając tym samym liczbę segmentów TCP wymaganych do wysłania wszystkich danych – co doprowadza do przepełnienia SKB. Luką dotknięte są wszystkie jądra od wersji 2.6.29. Obejściem problemu do czasu pojawienia się poprawek w jądrze jest zablokowanie połączeń z niską wartością MSS. Możemy to zrobić np. za pomocą iptables:

iptables -I INPUT -p tcp --tcp-flags SYN SYN -m tcpmss --mss 1:500 -j DROP
ip6tables -I INPUT -p tcp --tcp-flags SYN SYN -m tcpmss --mss 1:500 -j DROP

Ustawienie powyższych reguł spowoduje odrzucenie prób nowego połączenia z rozmiarem MSS z zakresu od 1 do 500. Należy mieć świadomość, że możemy zablokować te połączenia, które są poprawne i opierają się na niskim MSS. Wartości podane w filtrach są tylko przykładowe i należy zastosować wyższe lub niższe wartości – odpowiednie dla naszego środowiska sieciowego. Jeśli nie chcemy, aby złośliwy ruch zwiększał obciążenie procesora – możemy go odrzucać jeszcze przed procesem filtrowania w łańcuchu PREROUTING, czyli zaraz po tym, jak pakiet zostanie odebrany:

iptables -t raw -I PREROUTING -i eth0 -p tcp -m tcp --tcp-flags SYN SYN \
-m tcpmss --mss 1:500 -j DROP 

Ograniczenie ataku za pomocą iptables będzie skuteczne tylko wtedy, gdy próbkowanie MTU przez TCP jest wyłączone (czyli opcja net.ipv4.tcp_mtu_probing w sysctl ma wartość: 0, co wydaje się być wartością domyślną). Drugim sposobem złagodzenia możliwości przeprowadzenia ataku jest wyłączenie mechanizmu SACK:

echo "net.ipv4.tcp_sack=0" > /etc/sysctl.d/99-tcpsack.conf
sysctl --system

lub

echo "net.ipv4.tcp_sack=0" >> /etc/sysctl.conf
sysctl -p

Które obejście wybierzemy zależy od nas. Jedno z nich powinno być wystarczające i nie ma konieczności stosowania obu na raz.
CVE-2019-11478: SACK Slowness

Możliwe jest wysłanie specjalnie spreparowanej sekwencji SACK, które spowoduje fragmentację kolejki stosowanej do retransmisji TCP. W jądrach Linuksa o wersjach wcześniejszych niż 4.15 osoba atakująca może być w stanie wykorzystać tak pofragmentowaną kolejkę do kosztownego “spaceru” po niej (jej przeglądania) w poszukiwaniu kolejnych sekwencji SACK otrzymanych dla tego samego połączenia TCP.

CVE-2019-11479: Excess Resource Consumption Due to Low MSS Values

Osoba atakująca może zmusić jądro Linuksa do podzielenia odpowiedzi na wiele segmentów TCP, z których każda zawiera tylko 8 bajtów danych. Zabieg taki znacznie zwiększa przepustowość wymaganą do dostarczenia takiej samej ilości danych niż w przypadku normalnego przebiegu tego procesu. Ponadto zużywane są dodatkowe zasoby (moc obliczeniowa procesora oraz karty sieciowej). Atak ten wymaga też ciągłego zaangażowania ze strony atakującego, ponieważ odpowiedzi zostają zakończone wkrótce po tym, jak atakujący przestanie wysyłać szkodliwy ruch do maszyny. Na takie nadmierne zużycie zasobów spowodowane stosowaniem niskim wartości MSS podatne są wszystkie wersje Linuksa.

Podsumowanie:

Ograniczenie ataków możliwych w CVE-2019-11478 oraz CVE-2019-11479 sprowadza się do tych samych mechanizmów, co w CVE-2019-11477 – czyli możemy filtrować odpowiednie wartości MSS na poziomie filtra pakietów lub wyłączyć w systemie mechanizm SACK. Podatności te zostały już zaadresowane w poprawkach zgłaszanych do jądra Linuksa. Dystrybucje Ubuntu oraz RedHat, czy dostawcy chmur obliczeniowych, jak Amazon – wydały już odpowiednie aktualizacje. Podobny problem miał system OpenBSD w 2005 roku. Jeśli chodzi o FreeBSD (CVE-2019-5599) – to luka jest podobna do systemu Linux i dotyka system w wersji 12’stej: możliwe jest wysłanie spreparowanej sekwencji SACK, która spowoduje fragmentację mapy wysyłania RACK. Osoba atakująca może być w stanie wykorzystać podefragmentowaną mapę wysyłania, aby spowodować kosztowne przeglądanie listy połączeń dla kolejnych sekwencji SACK otrzymanych dla tego samego połączenia TCP. Na szczęście FreeBSD 12 nie ma domyślnie włączonego mechanizmu RACK i wymaga rekompilacji jądra z własną konfiguracją do jego włączenia.

Niestety bardzo wiele urządzeń IoT, czy starszych wersji telefonów z systemem Android zostanie podatnych na tego typu ataki – ze względu na brak możliwości aktualizacji. Luki w mechanizmie SACK przypominają atak Ping of Death z lat 90-tych, kiedy spreparowany pakiet IP mógł spowodować zamrożenie lub ponowne uruchomienie systemu.

Więcej informacji: Linux and FreeBSD Kernel: Multiple TCP-based remote denial of service vulnerabilities