IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

333PARTAGES

8  0 
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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de AoCannaille
Expert confirmé 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
9  1 
Avatar de Uther
Expert éminent sénior 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é.
7  0 
Avatar de 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 !
7  1 
Avatar de Uther
Expert éminent sénior 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é.
4  0 
Avatar de Andarus
Membre confirmé 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.
3  0 
Avatar de Mimoza
Membre averti 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
5  3 
Avatar de Shepard
Membre expérimenté 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 ?
1  0 
Avatar de TJ1985
Membre chevronné 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.
0  0 
Avatar de esxpro
Nouveau Candidat au Club https://www.developpez.com
Le 07/07/2017 à 12:36
il suffit de remplacer le service incriminé par un autre ... dnsmasq par exemple
0  0 
Avatar de Blackknight
Membre averti https://www.developpez.com
Le 08/07/2017 à 10:30
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
0  0