GHOST ( CVE- 2015-0235 ) vient dapparaître. Comment puis-je vérifier rapidement si un de mes systèmes est sécurisé? Idéalement avec une commande shell sur une seule ligne.
Selon larticle de ZDNet « vous devriez alors redémarrer le système ». Idéalement, le test indiquerait également ceci …
Commentaires
- Je suggère de promouvoir en » question canconique »
- Excellente question. Dommage que vous ayez accepté une réponse qui, loin dêtre une commande shell en une ligne, nécessite linstallation dune chaîne doutils complète pour les développeurs. Les périphériques critiques comme les routeurs nont généralement ‘ pas gcc. Certains appareils peuvent ‘ être même auto-hébergés.
- Vous ‘ avez droit à @BenVoigt. Jai mis en place une prime pour une réponse avec une seule ligne qui ne ‘ pas besoin doutils de développement.
- Sur un appareil qui peut ‘ t self-host, uClibc et dietlibc sont beaucoup plus probables que la glibc. Assurez-vous que ‘ fonctionne bien sur la glibc avant de faire glisser le compilateur croisé.
Réponse
Il semble que vous puissiez télécharger un outil de lUniversité de Chicago qui vous permettra de tester votre système pour la vulnérabilité .
Cela ne répare ni ne redémarre rien il vous dira seulement si votre système est vulnérable.
$ wget https://webshare.uchicago.edu/orgs/ITServices/itsec/Downloads/GHOST.c $ gcc GHOST.c -o GHOST $ ./GHOST [responds vulnerable OR not vulnerable ]
En exécutant ceci sur lun de mes serveurs distants, jobtiens:
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
Le le code source de ce script ressemble à ce bloc de code suivant mais vous devez quand même inspecter le code dorigine en premier . Comme dautres lont souligné, si vous exécutez arbitrairement du code sur Internet sans savoir ce quil fait, de mauvaises choses peuvent se produire :
/* * 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); }
Modifier : jai ajouté un playbook ansible ici sil est utile à quiconque, si vous en avez un grand nombre de systèmes à tester ensuite ansible vous permettra de le faire rapidement.
De plus, comme indiqué ci-dessous, si vous trouvez que vos serveurs sont vulnérables et que vous appliquez les correctifs disponibles, il est fortement recommandé de redémarrer votre système .
Commentaires
- @KasperSouren Eh bien, oui. Sil est vulnérable, appliquez le correctif / la mise à jour et redémarrez.
- @KasperSouren Ce que vous ‘ demander est franchement un peu idiot. Cette réponse répond parfaitement à votre question: comment détecter cette vulnérabilité. Cest ‘ que cest tout ce que vous avez demandé. Demander un » une doublure » est également un peu idiot. Jai effectué le test quil a posté ici sur tous mes serveurs en moins de 2 minutes. Cest ‘ que cest simple. » arrêtez -r maintenant » après ‘ terminé ….. ..
- Jai mis à niveau, exécuté le test, ‘ t redémarrer. Je ny suis revenu que lorsque jai découvert que je devais redémarrer. Cela peut arriver à un certain nombre de personnes et leurs serveurs peuvent être vulnérables et être piratés malgré leur faux sentiment de sécurité. Donc pas si idiot de clarifier les choses si possible IMHO.
- Le
GHOST.c
POC provient de le Qualys original conseil . - @KasperSouren un test peut vous dire que les nouveaux programmes utiliseront une version sûre de la glibc. Cependant, il se peut que vous ayez des programmes exécutés en arrière-plan qui ont démarré avant la mise à niveau et ont donc chargé lancienne version.
Réponse
PHP one-liner:
php -r "$e="0";for($i=0;$i<2500;$i++){$e="0$e";gethostbyname($e); }"
Python one-liner:
python -c "import socket;y="0"*50000000;socket.gethostbyname(y)"
Si ceux-ci vous donnent des segfaults (oui, un segfault Python, un spécimen rare) alors vous « êtes vulnérable. Je ne sais pas si vous considérez Python comme un » outil de développement « mais PHP est un programme commun à avoir.
Si le périphérique cible est un routeur, je ne sais rien de ce que vous pourriez faire sur celui-ci qui vous dirait, à part creuser dans les spécifications du fabricant et / ou attendre les avis du fabricant et les mises à jour du micrologiciel.
Commentaires
- Est-il possible de combiner cela avec
sudo lsof | grep libc- | grep DEL"
? Fourni dans un autre commentaire, pour éviter cela les gens pensent quils ‘ sont en sécurité tant que lancienne libc est encore utilisée. Avec cet ajout, je ‘ donnerai la prime tout de suite. - Il ‘ est une commande shell, vous pouvez donc ajouter des éléments avec & &. Et cette commande est seulement après que vous ayez mis à jour vos paquets glibc.Si vous ‘ avez mis à jour, ces doublures échoueront. Alors bourrez votre vommamd de mise à jour entre les deux?
- Jai utilisé le php sur SUSE 11SP3, et je nai vu aucun segfault avant ou après le patch. Des idées?
- @marcin Cela ‘ est intéressant. Je les ai tirés de sources Internet, et beaucoup de gens signalent des erreurs de segmentation. Augmenter le nombre de boucles fait-il quelque chose? (Pour ce que cela vaut ‘, le segfault pour Python segfault sur certains systèmes patchés aussi … aucun mot sur pourquoi cela ‘ Cela se passe.)
- En jouant avec le code uchicago, il semble que si vous essayez de déborder de plus de 4 octets environ, gethostbyname () renverra une erreur (EINVAL) au lieu de déborder. Avec C, vous pouvez contrôler exactement ce qui est écrasé. Avec PHP ou Python, ce qui est écrasé peut être important et segfault, ou ce peut être rien; il ‘ dépendra de la construction exacte du système. Et le segfault Python sur
gethostbyname("0"*50000000)
ressemble plus à un bogue en Python pour moi. (Ghost Python?)
Réponse
La réponse de aaronfay a déjà été abordée pour déterminer si votre système sous-jacent est vulnérable, mais il ne détecte pas si des programmes sont toujours en cours d exécution en utilisant l ancienne version de la glibc après la mise à niveau. Autrement dit, vous pouvez mettre à niveau sans redémarrer les processus affectés, et le script signalera « non vulnérable » même si lancienne bibliothèque vulnérable est toujours utilisée.
Voici une façon de vérifier sil y en a programmes liés dynamiquement utilisant toujours lancienne version de la glibc:
sudo lsof | grep libc- | grep DEL
Sil y a des résultats, des versions supprimées de la glibc sont en cours dutilisation, et les processus les utilisant peuvent être vulnérable.
Bien sûr, cela ne couvre pas le cas où la glibc était liée statiquement. La bonne (?) nouvelle est quil est très rare de trouver la glibc liée statiquement dans un binaire, à la fois parce que de la taille, et parce quil présente quelques autres désagréments et difficultés. Dans le cas où vous avez des programmes utilisant une glibc compilée statiquement (ce que vous n’avez presque certainement pas), vous devrez les recompiler.
Commentaires
-
lsof +c0 -f -- /usr/lib64/libc-*.so | grep "(deleted)$"
un peu plus précis, vous montre les noms complets des processus et recherche des liens vers les fichiers qui ont été supprimés.
Réponse
Si vous avez un compte à Redhat, vous pouvez accéder à leur « détecteur GHOST » à cette URL . Cest un petit script shell qui vous dira si votre glibc
est vulnérable.
Red Hat est maintenant revenu et ont déclaré que leur script de détection était défectueux. Notez quil existe également un problème sur RHEL6.6 lors de lutilisation de yum –security pour corriger la vulnérabilité car elle a été manquée selon https://bugzilla.redhat.com/show_bug.cgi?id=1186717 .
Commentaires
- Loutil RedHat vérifie uniquement la version du RPM glibc , et cela seulement connaît les versions de RedHat (et probablement ses dérivés). Il ne fonctionne en fait sur aucun autre système dexploitation.
- Ce nest également plus disponible au téléchargement, probablement pour les failles.