P

odczas codziennego użytkowania Internetu zazwyczaj korzystamy z dwóch metod HTTP: GET oraz POST. Inną metodą jest OPTIONS, która po prostu pozwala na odpytanie serwera HTTP, jakich metod może użyć użytkownik w komunikacji z nim. Serwer powinien nam odpowiedzieć wartością nagłówka “Allow”, gdzie obsługiwane metody będą wymienione po przecinku:

curl -v -XOPTIONS https://www.0x0.pl > /dev/null

HTTP/1.1 200 OK
Allow: OPTIONS, GET, HEAD, POST
Cache-Control: max-age=604800

Okazało się, że podczas badań nad top milionem domen Hanno Böck trafił na dziwne odpowiedzi płynące z tego zapytania. Dużo odpowiedzi zawierało oprócz dozwolonych metod, jakby uszkodzone dane. Swoją charakterystyką przypominały wycieki pamięci. Inną wskazówką był fakt, że w każdym uszkodzonym nagłówku odpowiedzi zawierały ciągi, które były wyraźnie wskazywały na konfigurację serwera httpd Apache. Po konsultacjach z developerem Apache – Jacobem Championem okazało się, że problem tkwi w dyrektywie Limit, która pozwala na limitowanie dostępu do konkretnych metod HTTP. Wystarczy, że owa dyrektywa z poziomu globalnej konfiguracji lub pliku .htaccess będzie próbowała wprowadzić limit dla nieistniejącej metody HTTP:

<Limit SPLOIT>
</Limit>

Wówczas dojdzie do błędu typu Use After Free. Może to doprowadzić do wycieku części pamięci z procesu serwera, w której mogą znajdować się poufne dane. Cieknąca pamięć zmienia się po wysłaniu wielu żądań, więc dla podatny serwer może ujawnić dowolną liczbę bloków pamięci. Szczególnie narażone są serwery działające w środowisku hostingu współdzielonego. Błąd nie ogranicza się do jednego hosta wirtualnego, dlatego złośliwy klient posiadający możliwość sterowania konfiguracją za pomocą pliku .htaccess może celowo utworzyć błędną konfigurację mając nadzieję, że uzyska dostęp do wrażliwych informacji z innych hostów na tym samym serwerze.

Podatne są wszystkie wersje Apache 2.x do 2.2.34 oraz 2.4 do 2.4.27. Jak zaznacza autor znaleziska reprodukcja błędu oraz sprawdzenie podatności swojego serwera jest bardzo niedeterministyczna. Możemy posłużyć się do tego dedykowanym skryptem lub narzędziem curl testując różne adresy pod różnym obciążeniem. Jeśli nasza dystrybucja nie zapewniła nam jeszcze możliwości aktualizacji możemy przekompilować paczkę z odpowiednią łatką dla 2.4 lub 2.2. Czy globalna blokada OPTIONS jest tymczasowym rozwiązaniem? Nie. Paru użytkowników zgłosiło już fakt, że są w stanie powtórzyć błąd dla innych istniejących metod np. GET.

Więcej informacji: Optionsbleed – HTTP OPTIONS method can leak Apache’s server memory, CVE-2017-9798