Developpez.com

Une très vaste base de connaissances en informatique avec
plus de 100 FAQ et 10 000 réponses à vos questions

De nombreuses distributions Linux affectées par une vulnérabilité dans le système init systemd
Permettant l'exécution de code à distance

Le , 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


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de LapinGarou LapinGarou - Membre averti https://www.developpez.com
le 04/07/2017 à 14:16
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
Avatar de Toon34 Toon34 - Membre à l'essai https://www.developpez.com
le 04/07/2017 à 14:41
@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 !
Avatar de AoCannaille AoCannaille - Membre expérimenté https://www.developpez.com
le 04/07/2017 à 14:43
Citation Envoyé par LapinGarou Voir le message
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
Avatar de Aiekick Aiekick - Membre expérimenté https://www.developpez.com
le 04/07/2017 à 14:48
je me rappelle le merdier que l'integration de system D avait fait à l'époque, ils doivent bien être contant.
Avatar de Mimoza Mimoza - Membre habitué https://www.developpez.com
le 04/07/2017 à 15:15
On avait prévenu que de tout regrouper dans un seul composant c'était pas une bonne idée
Avatar de Uther Uther - Expert éminent https://www.developpez.com
le 04/07/2017 à 16:40
Citation Envoyé par AoCannaille Voir le message
é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é.
Avatar de Andarus Andarus - Membre averti https://www.developpez.com
le 04/07/2017 à 17:12
Citation Envoyé par Mimoza Voir le message
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.
Avatar de Shepard Shepard - Membre éclairé https://www.developpez.com
le 04/07/2017 à 18:34
Citation Envoyé par Uther Voir le message
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 ?
Avatar de Uther Uther - Expert éminent https://www.developpez.com
le 04/07/2017 à 18:49
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é.
Avatar de TJ1985 TJ1985 - Membre actif https://www.developpez.com
le 07/07/2017 à 8:15
A priori Pascal devrait aussi éviter ce type de problème. Mais ce n'est pas une certitude.
Offres d'emploi IT
Chef de projet SI infrastructure H/F
Michael Page - Ile de France - Aubervilliers (93300)
Administrateur dba oracle
D&B SELECTION - Provence Alpes Côte d'Azur - Nice (06000)
Administrateur systèmes et réseaux H/F
Confidentiel - Ile de France - Orsay (91400)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil