Błąd DUCHA: czy istnieje prosty sposób na sprawdzenie, czy mój system jest bezpieczny?

Wygląda na to, że możesz pobrać narzędzie z Uniwersytetu w Chicago , które pozwoli Ci przetestować system pod kątem luki w zabezpieczeniach .

To nie naprawia ani nie restartuje niczego , informuje tylko o tym, czy system jest podatny na ataki.

$ wget https://webshare.uchicago.edu/orgs/ITServices/itsec/Downloads/GHOST.c $ gcc GHOST.c -o GHOST $ ./GHOST [responds vulnerable OR not vulnerable ] 

Po uruchomieniu tego na jednym z moich serwerów zdalnych otrzymuję:

user@host:~# wget https://webshare.uchicago.edu/orgs/ITServices/itsec/Downloads/GHOST.c --2015-01-27 22:30:46-- https://webshare.uchicago.edu/orgs/ITServices/itsec/Downloads/GHOST.c Resolving webshare.uchicago.edu (webshare.uchicago.edu)... 128.135.22.61 Connecting to webshare.uchicago.edu (webshare.uchicago.edu)|128.135.22.61|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 1046 (1.0K) [text/x-csrc] Saving to: `GHOST.c" 100%[============================================>] 1,046 --.-K/s in 0s 2015-01-27 22:30:48 (237 MB/s) - `GHOST.c" saved [1046/1046] user@host:~# gcc GHOST.c -o GHOST user@host:~# ./GHOST vulnerable 

kod źródłowy tego skryptu wygląda jak ten następny blok kodu , ale i tak powinieneś najpierw sprawdzić kod źródłowy . Jak zauważyli inni, jeśli arbitralnie uruchamiasz kod z Internetu, nie wiedząc, co on robi, mogą się zdarzyć złe rzeczy :

/* * GHOST vulnerability check * http://www.openwall.com/lists/oss-security/2015/01/27/9 * Usage: gcc GHOST.c -o GHOST && ./GHOST */ #include <netdb.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <errno.h> #define CANARY "in_the_coal_mine" struct { char buffer[1024]; char canary[sizeof(CANARY)]; } temp = { "buffer", CANARY }; int main(void) { struct hostent resbuf; struct hostent *result; int herrno; int retval; /*** strlen (name) = size_needed - sizeof (*host_addr) - sizeof (*h_addr_ptrs) - 1; ***/ size_t len = sizeof(temp.buffer) - 16*sizeof(unsigned char) - 2*sizeof(char *) - 1; char name[sizeof(temp.buffer)]; memset(name, "0", len); name[len] = "\0"; retval = gethostbyname_r(name, &resbuf, temp.buffer, sizeof(temp.buffer), &result, &herrno); if (strcmp(temp.canary, CANARY) != 0) { puts("vulnerable"); exit(EXIT_SUCCESS); } if (retval == ERANGE) { puts("not vulnerable"); exit(EXIT_SUCCESS); } puts("should not happen"); exit(EXIT_FAILURE); } 

Edytuj : dodałem tutaj poradnika ansibla , jeśli jest przydatny dla każdego, jeśli masz dużą liczbę systemów do testowania to ansibl pozwoli Ci to zrobić szybko.

Ponadto, zgodnie z poniższą dyskusją, jeśli stwierdzisz, że Twoje serwery są podatne na ataki i zastosujesz dostępne łaty, zdecydowanie zalecamy ponowne uruchomienie systemu .

Komentarze

• @KasperSouren No tak. Jeśli jest podatny na atak, zastosuj poprawkę / aktualizację i uruchom ponownie.
• @KasperSouren To, o co pytasz ', jest szczerze mówiąc trochę głupie. Ta odpowiedź doskonale odpowiada na twoje pytanie: jak mogę wykryć tę lukę. To ' to wszystko, o co prosiłeś. Pytanie o ” jedną wkładkę ” też jest trochę głupie. Przeprowadziłem test, który zamieścił tutaj, na wszystkich moich serwerach w mniej niż 2 minuty. To ' jest śmiertelnie proste. Po prostu ” shutdown -r now ” po ' zakończeniu ….. ..
• Zaktualizowałem, przeprowadziłem test, nie ' nie uruchomiłem ponownie. Wróciłem do tego dopiero, gdy dowiedziałem się, że muszę ponownie uruchomić komputer. Może się to zdarzyć wielu osobom, a ich serwery mogą być podatne na ataki i mogą zostać zhakowane pomimo ich fałszywego poczucia bezpieczeństwa. Więc nie jest to głupie, jeśli to możliwe, jeśli to możliwe.
• GHOST.c POC pochodzi z oryginalnego Qualys poradnik .
• @KasperSouren test może powiedzieć, że nowe programy będą używać bezpiecznej wersji glibc. Jednak możesz mieć programy działające w tle, które zostały uruchomione przed aktualizacją i dlatego zostały załadowane starą wersję.

