FantastIX a écrit 1338 commentaires

Il ne s'agit pas que d'un bouton poussoir ou que d'un moteur… Le tout étant interconnecté, ce projet s'inscrit dans le cadre de l'internet des objets, ce en quoi il semble des plus simples d'accès, si l'on en juge d'après les commentaires.

Bref, je crois que la plupart des libristes ont compris, et que Lennart a juste eu la mauvaise chance de devenir connu à l'aide d'une solution technique qui ne faisait pas l'unanimité et a réussit, du coup, à devenir la cible de quelques aigris qu'on trouve dans toutes les communautés.

J'aurais été entièrement d'accord avec le reste de ta réponse (qui pour moi aborde le sujet d'un ton relativement neutre que j'apprécie beaucoup) si la dernière phrase ne me choquait pas à ce point. Je ne sais pas s'il faut interpréter cette dernière comme « ce sont les aigris qui tirent à bout portant sur [Lennart Poettering] » ou autre chose que j'ai du mal à définir.

Le moins qu'on puisse dire c'est que son produit divise. Et quand la division est à ce point prononcée, il y a de quoi s'interroger, encore faut-il se poser les bonnes questions. Et classer les détracteurs de systemd dans la catégorie "râleurs" ou "aigris" est beaucoup trop facile, comme si, parce que "la critique est aisée", celle-ci devait nécessairement être non fondée.

J'utilise Gentoo depuis 2004, année où je suis passé à GNU/Linux. J'applaudis et admire profondément le choix des mainteneurs à fournir autant d'efforts pour le support des deux systèmes; ils font tout leur possible et y arrivent, tant bien que mal. Et que M. Poettering en vienne à critiquer les responsables de cette distribution me heurte profondément, pas parce que c'est ma distribution préférée mais parce que eux qui sont derrière méritent le respect de ceux qui l'utilisent au moins autant que ce… morveux semble prétendre imposer le sien… qu'il ne gagnera sûrement pas en se comportant ainsi.

Pour info, j'ai arrêté de lire son… message dès que je suis tombé sur les trucs du genre « [A] is full of [B] " avec B étant un qualificatif peu élogieux.

Bonjour.

Je ne connais pas le livre que vous référencez, ni le matériel dont il est question. Je vais plutôt détailler mon expérience personnelle.

Je me suis acheté un RaspberryPi B+ pour débuter dans l'embarqué. Je pense que c'est une manière très ludique de commencer, d'autant que l'internet fourmille d'exemples avec ce module. Et justement, le public du RaspberryPi n'est pas nécessairement composé d'électroniciens, ça se reflète dans les exemples, très bien expliqués (au moins pour ce que j'en ai lu). La platine m'a coûté environ 50€ (plus la carte micro SD de 64Go mais c'est du luxe) c'est mon seul investissement de départ. Une carte de 8 Go est un minimum. On en trouve pour quelque 10€.

Un des avantages du RaspberryPi est qu'il "suffit" d'une distribution Linux (p.ex. Raspbian) pour démarrer. Le seul matériel requis est un PC avec lecteur de carte (micro) SD, un chargeur pour téléphone avec micro-usb (comme pour les téléphones android), un câble HDMI et un clavier USB. Donc rien d'exotique.

Pour "connecter" le Pi avec le monde extérieur, une platine d'expérimentation est nécessaire, ainsi que quelques câbles avec leur connecteur individuel. Vous pourrez Pi-loter l'engin avec des script en Python, par exemple. Le Guide de Linux Pratique n°30, avec sa superbe couverture cartonnée, lui est d'ailleurs entièrement dédié et vous n'aurez qu'à suivre les instructions d'installation à la lettre pour avoir un système fonctionnel au bout de quelques minutes (tout dépendra du temps que prendra la copie du système sur la carte SD).

C'est ce que je recommanderais pour un bon démarrage.

mais bon 140 £ = 8 sams soit 180 euros je trouve cela un peu cher.

Si le projet se concrétise, il est fort possible qu'une production de masse fasse baisser les prix de manière significative. Même au stade de projet, SAM reste accessible, en tous cas.

Nathan Barry explique en quoi SAM est différent.

