Developpez.com

Le Club des Développeurs et IT Pro

De nombreuses distributions Linux affectées par une vulnérabilité dans le système init systemd

Permettant l'exécution de code à distance

Le 2017-07-04 13:59:35, par Michael Guilloux, Chroniqueur Actualités
Chris Coulson, développeur de Canonical, a récemment découvert une faille dans systemd, le système init utilisé dans de nombreuses distributions Linux pour démarrer et gérer des processus. La vulnérabilité réside dans le daemon systemd-resolved. Et elle peut être exploitée à l'aide d'une requête DNS malveillante pour permettre à un attaquant de bloquer un système ou exécuter un code à distance.

D’après Chris Coulson, ce problème a été introduit dans le code de systemd en juin 2015, dans la version v223. Elle affecte donc la version v223 de systemd ainsi que les versions plus récentes. Les versions affectées permettent à un attaquant d'allouer une petite taille de tampon au traitement des paquets DNS. « Un serveur DNS malveillant peut l'exploiter en répondant avec une charge utile TCP spécialement conçue pour tromper Systemd-resolved en allouant un tampon trop petit et ensuite écrire des données arbitraires [en dehors de la zone de tampon allouée] », explique Coulson.

Certains fournisseurs de distributions Linux ont déjà commencé à réagir après cette alerte. C’est le cas par exemple de Canonical qui a publié des mises à jour pour Ubuntu 16.10 (Yakkety Yak) et 17.04 (Zesty Zapus) pour protéger ses utilisateurs. Red Hat a également fait savoir que la vulnérabilité n’affecte pas les versions de systemd utilisées avec Red Hat Enterprise Linux 7.

Pour sa part, l’équipe Debian a déclaré que sa dernière mouture (Debian 9 Stretch) embarque une version vulnérable de systemd, mais le service systemd-resolved où se trouve le bogue n'est pas activé par défaut. Ainsi, ses utilisateurs sont protégés à moins qu'ils aient manipulé les paramètres systemd. Debian doit donc encore publier un correctif pour Stretch. Les versions antérieures comme Jessie et Wheezy, quant à elles, ne contiennent pas le code vulnérable.

Sources : Chris Coulson, Canonical, Red Hat, Debian

Et vous ?

Qu'en pensez-vous ?

Voir aussi :

Linux : une faille de sécurité a été détectée dans sudo, mais a déjà été corrigée sur Red Hat, SUSE et Debian
Stack Clash : les systèmes Linux et BSD affectés par une vulnérabilité de dépassement de pile mémoire, permettant une élévation de privilèges
  Discussion forum