Jedna linijka PHP:

php -r "$e="0";for($i=0;$i<2500;$i++){$e="0$e";gethostbyname($e); }" 

Jedna linijka Pythona:

python -c "import socket;y="0"*50000000;socket.gethostbyname(y)" 

Jeśli to daje ci błędy segfault (tak, segfault Pythona, rzadki okaz), wtedy jesteś „podatny na ataki. Nie wiem, czy uważasz Pythona za” narzędzie programistyczne „, ale PHP jest powszechnym programem.

Jeśli urządzeniem docelowym jest router, nie wiem, co można by na nim zrobić, co by Ci powiedział, z wyjątkiem zagłębiania się w specyfikacje producenta i / lub czekania na porady producenta i aktualizacje oprogramowania sprzętowego.

Komentarze

• Czy można to połączyć z sudo lsof | grep libc- | grep DEL"? Podano w innym komentarzu, aby tego uniknąć ludzie myślą, że ' są bezpieczni, podczas gdy stara biblioteka libc jest nadal używana. Dzięki temu ' od razu przyznam nagrodę.
• To ' jest poleceniem powłoki, więc możesz łączyć rzeczy za pomocą & &. To polecenie jest dostępne dopiero po zaktualizowaniu pakietów glibc.Jeśli ' zaktualizowałeś, te jedna linijka nie powiedzie się. Więc wepchnij swoją aktualizację vommamd pomiędzy?
• Użyłem wersji php na SUSE 11SP3 i nie widziałem żadnych błędów segfault przed ani po łataniu. Jakieś pomysły?
• @marcin To ' jest interesujące. Wyciągnąłem je ze źródeł internetowych i wiele osób zgłasza przypadki segfantacji. Czy zwiększenie liczby pętli coś robi? (Bez względu na to, ile ' jest warte, błąd segfault dla Pythona wystąpi również w niektórych systemach z łatkami … nie ma słowa o tym, dlaczego ' s.)
• Po zabawie z kodem uchicago wygląda na to, że jeśli spróbujesz przepełnić go o więcej niż 4 bajty, gethostbyname () zwróci błąd (EINVAL) zamiast przepełnienia. Dzięki C możesz dokładnie kontrolować, co zostanie nadpisane. W PHP lub Pythonie to, co zostanie nadpisane, może być ważne i błędne lub może być niczym; będzie to ' będzie zależne od dokładnej budowy systemu. A błąd segfaulta w Pythonie na gethostbyname("0"*50000000) wygląda bardziej jak błąd w Pythonie. (Ghost Python?)

aaronfay „odpowiedziała już na określenie, czy Twój podstawowy system jest podatny na atak, ale nie wykrywa, czy istnieją programy, które po aktualizacji nadal działają przy użyciu starej wersji biblioteki glibc. Oznacza to, że możesz przeprowadzić aktualizację bez ponownego uruchamiania procesów, których dotyczy luka, a skrypt zgłosi „brak luki”, mimo że stara, podatna na ataki biblioteka jest nadal w użyciu.

Oto jeden sposób sprawdzenia, czy są jakieś dynamicznie połączone programy nadal używają starej wersji glibc:

sudo lsof | grep libc- | grep DEL 

Jeśli istnieją wyniki, usunięte wersje glibc są w użyciu, a procesy ich używające mogą być podatny.

Oczywiście nie obejmuje to przypadku, w którym glibc był dowiązany statycznie. Dobrą (?) wiadomością jest to, że bardzo rzadko można znaleźć statycznie połączony plik glibc w pliku binarnym, ponieważ rozmiaru, a także dlatego, że stwarza inne uciążliwości i trudności. W przypadku, gdy masz programy używające statycznie skompilowanego glibc (czego prawie na pewno nie robisz), będziesz musiał je ponownie skompilować.

Komentarze

• lsof +c0 -f -- /usr/lib64/libc-*.so | grep "(deleted)$" nieco dokładniej, pokazuje pełne nazwy procesów i szuka linków do plików, które zostały usunięte.

Jeśli masz konto w Redhat, możesz uzyskać dostęp do ich „wykrywacza GHOST” pod adresem ten adres URL . Jest to mały skrypt powłoki, który poinformuje Cię, czy glibc jest podatny na ataki.

Red Hat wrócił teraz i stwierdził, że ich skrypt wykrywający jest wadliwy. Zauważ, że istnieje również problem w RHEL6.6 podczas używania yum –security do załatania luki, ponieważ została pominięta zgodnie z https://bugzilla.redhat.com/show_bug.cgi?id=1186717 .

Komentarze

• Narzędzie RedHat sprawdza tylko wersję RPM glibc i tylko to wie o wersjach RedHata (i prawdopodobnie pochodnych). W rzeczywistości nie działa na żadnym innym systemie operacyjnym.
• Nie jest już dostępny do pobrania, prawdopodobnie ma to związek z wadami.