Pour être complet: il est impossible d'appliquer à bash la même technique de validation des données que sur un site web avec SQL en filtrant les données car, dans ce cas-ci, c'est bien le contenu (arbitraire) de la variable d'environnement qui va déclencher le problème. Mais ça, je ne l'ai pigé complètement qu'après avoir écrit ce que tu as lu plus haut.

Pour le reste, dire qu'en «poussant le raisonnement, ce serait à l'utilisateur d'éviter d'envoyer des crasses» transforme le problème parce que le raisonnement ne peut pas être poussé. En tout cas pas de cette manière là. Et de là à conclure que «la programmation défensive est inutile», c'est oublier que ce n'est pas parce qu'une solution n'est pas applicable que les autres ne le sont pas non plus. J'espère que ça répond à ta question.

Si les sophismes sont exacts, le sombre débile (moi) qui a généré ce fil s'est rendu compte plus tard de ses inepties. Donc, non, t'es pas bête et si t'as rien compris, c'est normal. Visiblement, moi non plus au départ et j'aurais mieux fait de fermer ma grande gueule. Leçon de vie.

[…] le bronsoniser, oui, mais le remplacer par quoi?

OpenRC?

Bon, d'accord.

-->[]

… car c'est un vrai démon.

-->[]

Pfff… mettre un genoux à terre, faire acte de contrition et répéter: je ne le ferai plus.

[…] puisque le problème qui nous occupe n'est pas le contenu des variables d'environnement […]

Ben si, justement. Quel con, mais quel con!

J'étoffe ma réponse-question: puisque le problème qui nous occupe n'est pas le contenu des variables d'environnement mais les crasses qui traînent après le guillemet de fermeture, un simple "parsing" des variables avant de présenter les valeurs ainsi filtrées aurait suffit à éliminer les commandes indésirables. C'est, notamment, ce que fait filter_input() en PHP avec les données en entrée, par exemple.

Je parle de sécuriser les valeurs, pas de parser des chaînes "clé=valeur".

En quoi "parser" ne répondrait pas à la question?

Tout-à-fait. De plus, c'est un porc qui pique.

Flûte…!

L'analogi*e* pas l'analogi*que*! :D

Sans bash il n'y aurait pas eu de problème […]

Faux. Il y aurait probablement eu une erreur dans les logs, éventuellement, peut-être sans conséquence apparente.

j'aimerais qu'on me montre la partie de la spec POSIX qui explique comment on "sécurise" les valeurs des variables d'environnement.

Avec une expression régulière, par exemple? Pour séparer le nom de variable de sa valeur…?

Il n'y a rien à échapper ici.

Exact. L'échappement est propre aux bonnes pratiques sur l'utilisation de SQL dans un site Web. Il ne faut pas prendre l'analogique au pied de la lettre, bien entendu.

Il ne faut pas inverser les responsabilités : c'est bien à bash de s'assurer qu'il n'introduit pas des comportements non spécifiés ;

Il ne s'agit pas d'inverser les responsabilités. La responsabilité porte, d'une part, sur bash, qui ne se conforme pas à son API, comme expliqué mais aussi sur les programmes, d'autre part, qui se contentent de passer des données non validées à bash. Ne porter son attention que sur le côté bash revient à masquer l'autre partie du problème.

Si on pousse votre raisonnement, ce n'est pas au site d'échapper ses entrées mais à l'utilisateur de ne pas envoyer de saloperie.

Faux. Sophisme, faux dilemme.

La conclusion est donc que la programmation défensive ça sert à rien […]

Faux. Autre sophisme, épouvantail.

Merci beaucoup!

Le journal est ici.

Merci pour le conseil. C'est par manque de familiarité avec la rédaction de contenu, essentiellement. Je me disais tout simplement que les petites annonces convenaient mieux. C'est possible de transformer cette annonce en journal?

Pour moi ce n'est pas très clair: est-ce que l'exécution du code après la définition de la fonction était voulu ?