14 commentaires
  • AoCannaille
    Expert confirmé
    Envoyé par LapinGarou
    Alors ?! Ils sont où les pro linux qui certifient qu'il n'y a que Microsoft qui a des problèmes avec son OS "tout pourri" ? Pas de commentaire ?
    C'est en ne faisant rien qu'on ne commet pas d'erreur
    Tu ne leur laisse pas le temps de réagir ;-)

    De manière parfaitement objective :
    - La faille à moins de deux ans (comparé à certaines failles de plus de 20 ans sur windows)
    - La faille a été repéré grâce au concept de sources publiques. Corollaire direct : le type de faille et sa correction sont publiques et peuvent servir à la formation (alors que les failles et corrections faites par ms sont privées ==> Erreurs reproductibles)
    - La faille est déjà corrigé dans une partie des systèmes impactés et les suivants ne vont pas tarder. (temps de réaction < 1 mois, comparé aux 3 mois de marge que donne google à MS et que MS n'arrive pas à suivre.)

    évidement, il y a des axes d'améliorations classiques:
    - Relecture plus attentive du code avant de pousser la correction
    - Augmentation de la qualité des Test unitaires
    le 04/07/2017 à 14:43
  • Uther
    Expert éminent sénior
    Le typage peut être bien pour éviter certaines erreurs, mais en l’occurrence, ça n'est pas le problème. Cette faille est a la base un banal dépassement de tampon, un grand classique du C/C++. A peu près tous les langages modernes interprétés et/ou managés empêchent les dépassement de tampons.
    C'est plus rare pour les langages de bas niveau, mais il y en a quand même qui protègent contre ça comme Ada ou Rust.

    Après non, ça ne serait probablement pas détecté à la compilation (quoique peut-être avec Ada). Mais au moins, ça planterait proprement à l'exécution sans ouvrir de faille de sécurité.
    le 04/07/2017 à 18:49
  • Toon34
    Membre à l'essai
    @LapinGarou : Joli Troll 6/10 (pas plus car un peu trop gros quand même)!

    Dans la même veine, les détracteurs de systemd vont s'en donner à cœur joie !

    Pour ma part, je suis content d'avoir cette "transparence" et cette réactivité sous linux.

    Puis la PoC doit pas être à la portée du premier venu !
    le 04/07/2017 à 14:41
  • Uther
    Expert éminent sénior
    Envoyé par AoCannaille
    évidement, il y a des axes d'améliorations classiques:
    - Relecture plus attentive du code avant de pousser la correction
    - Augmentation de la qualité des Test unitaires
    On peut aussi, utiliser des langages qui empêchent que ce genre d'erreur se transforme en faille de sécurité.
    le 04/07/2017 à 16:40
  • Andarus
    Membre confirmé
    Envoyé par Mimoza
    On avait prévenu que de tout regrouper dans un seul composant c'était pas une bonne idée
    c'est vrai mais c'est vrai pour tout.
    Si tout le monde partage le même noyaux linux quand il y a un problème dedans le problème et partagé par tout le monde.
    Si tu fais le tiens il y aura que toi pour voir qu'il y a un problème dedans.
    le 04/07/2017 à 17:12
  • Mimoza
    Membre averti
    On avait prévenu que de tout regrouper dans un seul composant c'était pas une bonne idée
    le 04/07/2017 à 15:15
  • Shepard
    Membre expérimenté
    Envoyé par Uther
    On peut aussi, utiliser des langages qui empêchent que ce genre d'erreur se transforme en faille de sécurité.
    Je veux bien des détails sur le genre de langage auquel tu penses

    Un langage basé sur les types qui fait que ce genre d'erreur est détecté à la compilation ?
    le 04/07/2017 à 18:34
  • TJ1985
    Membre chevronné
    A priori Pascal devrait aussi éviter ce type de problème. Mais ce n'est pas une certitude.
    le 07/07/2017 à 8:15
  • esxpro
    Nouveau Candidat au Club
    il suffit de remplacer le service incriminé par un autre ... dnsmasq par exemple
    le 07/07/2017 à 12:36
  • Blackknight
    Membre averti
    Après non, ça ne serait probablement pas détecté à la compilation (quoique peut-être avec Ada). Mais au moins, ça planterait proprement à l'exécution sans ouvrir de faille de sécurité.
    En Ada, dès le départ, on éviterait de faire appel à trop de pointeurs comme on peut le voir en C. Il est tout à fait possible d'écrire un programme entier sans en utiliser d'ailleurs.
    Après, si vraiment on veut en utiliser, on les encapsulerait pour éviter d'avoir à les manipuler partout. Et puis, il ne faut pas oublier qu'en Ada, il n'y a pas d'arithmétique de pointeur, que de base, les types de pointeurs sont incompatibles entre eux, qu'il ny a pas de cast implicite et que les cast explicites sont très encadrés.
    Donc déjà, faire un programme dans la même veine que systemd avec la même conception mais en Ada relèverait du challenge, ne serait-ce que pour passer la compilation
    Il y a quelques années, pour ceux qui voulaient un DNS qui n'avait pas de failles, j'aurais conseillé Ironsides, un serveur DNS écrit en Spark
    Bon, compte tenu des évolutions sur Spark ces dernières années, je suis sûr qu'il ne compile plus avec les versions récentes de chez Adacore
    le 08/07/2017 à 10:30
  Poster une réponse