Une sérieuse faille dans la glibc de linux

  • Initiateur de la discussion Initiateur de la discussion Hibou57
  • Date de début Date de début
Hibou57

Hibou57

Comme-même (tm)
VIB
C’est une faille nommé GHOST, parce que son exploitation passe par l’appel de la fonction standard gethostbyname. Elle a été annoncée le 27 Janvier 2015. C’est tout récent.

Pour savoir si votre machine de bureau ou votre serveur est vulnérable, et pour plus de détails, voir cet article : How To Patch and Protect Linux Server Against the Glibc GHOST Vulnerability # CVE-2015-0235 (cyberciti.biz), 28 Janvier 2015.

Je rapporte une liste des versions d’environnements impactés :
  • RHEL (Red Hat Enterprise Linux) version 5.x, 6.x and 7.x
  • CentOS Linux version 5.x, 6.x & 7.x
  • Ubuntu Linux version 10.04, 12.04 LTS
  • Debian Linux version 7.x
  • Linux Mint version 13.0
  • Fedora Linux version 19 or older
  • SUSE Linux Enterprise 11 and older (also OpenSuse Linux 11 or older versions).
  • SUSE Linux Enterprise Software Development Kit 11 SP3
  • SUSE Linux Enterprise Server 11 SP3 for VMware
  • SUSE Linux Enterprise Server 11 SP3
  • SUSE Linux Enterprise Server 11 SP2 LTSS
  • SUSE Linux Enterprise Server 11 SP1 LTSS
  • SUSE Linux Enterprise Server 10 SP4 LTSS
  • SUSE Linux Enterprise Desktop 11 SP3
  • Arch Linux glibc version <= 2.18-1
Notez que plusieurs versions de serveurs apparaissent dans cette liste…

Il y a malheureusement ma version, Ubuntu 12.04 LTS :( . Normalement il devrait y avoir une mise à jours de la (E)GlibC ?

Je lis le reste de l’article.
 
Hibou57 a dit:
Il y a malheureusement ma version, Ubuntu 12.04 LTS :( .
Cliquez pour agrandir...
Ouf, … non. La mise à jour est peut‑être déjà passée sans que je ne l’ai noté. Je viens de compiler et lancer le petit programme de test (rapporté plus bas), et le résultat “not vulnerable”.

C: 
/* ghosttest.c:  GHOST vulnerability tester */
/* Credit: http://www.openwall.com/lists/oss-security/2015/01/27/9 */
#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);
}
 
Sous FreeBSD qui n'utilise pas glibc, je recois "should not happen", avec une valeur de retval == 0. FreeBSD libc n'est apparament pas vulnerable (mon systeme de test n'a pas encore ete upgraded cette annee). Enfin, je l'espere. Je vais quand meme verifier le code plus tard.
 
farid_h a dit:
Sous FreeBSD qui n'utilise pas glibc, je recois "should not happen", avec une valeur de retval == 0. FreeBSD libc n'est apparament pas vulnerable (mon systeme de test n'a pas encore ete upgraded cette annee). Enfin, je l'espere. Je vais quand meme verifier le code plus tard.
Cliquez pour agrandir...
Via gethostbyname() or gethostbyname2(), the overflowed buffer is located in the heap. Via gethostbyname_r() or gethostbyname2_r(), the overflowed buffer is caller-supplied (and may therefore be located in the heap, stack, .data, .bss, etc; however, we have seen no such call in practice).
Cliquez pour agrandir...
Tu es peut‑être dans ce second cas.
 
Apparemment il n’y a pas de system call équivalent à cette fonctionalité. J’ai voulu chercher, pour voir si ce type de problème peut être évité en passant directement par le noyau au lieu de passer par la LibC.
 
phil@yoshi:/tmp$ gcc code.c -o code
phil@yoshi:/tmp$ ./code
not vulnerable
phil@yoshi:/tmp$ cat /etc/issue
LMDE Cinnamon Edition
 

Pièces jointes

  • Capture du 2015-02-06 22:19:00.png
    Capture du 2015-02-06 22:19:00.png
    18 KB · Affichages: 4
c'est chaint quand tu as une application high-availability qui roule sur l'un des systemes mentionnes, un init-6 est necessaire et pas sur que le systeme remonte adequatement :fou:
 
FqihZgandaf a dit:
c'est chaint quand tu as une application high-availability qui roule sur l'un des systemes mentionnes, un init-6 est necessaire et pas sur que le systeme remonte adequatement :fou:
Cliquez pour agrandir...
Alors vérifie que c’est vraiment nécessaire, avant de faire quoique ce soit. Un petit programme de test en C, a été posté. Le lien de son origine est donné dans le commentaire d’entête.
 
@farid_h heureusement il y a des blades en masse derriere une VIP, il suffit de sortir une a une a chaque intervention, faire le changement, rebooter, faire un health check profond avant de les remettre dans la ferme.

@Nalinux la config a change au fil des ans, puis tu ne sais jamais par exemple si une personne pour regler un probleme de connectivite IP s'il a juste ajouter les routes avex du "ip route add..." sans les configurer de maniere persistente sur la bonne interface... ou le service snmp qui ne part pas de maniere normale... y en a tellement des cas de figures tu sais...
trust nobody quand c'est pas toi qui a livre la bidule from day 1 :-)

@Hibou57 helas deja verifie que c'est necessaire, on prend notre temps avant de regler ca pour cerner tt les cas de figures
 
Retour
Haut