GHOST hiba: van-e egy egyszerű módja annak tesztelésére, hogy a rendszerem biztonságos-e?

Úgy tűnik, hogy letölthet egy eszközt a Chicagói Egyetemről , amely lehetővé teszi a rendszer tesztelését a biztonsági rés szempontjából .

Ez nem javít és nem indít újra semmit , csak akkor közli, ha a rendszere sebezhető.

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

Ezt az egyik távoli szerveremen futtatva kapom:

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 

A szkript forráskódja úgy néz ki, mint ez a következő kódblokk: , de mindenképpen először ellenőrizze az eredet kódját . Amint arra mások is rámutattak, ha önkényesen futtatja a kódot az internetről anélkül, hogy tudná, mit csinál, akkor rossz dolgok történhetnek :

/* * 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); } 

Szerkesztés : Hozzáadtam egy lehetséges lejátszási könyvet ide , ha bárkinek hasznos, ha nagy száma van rendszer tesztelésére, akkor lehetővé teszi, hogy ezt gyorsan elvégezze.

Továbbá, az alábbi beszélgetés szerint, ha kiszolgálóit sebezhetőnek találja és elérhető javításokat alkalmaz, akkor erősen ajánlott a rendszer újraindítása .

Megjegyzések

• @KasperSouren Nos, igen. Ha sérülékeny, alkalmazza a javítást / frissítést és indítsa újra.
• @KasperSouren Az, amit ‘ kérdez, őszintén szólva kissé buta. Ez a válasz tökéletesen megválaszolja a kérdését: hogyan fedezhetem fel ezt a biztonsági rést. Ennyit kért ‘. ” egy vonalhajózás ” kérése szintén kissé ostoba. 2 perc alatt lefuttattam az összes szerveremen itt közzétett tesztet. ‘ halottan egyszerű. Csak ” leállítás -r most “, miután elkészült ‘ ….. ..
• Frissítettem, lefuttattam a tesztet, nem indultam ‘ t. Erre csak akkor jöttem vissza, amikor megtudtam, hogy újra kell indítanom. Ez jó néhány emberrel előfordulhat, és kiszolgálóik sérülékenyek lehetnek, és hamis biztonságérzetük ellenére feltörhetik őket. Tehát nem olyan butaság, hogy ezt az IMHO-t, ha lehetséges, megegyezzük.
• A GHOST.c POC az eredeti Qualys-ból származik tanácsadó .
• A @KasperSouren teszt elárulhatja, hogy az új programok a glibc biztonságos verzióját használják. Előfordulhat azonban, hogy a háttérben futó programok futnak a frissítés előtt, ezért betöltötték a régi verziót.

PHP egysoros:

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

Egysoros Python:

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

Ha ezek megadják az alapértelmezéseket (igen, egy Python-segfaultot, egy ritka példányt), akkor sérülékeny vagy. Nem tudom, ha a Pythont “fejlesztői eszköznek” tekinted, de a PHP egy általános program.

Ha a céleszköz útválasztó, akkor nem tudok semmit, amit megtehetnél rajta, ami elmondaná neked, kivéve, ha elmélyülök a gyártó specifikációiban és / vagy várok a gyártói tanácsokra és a firmware-frissítésekre.

megjegyzések

• kombinálható-e ez a következővel: sudo lsof | grep libc- | grep DEL"? Ennek elkerülése érdekében egy másik megjegyzésben szerepel az emberek azt hiszik, hogy ‘ biztonságban vannak, amíg a régi libc még mindig használatban van. Ezzel a kiegészítéssel azonnal kiadom a fejemet.
• Ez ‘ egy shell parancsot tartalmaz, így a & . És ez a parancs csak a glibc csomagok frissítése után lehetséges.Ha ‘ frissített, akkor ez az egy vonal nem fog sikerülni. Tehát töltse be a frissítés vommamd fájlját?
• A php-t a SUSE 11SP3-on használtam, és a javítás előtt vagy után nem láttam segfaultot. Van valami ötlet?
• @marcin Ez érdekes ‘. Ezeket internetes forrásokból hoztam, és sokan beszámoltak arról, hogy bántalmaznak. A hurokszám növelése tesz valamit? (Mit ér ‘, a Python segfaultja egyes javított rendszereken is szét fog szegmentálódni … szó sincs arról, hogy miért ‘
• Az uchicago-kóddal való játéktól úgy tűnik, hogy ha megpróbál több mint 4 bájttal túlcsordulni, akkor a gethostbyname () hibát (EINVAL) ad vissza túlcsordulás helyett. A C segítségével pontosan szabályozhatja, hogy mi kerül felülírásra. A PHP vagy a Python használatával fontos lehet, hogy a felülírások fontosak és megkülönböztethetőek legyenek, vagy lehet, hogy semmi; ‘ a rendszer pontos felépítésétől függ. És a gethostbyname("0"*50000000) Python segfault nekem inkább a Python hibájának tűnik. (Ghost Python?)

aaronfay válasza már lefedte annak meghatározását, hogy az alaprendszere sebezhető-e, de nem érzékeli, hogy vannak-e olyan programok, amelyek a frissítés után még mindig a glibc régi verzióját használják. Vagyis frissítheti az érintett folyamatok újraindítása nélkül, és a parancsfájl “nem sérülékeny” jelentést ad, annak ellenére, hogy a régi, sérülékeny könyvtárat továbbra is használják. dinamikusan összekapcsolt programok, amelyek továbbra is a glibc régi verzióját használják:

sudo lsof | grep libc- | grep DEL 

Ha vannak eredmények, akkor a glibc törölt verziói vannak használatban, és az őket használó folyamatok sebezhető.

Ez természetesen nem fedi le azt az esetet, amelyben a glibc statikusan kapcsolódott. A jó (?) hír az, hogy nagyon ritkán találunk statikusan összekapcsolt glibc-t bináris fájlban, mindkettő miatt méretű, és mivel ez más bosszúságokat és nehézségeket okoz. Abban az esetben, ha van nak olyan programja, amely statikusan összeállított glibc-t használ (amit szinte biztosan nem használ), akkor újra kell fordítania őket.

Megjegyzések

• lsof +c0 -f -- /usr/lib64/libc-*.so | grep "(deleted)$" egy kicsit pontosabban, megmutatja a folyamatok teljes nevét és törli a fájlokat.

Ha van fiókja a Redhat-ban, akkor elérheti “GHOST detektorát” a ez az URL . Ez egy kis shell parancsfájl, amely megmondja, hogy a glibc sérülékeny-e.

A Red Hat most visszatért és kijelentette, hogy az érzékelő szkriptjük hibás. Ne feledje, hogy az RHEL6.6 is aggodalomra ad okot, amikor a yum –securityt a sebezhetőség javításához futtatja, mivel a https://bugzilla.redhat.com/show_bug.cgi?id=1186717 .

Megjegyzések

• A RedHat eszköz csak a glibc RPM verzióját ellenőrzi , és csak tud a RedHat verziókról (és valószínűleg derivatívákról). Valójában nem működik más operációs rendszereken.
• Ez szintén nem érhető el letölthető formában, valószínűleg a hibákhoz vezetnek.