Je pense que le problème va au-delà de ça. Ce n'est pas tellement bash qui pose problème (je me marre en lisant les trolls plus haut) et je dirais même que le travail des équipes de RedHat autour de bash est admirable parce que ce que la faille démontre est rien moins que passer des données sans les vérifier, c'est mal. Ce que je vois ici c'est le rôle des passe-plats, qui se bornent à positionner des variables d'environnement sans valider les données qu'ils transmettent. Un peu comme Ponce Pilate. (Bon, mais de la à dire que bash, c'est le petit Jésus, y a un pas, quand-même, hein.)

Fais pareil avec un site web, ça donne une magnifique porte d'entrée par injection (SQL ou autre). J'affirmerais même que ce n'est théoriquement pas à bash de rectifier le tir mais, comme il se trouve en première ligne et que c'est sur lui que la patate chaude retombe, il est le dernier maillon de la chaîne à pouvoir encore faire quelque chose. En fait, ce serait plutôt aux équipes derrière postfix, apache, moteurs CGI et consorts de corriger leur… brol et de vérifier les données qui leur parviennent avant d'altérer l'environnement.

Mais bon, le rôle du shell ici est primordial et c'est un peu grâce à lui qu'on peut voir que les mauvaises pratiques ne se tiennent pas toujours là où elles sont les plus évidentes. Avec un autre shell le vrai problème aurait tout simplement masqué. (Voix off: « De grands pouvoirs impliquent de grandes responsabilités. ») Au moins bash a pu mettre un gros problème en évidence et peut-être pas dans son propre code…

Further flaws render Shellshock patch ineffective

Même après application des correctifs, les systèmes demeureraient vulnérables. À confirmer, j'imagine.

Merci pour ces explications. Cette faille était pour moi assez subtile car je ne suis encore jamais (volontairement) "tombé" sur un tel cas de figure; même s'il m'est arrivé d'installer des services potentiellement vulnérables à la faille (comme OpenVPN et postfix), je n'ai jamais pris la peine d'aller observer l'impact (à ce point) sur les variables d'environnement. Rien n'est jamais vraiment acquis, quoi ;-) .

[…] je ne suis pas sûr qu’une comparaison soit pertinente.

C'est bien ce que je pensais.

Ok, je me réponds à la première partie de ma question: c'est bien l'exécution du code arbitraire qui suit la fonction qui cause la faille. Je comprends maintenant la faille à travers l'exemple d'exécution de scripts CGI où l'environnement est modifié par le serveur HTTP, qui retranscrit directement dans l'environnement des paramètres provenant du navigateur. Je vois bien l'impact du passe-plats. Donc, en modifiant la chaîne USERAGENT côté client, on peut arriver à exécuter des commandes arbitraires sur le serveur web. (Je réfléchis tout haut, là :D.)

Merci au lien vers le blog de Dan Walsh. Ce n'est pas expliqué là-dedans mais un peu plus loin via un lien vers reddit: http://www.reddit.com/r/netsec/comments/2hbxtc/cve20146271_remote_code_execution_through_bash/ .

… il y a quand même quelque chose que j'ai du mal à comprendre. D'abord, j'ai vu que la correction consistait à empêcher de définir du code après la fonction, comme ceci:

env mafonction='() { echo "bonjour vous"; }; echo "voici shellshock"'

ce qui doit donner un message d'erreur. Jusque là, d'accord. Mais ce que j'ai du mal à saisir, c'est: pourquoi cette tournure est dangereuse? Bon, hormis le fait que c'est une construction douteuse, qu'est-ce qui fait que

env mafonction='() { echo "bonjour vous"; }; <code malfaisant>' ...

est plus dangereux que

env mafonction='() { echo "bonjour vous"; <code malfaisant>; }' ...

? Est-ce que ça tient de l'exécution, que j'appellerais non gardée, du code malfaisant dans le premier cas?

J'ai aussi du mal à concevoir en quoi cette… "faille" serait plus conséquente que HeartBleed étant donné que tout code arbitraire ne peut que se dérouler avec les privilèges du compte sous lequel le processus appelant s'exécute, exact?

Si quelqu'un veut bien éclairer ma lanterne, ce serait très gentil.

est-t'on vraiment en démocratie?

Suffit de comparer: dans une démocratie, le peuple vote les lois.