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

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

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 ?

:fleche: Qu'en pensez-vous ?

Voir aussi :

:fleche: 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
:fleche: 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

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 :)

@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 !

Citation:

---

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

je me rappelle le merdier que l'integration de system D avait fait à l'époque, ils doivent bien être contant.

On avait prévenu que de tout regrouper dans un seul composant c'était pas une bonne idée :whistle2:

Citation:

---

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é.

Citation:

---

Envoyé par Mimoza

On avait prévenu que de tout regrouper dans un seul composant c'était pas une bonne idée :whistle2:

---

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.

Citation:

---

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 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é.

A priori Pascal devrait aussi éviter ce type de problème. Mais ce n'est pas une certitude.

il suffit de remplacer le service incriminé par un autre ... dnsmasq par exemple

Citation:

---

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 :D
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 ;)

Qu'en est-il de Tails ?

Pareil, Tail est une base Debian.