« ShellShock », une faille dans l'usage du shell Bash, est sous les projecteurs depuis quelques jours. Le terme est un jeu de mot entre la stupeur propre à l'obusite des combattants de la première guerre mondiale et l'interface système shell. Nous vous proposons des explications sur cet évènement particulier, son périmètre, les conditions de son exploitation, les surfaces d'attaques, et les solutions proposées, déjà mises en œuvre ou à venir. Enfin, une revue de presse sera dressée, cette faille s'étant transformée en évènement.
Sommaire
- Contexte et histoire
- Quelques explications
- Surfaces d'attaques et exploitabilité
- Chronologie des évènements
-
Solutions mises en œuvre
-
Correctifs disponibles et annonces des distributions
- La faille, CVE-2014-6271
- Le second problème, CVE-2014-7169
- Les CVE-2014-6277, CVE-2014-7186 et CVE-2014-7187 ne sont pas publics à ce jour (infos chez Redhat 0, 1 et 2).
- mod_security, le filtrage
- Le cas FreeBSD
-
Correctifs disponibles et annonces des distributions
- Revue de presse
- Conclusion
Contexte et histoire
Bash est l'interpréteur par défaut du projet GNU, c'est une amélioration du Shell Bourne, reprenant des idées du Korn Shell (ksh). Il est développé depuis 1988 et n'a cessé de s'améliorer.
Bash est le shell par défaut d'un grand nombre de distributions GNU/Linux, mais pas toutes. Par exemple Ubuntu ne lance pas Bash avec son /bin/sh, mais dash, Bash n'étant disponible que pour l'utilisateur en session interactive. Bash se retrouve également dans Apple Mac OS X et dans Microsoft Windows via Cygwin (SFU, Services for Unix, utilise csh ou ksh).
Quelques explications
Il s'agit d'exploiter un bash-isme, une spécificité du shell Bash, permettant d'exporter une fonction et non seulement une variable. Les autres shells (ksh, zsh, dash, …) ne sont pas concernés par cette faille. Par ailleurs, Bash ne permet pas cet export de fonctions s'il est utilisé avec l'option -p ).
Il est tout à fait normal de vouloir passer des variables d'environnement à un processus enfant.
Mais Bash permet en outre de passer des fonctions vers le processus enfant. Aucun autre shell ne permet cela. Dans ce cadre relativement strict, la sécurité ne pose pas de problème : les droits et contextes d'exécution sont identiques et l'utilisateur, système ou non, est le même. Ceci est documenté, il s'agit de l'option -f de la commande export dans le shell Bash. « It is not a bug, it is a feature », le vieil adage prend ici tout son sens. Nous laissons le lecteur seul juge du bien-fondé de ce bashisme.
Alors s'il n'y a pas de problème, où est le problème ? Le problème se situe dans l'usage de Bash par les autres programmes. Bash est devenu le shell par défaut de certaines distributions, et de nombreux programmes utilisent le shell par défaut pour passer des variables d'environnement entre leurs processus. Le contexte change donc : ce n'est plus un utilisateur local et de confiance qui utilise cela, mais une multitude de programmes, parfois distants.
Ces programmes ne valident pas eux mêmes les données qu'ils donnent à Bash, et ne font souvent que passe-plat. Dans ce contexte, ce qui était auparavant une fonctionnalité se transforme alors en faille. Ceci explique l'ancienneté du problème.
Explications techniques
Une fonction dans le shell bash
#!/bin/bash
# déclaration de la fonction d'affichage du message "bonjour vous", nommée mafonction :
mafonction() {
echo "bonjour vous";
}
# exécution de la fonction :
mafonctionLa même chose, pour passer la fonction à un sous-shell
env mafonction='() { echo "bonjour vous"; }' bash -c 'mafonction;'
On prefixe avec la commande env pour faire tourner un programme dans un environnement modifié. Et à la fin on fait exécuter la fonction par un autre bash. OK ?
La même chose, en détournant l'usage
env mafonction='() { echo "bonjour vous"; }; echo "voici shellshock"' bash -c "mafonction;"
Ici, l'exécution de la fonction mafonction ne se limite pas à un écho "bonjour vous", mais exécute aussi le code echo "voici shellshock" On notera la place du délimiteur '
OK ?
Et en fait il n'est même pas nécessaire d'exécuter la fonction définie :
env mafonction='() { echo "bonjour vous"; }; echo "voici shellshock"' bash -c "true"
voici shellshock
Donc, le simple () { :;} suffit à résumer la situation.
OK !
Surfaces d'attaques et exploitabilité
Les conditions de l'exploitation à distance de la faille sont relativement simples :
-
/bin/shpointe sur/bin/bash; - avoir SELinux désactivé ou non configuré ;
- avoir un service qui écoute le réseau et qui va exécuter
bash.
L'exploitation de cette faille est très simple, et de nombreux preuves de concepts et exploits circulent actuellement sur Internet. Voici une liste non-exhaustive des logiciels qui peuvent être utilisés en passe-plat :
- dhclient ;
- apache, via mod_cgi (et sans mod_security correctement configuré) ;
- exim ; postfix ; qmail ; procmail ;
- OpenVPN ;
- stunnel ;
- probablement de très nombreux logiciels privateurs …
- SIP, FTP, probablement d'autres …
Preuves de Concept
Un projet hébergé sur github rassemble une série de POC à cette adresse
À noter que SELinux ne va pas bloquer un usage de « shellshock », il va cependant en réduire fortement les possibilités d'exploitation. Par exemple le contexte httpd_sys_script_t est attribué à tout CGI, contexte qui ne permet l'écriture que dans … /tmp! Le lecteur trouvera des explications complètes sur le blog de Dan Walsh à ce sujet.
Ne sont donc pas concernées : toutes les distributions ayant un autre shell que Bash. Toutes les distributions ayant SELinux activé bénéficient d'une protection contre des exploitations de ce type. Mais également : tous les matériels embarqués et objets connectés, contrairement à ce que des articles de presse affirment, car ces matériels utilisent la plupart du temps busybox et son implémentation inline de Bash n'est pas vulnérable. Ne sont pas concernés non plus les téléphones portables (pas plus les Android que les iPhones). Les "box" internet ne le sont pas davantage, ni les télévisions, ni les lecteurs de salon, les autoradios, ni les avions, drones, missiles, sous-marins… Bref, nous avons eu le plaisir de lire un peu n'importe quoi sur le sujet et la revue de presse contient quelques jolies perles.
NdM : le fabriquant de NAS QNAP vient d'alerter ses utilisateurs (cf article Next INpact)
Chronologie des évènements
- Stéphane Chazelas rapporte le problème à Redhat (bug déclaré le 14 septembre) ;
- Le CVE-2014-6271 lui est attribué ;
- Le 24 septembre, ce CVE est rendu public et un premier correctif est mis à disposition ;
- Le jour même la communauté pointe l'insuffisance de ce correctif ;
- Le CVE-2014-7169 est alors ouvert et attribué à Tavis Ormandy ;
- Le 27 septembre le second correctif est publié
Solutions mises en œuvre
Correctifs disponibles et annonces des distributions
La faille, CVE-2014-6271
Le test :
env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"Ne doit pas retourner le terme "vulnérable", quelque soit le formattage retour.-
Les annonces :
Le second problème, CVE-2014-7169
Le test :
cd /tmp; rm -f echo; env 'x=() { (a)=>\' bash -c "echo date"; cat echodoit retourner que le fichier "/tmp/echo" n'existe pas.-
Les annonces :
Les CVE-2014-6277, CVE-2014-7186 et CVE-2014-7187 ne sont pas publics à ce jour (infos chez Redhat 0, 1 et 2).
- D'autres correctifs sont à venir.
mod_security, le filtrage
Mod_security est un pare-feu applicatif pour le serveur Apache. Il peut être configuré pour filtrer certains caractères et expressions régulières. C'est donc un moyen efficace pour se prémunir contre le principal vecteur d'attaque : les scripts CGI. Si vous utilisez Redhat, vous pouvez l'installer ou le mettre à jour : il contient les règles tout prêtes pour filtrer « shellshock ». Ces règles sont de types : SecRule REQUEST_HEADERS "^\(\) {" & request_line.
Le cas FreeBSD
Le projet FreeBSD a décidé de désactiver la possibilité d'importation de fonction de Bash. Le système FreeBSD n'utilise pas Bash comme shell par défaut, mais tcsh, Bash n'étant même pas inclus dans une installation de base. Mais pour prémunir de tout problème lié à un changement de shell par défaut, le projet a décidé de supprimer la fonctionnalité incriminée, avec ce message laconique : « cela retire le risque de nouveaux problèmes conduisant à l’exécution de code, et le risque pour les scripts suid, aussi pour les applications mal écrites qui ne nettoient pas leurs environnements » Radical.
Revue de presse
Après les annonces sécurité et la réaction des projets (Bash, FSF - traduite en français par l'April), la presse spécialisée puis la presse généraliste ont multiplié les articles : pire que la faille Heartbleed ? (Slate.fr, LMI, Silicon.fr, L'Express, 20minutes, HuffingtonPost, New Zealand Herald), « panique » (Courrier International), « mégafaille » (01Net), « horrible » (ZdNet), « premières attaques » (01net), « plus grande menace de l'histoire du web » (ParisMatch, si si), « 500 millions de serveurs web vulnérables » (La Tribune, Washington Post), « Google et Amazon ont patchés » - super on est sauvés alors - (WallStreetJournal), d'autres failles Bash à prévoir (ArsTechnica), « ver fou ShellShock » (Wired ou le blog de R. Graham), « internet bâti sur de la glace fine » (Financial Times), etc.
Conclusion
D'une rencontre entre une fonctionnalité et des usages nait une faille qui fait grand bruit. Bruit généré par l'importance du problème, certes, mais également par le manque de discernement et le FUD autour. Ce qui met en valeur la place qu'ont pris les Logiciels Libres dans nos vies quotidiennes, sans que cela se voie. Il aura fallu moins de 4 jours entre la publication du problème (à ne pas confondre avec le signalement initial aux équipes sécurité) et sa résolution. Peu d'éditeurs peuvent se targuer d'être aussi rapides sur la résolution d'un problème de ce type et sur la transparence pour l'accès à l'information.
Dans le même temps, l'inquiétude de savoir que cette possibilité existe depuis de nombreuses années est légitime. Et elle renforce la nécessité de participation. Combien d'éditeurs de solutions s'appuient sur des briques libres sans jamais rien verser aux projets ?
Mettez et maintenez vos systèmes à jour! Et ne pensez pas qu'un programme qui n'a pas connu beaucoup de failles est forcément très sûr, peut-être que personne ne l'avait vraiment regardé jusque là.
Aller plus loin
- Redhat : Frequently Asked Questions about the Shellshock Bash flaws (493 clics)
- Redhat : Bash specially-crafted environment variables code injection attack (197 clics)
- Annonce initiale sur la liste Open Source Security (148 clics)
- CERTFR-2014-ALE-006 : Vulnérabilité dans GNU bash (710 clics)
- ShellShock.fr : explications et testeur en ligne (1950 clics)
- GitHub : Security vulnerability in bash addressed (235 clics)
- Shellshock DHCP RCE Proof of Concept (184 clics)
- Journal initial sur LinuxFr.org : Mets à jour ton bash. Maintenant. (455 clics)
- Free Software Foundation statement on the GNU Bash "shellshock" vulnerability (112 clics)
- 01Net : Interview exclusive: « J’ai découvert la faille Shellshock par hasard » (727 clics)
- shellshocker.net : explications et testeur en ligne (425 clics)
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Une précision
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Précision ajoutée, merci.
[^] # Re: Une précision
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
deux choses par ailleurs.
Le shell système par défaut sous FreeBSD n'est pas tcsh mais sh. (tcsh est le shell de root tout pareil que dash / bash sous debian).
Avec haproxy
reqdeny ()\ {dans les frontends permet de bloquer les tentatives d'exploit.# Question
Posté par Florian.J . Évalué à 10. Dernière modification le 29 septembre 2014 à 01:27.
Quand on voit la manière dont l'information est traitée par les médias on peut se poser des questions sur leur pertinence quand ils nous parlent d'économie, de géopolitique, de sciences, etc…
Cela dit bravo pour la dépêche, jusque là j'avais lu que des sources anglo-saxonnes, ce qui est pas toujours évident pour traiter des sujets techniques, là au moins c'est limpide :)
[^] # Re: Question
Posté par Professeur Méphisto . Évalué à 6.
n'ayant aucune compétence en la matière, je me garderai de porter un jugement là dessus. Je me contente de me méfier.
là par contre, je n'ai plus aucun doute. Et ça fait peur…
[^] # Re: Question
Posté par cedric . Évalué à 9.
Vu que les medias adorent les simplifications outrancieres, tu te doutes bien que leur analyse sur le sujet est probablement tout aussi mauvaise que dans les domaines que tu connais. Le probleme etant que ce renseigner sur ces sujets prend du temps, mais les informations sont disponibles de nos jours a tout le monde…
[^] # Re: Question
Posté par Florian.J . Évalué à 1.
Concernant l'économie c'est pas bien compliqué, c'est même extrêmement simple (déjà comprendre le rôle de la monnaie, c'est 80% du travail de fait), c'est juste qu'il y a tout un jargon autour qui est déroutant au premier abord, mais il y a foison de bouquins et de vidéos sur le net sur le sujet pour qui s'interesse un peu.
En gros (de mon point de vue) l'économie, comme toutes les sciences sociales, c'est juste un système dynamique, chaotique (au sens de la théorie du chaos) qui s'auto-entretient.
La seule chose à savoir et dont on peut être sûr c'est que personne en ce bas monde n'est capable de dire où on en sera dans un an, pas plus que quiconque est foutu de donner la météo de l'an prochain.
Tout au plus on peut se faire une idée générale, au risque de faire de grosses erreurs si l'on s'attend toujours à avoir du beau temps :)
Donc sans même entrer dans les détails technique, un économiste qui te dit ce qui va se passer dans les années à venir si l'on fait tel ou tel chose est soit un menteur, soit il se prend un peu pour Dieu.
[^] # Re: Question
Posté par Antoine . Évalué à 3.
Bizarrement la planification a plutôt bien marché dans les trente glorieuses.
[^] # Re: Question
Posté par Albert_ . Évalué à 3.
Une des raisons peut etre c'est que la planification etait a lont terme et non pas a la prochaine election ie a 6 mois de la et que le gouvernement suivant ne faisait pas exactement le contraire de ce qui avait ete decide avant.
[^] # Re: Question
Posté par Florian.J . Évalué à 4. Dernière modification le 30 septembre 2014 à 18:23.
Exactement, là il s'agissait d'une planification gérée par l'état, on était loin du modèle aujourd'hui tout "libre marché", du coup l'ensemble était plus stable.
Il est évident pour moi que l'état (surtout aujourd'hui) est le seul facteur stabilisateur dans une économie de libre marché, c'était pas le sens de mon propos en disant que c'était fondamentalement imprédictible sur le long terme, d'ailleurs les trentes glorieuses ont eut une fin brutale et non prévue :)
Si tu suis mon propos, il va plutôt à l'encontre des grands économistes que l'on voit à la télévision qui disent au contraire qu'il faut réduire le poids de l'état en prédisant monts et merveilles, alors ça va a l'encontre de ce qui marchait par le passé (l'état Gaullien) et qu'ils se trompent systématiquement dans le résultat de leurs prédictions (euro, libéralisme, libre échange, etc…).
L'économie est par nature instable, l'état doit y jouer un rôle de poids pour contre-balancer tout ça.
C'est ce que te dirait en autre choses un économiste comme Erik Reinert (dont je suis un adepte), mais c'est pas demain que tu entendras parler de lui à la télé…
D'ailleurs en parlant de l'euro, de nombreux prix Nobel d'économie ont retournés leur vestes en disant que c'était finalement une mauvaise idée. Je me souviens pas en avoir entendu parler mis à part sur internet, et encore, pas la presse officielle
[^] # Re: Question
Posté par cedric . Évalué à -2.
Le probleme de la planification de l'etat et que si celui-ci est incompetent (du fait d'une population de decideur trop age pour prendre en compte les ameliorations techniques disponible et en comprendre leur impact), celui-ci dirige tout un pays dans le mur sans aucune alternative possible.
L'etat est la pour fixer des regles. Mettre un prix sur les externalites et assurer un cadre a long terme qui permettra aux entrepreneurs d'experimenter des solutions de maniere plus distribues. Le probleme venant quand le dit cadre en place est la pour proteger une caste de la population et tente de marcher a l'encontre du monde. Toute la responsabilite de l'etat est dans la definition de ces regles que l'economie n'est pas capable de prendre en compte…
En soit, je ne vois pas en quoi un systeme instable est un probleme, tant que globalement celui-ci fournit assez de filet pour permettre a l'innovation et au progres de se mettre en place et prosperer. Quand on compare cela au domaine de l'informatique, on prefere tous un systeme decentralise et peer-to-peer a un systeme centralise. Mais on sait tous que c'est plus complique a mettre en place.
[^] # Re: Question
Posté par cedric . Évalué à 1.
Les trentes glorieuses sont une periode historique unique au cour de l'histoire. La principale raison pour la croissance de cette periode, est qu'on a eu acces une quantite phenomenale de petrole pas chere tres vite. Ce fut le sang de notre civilisation moderne. Et lorsque la production mondiale a finit de s'accelerer, toutes les economies ont accuse le coup. Les politiques n'ont eu qu'un effet a la marge durant cette periode. C'est cette afflux d'energie pas chere qui a fait les 30 glorieuses.
Note d'ailleur que depuis 2005/2006, elle a atteind un plateau et je te laisse deviner ce qu'il va se passer a partir de 2016 quand la production mondiale va diminuer :-)
[^] # Re: Question
Posté par Antoine . Évalué à 3.
C'est une condition nécessaire, pas suffisante. Il y a des tas de pays qui ont accès à du pétrole pas cher ; certains se développent vite, d'autres pas.
Parles-en aux habitants de Libye ou d'Irak…
[^] # Re: Question
Posté par cedric . Évalué à 2.
C'est un fait interressant, mais les pays qui produisent des ressources naturelles n'arrivent jamais a diversifier leur economie et ont de gros probleme d'efficacite energetique compare au reste du monde. Note aussi que tous les litres de petrole ne sont pas equivalent. Developper un litre de petrole dans le desert Saoudien, c'etait juste planter une paille. Alors que pour extraire du petrole bitumineux du canada, ils en sont a concevoir des centrales nucleaire. Ce qui compte, c'est l'energie net disponible.
Il n'y a pas de rapport entre developpement economique et regime politique, on est bien d'accord ? Avant qu'on decide que c'etait necessaire de leur taper dessus, ils n'etaient pas en si mauvaise position niveau developpement economique…
Mais etant donnee les tensions sur l'approvisionnement, clairement il vaut mieux avoir des armes pour securiser sont energie. Et c'est probablement la seul politique qui compte. Note que ca revient bien a dire que la seule politique qui compte est celle qui ramene de l'energie au pays ou en prend a d'autre.
On n'est d'ailleur pas oblige de le faire militairement, par exemple racheter du gaz de schiste americain est une arme tres efficace pour profiter de leur energie pas chere tout en leur en privant.
[^] # Re: Question
Posté par Antoine . Évalué à 3.
Les USA produisent des ressources naturelles. Le Royaume-Uni produit des ressources naturelles. La Norvège produit des ressources naturelles. Le Canada produit des ressources naturelles. L'Australie produit des ressources naturelles. Tous ces pays ont il me semble une économie qui se porte bien.
Ben non, on n'est pas d'accord. Pas en si mauvaise position peut-être, mais bon, je pense tout de même que la Libye, malgré son pétrole abondant et pas cher, était assez loin du développement occidental. Pareil, probablement, pour l'Irak de Saddam Hussein.
Et sinon, il y a d'autres exemples comme le Vénézuela, l'Algérie.
Donc pour résumer, on a :
- des pays ayant accès à beaucoup de pétrole pas cher qui se sont bien développé (1)
- des pays sans pétrole qui se sont bien développé (2)
- des pays ayant accès à beaucoup de pétrole pas cher qui ne se sont pas super développé
- des pays sans pétrole qui ne se sont pas super développé
On ne peut pas expliquer (1) et (2), et donc les trente glorieuses, uniquement en invoquant le pétrole pas cher (même si, encore une fois, je suis d'accord qu'il fait partie des facteurs de développement).
[^] # Re: Question
Posté par cedric . Évalué à 4.
Je n'ai jamais dis que leur economie ne se portait pas bien, mais quelle n'etait pas vraiment diversifie et qu'ils avaient de vrai probleme d'efficacite energetique. Commencons par le plus simple, dans la liste de pays que tu cites, lequel peut se promouvoir d'avoir une quelquonque efficacite energetique ? Aucun. Ils sont tous dans le palmares des plus gros consomateurs d'energie !
Pour ce qui est de la diversite de leur economie, a part les Etats-Unis qui sont, je pense, un cas a part du fait de leur taille et de leur population. Les autres pays sont plutot pauvrement diversifie de ce cote la. Le Royaume-Uni, c'est soit la banque, soit les ressources (en fonction de si tu habites a Londre ou pas en simplifiant). La Norvege, le Canada et l'Australie ne peuvent pas vraiment se targuer d'avoir une autre source de revenue que leur ressource.
Pour en revenir aux Etats-Unis, c'est un pays de taille considerable avec une tres importante population. Pour etre comparable aux autres pays, il vaut mieux le regarder comme un ensemble d'etat divers que comme un unique bloc. Dans ce cas, tu verras que a part la Californie et l'etat de New York, il n'y a tres peu de diversite dans son economie. D'ailleur si on enleve la Californie, les Etats-Unis sont tres proche du modele anglais en plus grand, grosse industrie de matiere premiere et financiarisation a outrance sans diversite de l'economie.
C'est a dire ? Les jeunes allez a l'universite. Ils avaient une perspective d'avenir. Et l'economie etait en croissance. Je te propose de regarder : http://fr.kushnirs.org/macroeconomie/gdp/gdp_libya.html. Le PIB par habitant etant passe de 2000$ a 15000$ en 40 ans. Je ne fais pas la l'appologie de leur regime politique, mais je pointe que lier democratie et reussite economique n'est pas une evidence. C'est une vue tres occidentale que de croire que croissance economique et democratie sont lie.
Ce qui compte c'est la capacite d'approvisionnement. En gros quel volume de petrole un pays est capable de s'accaparer. Plus il est capable de s'accaparer d'importante quantite de petrole, plus celui-ci se developpe et a une croissance economique forte (En fait, il faut rajouter aussi le charbon a cote du petrole pour etre complet).
Je veux bien un exemple de ce que tu entends par la. Mais la seule chose que je fais remarquer, c'est que l'augmentation du PIB est forcement precede par une augmentation de l'approvisionnement en volume de petrole. De la meme maniere, la diminution du dit approvisionnement precede la diminution du PIB.
Definir le developpement est quelques choses de plus complexe que de juste determiner le PIB (qui est deja pas simple en soi). J'ai l'impression que tu lie le PIB a une definition du developpement qui impliquerait aussi un systeme democratique et d'autres criteres de societe qui ne sont pas mon propos ici. Apres je pense que tous les regimes politiques actuels ont besoin d'une croissance economique sinon ils s'effondrent. Le simple ralentissement de celle-ci provoque des changements de regime assez radical et cela devrait poser question…
[^] # Re: Question
Posté par Antoine . Évalué à 2.
En guise de réponse, inutile de paraphraser ce qui existe déjà :
https://fr.wikipedia.org/wiki/%C3%89conomie_du_Royaume-Uni#mediaviewer/File:2012_Royaume-Uni_exportation_de_produits_treemap.png
Pareil qu'au-dessus :
https://fr.wikipedia.org/wiki/Industrie_aux_%C3%89tats-Unis#Les_types_d.27industries
Concernant le Canada, l'industrie (secteur secondaire) y représente 27% du PIB, contre 20% en France…
https://fr.wikipedia.org/wiki/%C3%89conomie_du_Canada#Secteur_secondaire
Bref cette fable selon laquelle un pays producteur de ressources naturelles ne pourrait se développer n'a aucune base réelle.
Sérieusement, tu te rends compte que tu te contredis d'une phrase à l'autre ? D'abord tu affirmes que les pays producteurs ne sont pas capables de se développer correctement, ensuite tu affirmes qu'il y a une causalité stricte entre l'accès au pétrole et le développement économique. Faudrait savoir !
On est bien d'accord. Sauf que c'est toi qui parles de démocratie ici, pas moi. Je rappelle la phrase que j'ai prononcée et à laquelle tu t'es opposée initialement :
"""Bizarrement la planification a plutôt bien marché dans les trente glorieuses."""
Depuis quand planification == démocratie ?
[^] # Re: Question
Posté par cedric . Évalué à 0.
Il y a quand meme deux choses que l'economie ne sait toujours pas expliquer depuis 2 siecles que cette "science" existe.
Tout d'abord qu'est-ce qui provoque la croissance ? C'est fou, mais oui, aucun economiste ne sait d'ou vient la croissance. Pour eux, c'est un postulat de base. On a une croissance fondamentale infinie et les crises ne sont que des mouvements au tour de cette courbe qui n'en finit pas de monter. C'est pour cela que les politiciens nous annoncent benoitement le retour de la croissance, car forcement elle reviendra, c'est un postula !
Le second point qui est amusant aussi, c'est l'incapacite de la science economique a prendre en compte un certain nombre d'externalite et de contrainte environementale. Ainsi le progres technique et la consomation des ressources sont infini par postula. Il n'y a pas de lien entre energie et economie. Ni entre matiere premiere et economie. Cela etait probablement vrai lorsque la science economique a pose ses postulat. Mais aujourd'hui, si tu calcules le rapport entre l'augmentation d'energie et l'augmentation de notre PIB, il devient evident que notre efficacite energetique diminue en fonction du temps. Le progres ralentit et notre dependence a une energie abondante n'a jamais etait aussi fort. De la meme maniere, on a jamais autant miner cette planete et la consomation de matiere premiere par occidentaux n'a jamais etait aussi eleve.
Il est evident que sauf a avoir acces tres tres tres rapidement a de nouvelle source d'energie et de matiere, on va droit a l'effondrement. Ce qui ne collera pas trop avec le modele de la croissance infinie.
Donc finalement, la monnaie, c'est pas si importante dans l'economie. Et si tu veux prevoir l'etat de l'economie, tu peux regarder la production en volume du petrole aujourd'hui, ca te donnera une indication sur le PIB dans environ un an. Pour le plus long terme, et bien, si tu arrives a prevoir la quantite d'energie disponible pour notre civilisation, tu arriveras probablement a une bonne approximation de notre PIB… C'est amusant que finalement ce soit une grandeur physique qui donne la contrainte sur notre economie qui elle, en temps que science, ignore complement. :-)
# Corrections
Posté par pedantic . Évalué à 10.
Par ailleurs, Bash ne permet pas cet export de fonctions s'il est utilisé en mode POSIX strict ( bash -p ).
Le mode posix est
bash --posix. C'est aussi le mode dans lequel on se trouve quandbashest invoqué en tant quesh.bash -pest un mode différent:Donc oui, bash n'est pas vulnérable avec
bash -p, mais il l'est toujours en mode posix.Mais Bash permet en outre de passer des fonctions vers le processus enfant. Aucun autre shell ne permet cela. Dans ce cadre relativement strict, la sécurité ne pose pas de problème : les droits et contextes d'exécution sont identiques et l'utilisateur, système ou non, est le même. Ceci est documenté, il s'agit de l'option -f du shell Bash.
Il s'agit de l'option
-fdeexportdans le shell bash.bash -fdésactive le globbing:La même chose, pour passer la fonction à un sous-shell
Quand on utilise la fonctionnalité "normalement", alors on utilise
export -fplutôt que de jouer avec les variables d'environnement:La variable d'environnement commençant par
() {n'est que la manière que bash a d'implémenterexport -f.[^] # Re: Corrections
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
[^] # Re: Corrections
Posté par barmic . Évalué à 7.
Pourquoi ne pas retirer ce bashisme du mode POSIX ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Quelque details
Posté par Misc (site web personnel) . Évalué à 10.
En fait, le souci a été rapporté plus tôt qu'il y a 4j. Le bug https://bugzilla.redhat.com/show_bug.cgi?id=1141597 date du 14 septembre. Sachant que l'équipe réponds en général sous 24h avec un CVE, je pense que la faille date de ce jour, ce qui a laissé le temps de coordonner , de corriger et de tester le correctif. Ensuite, en effet, la 2eme faille a été bien plus rapide à être corrigé, et je sais que l'équipe a bossé comme des fous sur le sujet.
Il est aussi à noter que l'article dit que CVE-2014-7187 et CVE-2014-7186 sont non publiques, mais il y a une description sur le bugzilla de RH :
https://bugzilla.redhat.com/show_bug.cgi?id=1146791
https://bugzilla.redhat.com/show_bug.cgi?id=1146804
Il me semble aussi que postfix n'est pas un vecteur connu ( au contraire de qmail et exim ), car il nettoie les variables comme il faut. Mais je ne trouve rien sur le sujet.
[^] # Re: Quelque details
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
On peut aussi voir le CVE-2014-6277 (Redhat).
[^] # Re: Quelque details
Posté par octane . Évalué à 3.
Curieux, je suis à peu près sur d'avoir vu les détails publiquement pour ces CVE, je cite de mémoire:
Et l'autre est lié à une boucle for, mais je ne parviens pas à la retrouver.
[^] # Re: Quelque details
Posté par Misc (site web personnel) . Évalué à 2.
Y a plein de poc sur github :
https://github.com/mubix/shellshocker-pocs
# Ne marche pas chez moi
Posté par Ant . Évalué à 1.
Je comprends à peu près le problème, mais chez moi la manip ne marche pas, n'étant pas un expert bash, je ne vois pas si c'est "normal" ou pas :
[^] # Re: Ne marche pas chez moi
Posté par Benoît Sibaud (site web personnel) . Évalué à 4. Dernière modification le 29 septembre 2014 à 10:10.
C'est un bash déjà corrigé (au moins partiellement).
[^] # Re: Ne marche pas chez moi
Posté par Ph Husson (site web personnel) . Évalué à 4.
Ouaip, c'est le comportement d'un bash mis à jour
# "bash" est plus large que lancer un shell
Posté par octane . Évalué à 10.
Ou n'importe quel outil qui fait une commande system:
Par exemple, pour python:
Ce n'est pas python qui est vulnérable, c'est la commande system qui lance "/bin/sh -c"
Donc attention, n'importe quel script (ou prog, ça marche aussi en C, etc..) peut sans qu'on s'en rende compte appeler /bin/sh (et par du fait des liens symboliques -> bash) même si bash n'apparaît pas explicitement.
Et même sans écouter le réseau, on peut imaginer un script qui va parser un fichier de log, ou autres joyeusetés, donc: mettez à jour
# Un avis différent sur bash
Posté par gnumdk (site web personnel) . Évalué à 3. Dernière modification le 29 septembre 2014 à 11:58.
http://blog.erratasec.com/2014/09/the-shockingly-bad-code-of-bash.html
[^] # Re: Un avis différent sur bash
Posté par octane . Évalué à 10.
Bonjour,
si un modo peut nettoyer l'URL du suffixe #.etc
C'est un marqueur du site web addthis, traqueur publicitaire. addthis est particulièrement "collant", donc il vaut mieux s'en défaire.
c'était la minute: "je ne veux pas être pisté, merci". Vous pouvez mettre vos bash à jour, maintenant :)
[^] # Re: Un avis différent sur bash
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Corrigé, merci.
[^] # Re: Un avis différent sur bash
Posté par Gof (site web personnel) . Évalué à 0.
C'est juste que bash a été écrit il y a 25 ans. C'est normal que le style de code soit un peux viellot. Mais ça ne veux pas dire que ce soit du mauvais code. Par contre c'est du code bien éprouvé.
[^] # Re: Un avis différent sur bash
Posté par barmic . Évalué à 4.
Dans ce qu'il présente, il y a des choses qui étaient moche même si elles avaient était écrite à la création du C. Tout ce qui est vieux ne peut pas utiliser son age pour expliquer sa mauvaise qualité.
On est sûr qu'il n'y a pas de faille qui traine dedans depuis 20 ans ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un avis différent sur bash
Posté par Troy McClure (site web personnel) . Évalué à 10.
Mouais franchement les trucs mentionnés dans le blog ci-dessus ça va pas chercher loin comme même, c'est pas hyper beau mais de là à le qualifier de shockingly bad c'est abusé. Le style K&R : on s'en fout. Les variables globales: c'est pas beau, mais au moins elles ont des noms bien longs et descriptifs , donc ça va, un coup de grep et on voit qui les utilise. La syntaxe un peu curieuse d'une boucle for: y'a pas de quoi en faire un plat. L'utilisation de strcpy: ça reflete l'age du soft, ça veut pas dire non plus que c'est un gruyère truffé de failles.
Franchement j'aime pas trop ce genre de posts où des donneurs de leçon bien opportunistes viennent se faire mousser en montrant du doigt le code des autres
[^] # Re: Un avis différent sur bash
Posté par barmic . Évalué à 0.
Je te moinsse rien que pour ça.
Moi j'apprécie qu'on remette en question le marbre qu'on a tendance à imaginer dur comme de la pierre et qui se révèle être fragile au final. Sincèrement voir encore des gens avancer l'argument de l'âge pour affirmer qu'un code est de qualité (cf ci-dessus) après heartbleed et shellshock va falloir apprendre à :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un avis différent sur bash
Posté par Beurt . Évalué à 5.
Très bel exemple de post donneur de leçons tel que Troy MCLure les dénonce !
[^] # Re: Un avis différent sur bash
Posté par barmic . Évalué à 1.
Ok. Si tu pense qu'il n'y a rien à apprendre de tout cela tant mieux.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un avis différent sur bash
Posté par Gof (site web personnel) . Évalué à 5.
Il y a peut être quelque chose à apprendre, mais il ne faut pas non plus tirer des conclusions hâtives.
Bash commence par la lettre 'B'. Et il contiens une faille de sécurité ! Conclusion: Il ne faut pas utiliser de programmes dont le nom commence par la lettre B.
Et les médias parlent de cette faille désastreuse. Vite ! Il faut créé une nouvelle loi pour que ça ne se reproduise pas. Dorénavant il est interdit de donner un nom qui commence par 'B' à un programme sous peine de prison.
Il faut que tu prouves que le style du code de bash soit une cause de la faille. Parce que c'est vraiment une critique gratuite : « Bouh, ils n'utilisent pas le dernier style à la mode, quels incapables ! »
[^] # Re: Un avis différent sur bash
Posté par pasBill pasGates . Évalué à 8.
Que le style soit responsable, c'est dur a prouver de maniere certaine (si ca se trouve c'est pas le cas…)
Ce qui est sur par contre, c'est que le style de programmation utilise (si on peut appeler ca un style…) est connu pour tres frequemment causer des problemes. Le meilleur exemple etant les variables globales, il devient tres dur d'arriver a savoir comment ces variables se comportent lorsque tu as des variables accessible de partout, que tu ne sais pas qui les change et qui ne les change pas (et non, un 'simple' grep ne suffit pas, vive les pointeurs).
Un certain minimum de variables globale peut avoir un sens, mais un nombre pareil rend le code impossible a maintenir et relire proprement.
Idem avec les fonctions considerees dangereuses. Leur presence n'indique evidemment pas automatiquement une faille, mais quand tu as fais assez de code reviews securite pour voir des patterns, tu sais que statistiquement, le risque est bcp plus eleve.
[^] # Re: Un avis différent sur bash
Posté par barmic . Évalué à 6.
C'est rigolo. OpenSSL a une faille d'un coup tout le monde se met à faire de l'audit et à financer des relectures, c'est normal. Bash possède une faille depuis l'éternité, mais attention avant de parler du code va falloir sortir des CVE sinon faut toucher à rien.
Maintenant il faut prouver quelque chose avant de pouvoir dire que leur code est moche ? Que c'est dommageable de devoir s'y reprendre à plusieurs fois pour corriger une faille ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un avis différent sur bash
Posté par Gof (site web personnel) . Évalué à 3.
Faire des audits et financer des relectures c'est utile.
Dire que leur code est « moche », c'est pas très utile et c'est un manque de respect.
[^] # Re: Un avis différent sur bash
Posté par barmic . Évalué à 3.
Critiquer c'est un manque de respect ? Parce que c'est ça ce que fait l'article dont on parle. Tu peut critiquer sa critique, dire que ce qu'il présente n'a pas d'intérêt, que ça n'a rien avoir avec la faille (et alors ?), etc… mais parler de manque de respect je ne vois pas.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un avis différent sur bash
Posté par Gof (site web personnel) . Évalué à 6.
Non, une critique constructive n'est pas un manque de respect.
Par contre là c'est juste une critique du genre « J'aime pas ton style, c'est moche. »
On peu discuter aussi longtemps qu'on veux pour savoir si la programmation fonctionelle est meilleur que la programation object ou impérative. Mais à l'époque, le style à la mode était à la programmation impérative avec des variables globales. À l'époque ou le code a été écrit, les fonctions prétendues plus sûres n'existaient pas encore et les développeur utilisaient les fonctions existantes en faisant attention.
Ça ne rends pas le code mauvais. Juste vieux.
[^] # Re: Un avis différent sur bash
Posté par barmic . Évalué à 1.
Tu dis qu'il a une dette technique et que c'est bien comme ça ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un avis différent sur bash
Posté par Antoine . Évalué à 1.
Dans chaque langage il existe des usages et des bonnes pratiques. Les ignorer en prétextant que c'est juste une question de goût et que chacun fait bien ce qu'il veut, c'est infantile.
En fait ce qui serait bien c'est que tu argumentes précisément sur le fond de l'article au lieu d'en reste à quelques généralités dignes d'un Zenitram.
[^] # Re: Un avis différent sur bash
Posté par Antoine . Évalué à 2.
Le code n'est pas seulement "moche", il pose de vrais problèmes de lisibilité et de compréhensibilité. Va lire le lien en question au lieu parler dans le vide :
http://blog.erratasec.com/2014/09/the-shockingly-bad-code-of-bash.html
[^] # Re: Un avis différent sur bash
Posté par bubar🦥 (Mastodon) . Évalué à -1.
Vu comme ça… :p
[^] # Re: Un avis différent sur bash
Posté par Antoine . Évalué à 3.
C'est quoi le problème ?
http://www.larousse.fr/dictionnaires/francais/compr%C3%A9hensibilit%C3%A9/17769
"""compréhensibilité
nom féminin
"""
[^] # Re: Un avis différent sur bash
Posté par ariasuni . Évalué à 2.
Tant qu’on est dans les pinaillages, c’est «Troy McClure».
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Un avis différent sur bash
Posté par Altor . Évalué à 5.
C'est Monsieur Troy McClure
[^] # Re: Un avis différent sur bash
Posté par soukki . Évalué à 10.
Dit quelqu'un qui écrit dans une réponse au dessus :
:p
[^] # Re: Un avis différent sur bash
Posté par Gof (site web personnel) . Évalué à 5.
Je n'ai pas dit ça. Et je n'ai pas dit non plus que du vieux code était forcément parfait et bien éprouvé. Ce serait tomber dans un extrême inverse.
Par contre, le poste critique bash car il utilise pas le dernier style de codage à la mode. Est-ce là raison de shellshock ? Probablement pas.
Je suis un partisent du « Ne corrige pas si ce n'est pas cassé ». Ça ne veux pas dire qu'il ne faut pas chercher à améliorer les vieux truc. Mais ça veux dire que refactoriser pour le plaisir n'est pas toujours une bonne idée. Pour un programme tel que bash, un petit changement de comportement peux casser plein de script. Il vaux mieux être prudent.
Je vais prendre un en exemple la CVE-2007-1381 dans PHP, où un développeur voulant rendre le code plus « sécure » a remplacé une utilisation parfaitement valide de
strncpypar un emploi erroné destrlcpycausant un trou béant de sécurité. Et parce que cette leçon n'est pas suffisante, php refait une erreur similaire 4 ans plus tard en remplaçant unstrcatpar unstrlcathttps://bugs.php.net/bug.php?id=55439Vive les bonne pratiques, hein !
[^] # Re: Un avis différent sur bash
Posté par barmic . Évalué à 4.
Je n'ai pas dis que tout code de moins de X années est exempte de bug, juste qu'il ne faut pas mystifier du vieux code sous prétexte qu'il est vieux ou très utiliser. Dis autrement avoir une approche scientifique et s'autoriser le doute (mais douter ce n'est pas corriger à l'arrache, c'est regarder comment ça marche et se poser la question est-ce que ça marche bien).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un avis différent sur bash
Posté par djano . Évalué à 3.
Bah si ç’avait été un programme qui avait automatiquement corrige le code pour le mettre a jour, ce n'aurait jamais été un problème.
Je ne suis pas d'accord avec la politique qui consiste a dire que l'on ne touche a rien parce que ça marche. C'est comme ça que l'on arrive a une base de code morte parce que personne ne veut mettre le nez dedans parce que c'est moche / buggue / etc.
C'est comme ça que l'on arrive a avoir du code legacy que l'on ne peut plus toucher parce que l'on ne sais pas ce que ça fait, ni comment ça le fait.
Le meilleur moyen d’éviter tout cela et de faire évoluer le code continuellement.
[^] # Re: Un avis différent sur bash
Posté par tyoup . Évalué à 0.
La fusée Ariane s'en souvient ;-)
Les traders savent aussi que c'est important de bidouiller l'algo de valorisation de leurs portefeuilles
…
[^] # Re: Un avis différent sur bash
Posté par djano . Évalué à 2.
Je vois pas le rapport avec ce que je dis dans le commentaire ci-dessus.
La fusée Ariane V s'est plantée parce qu'il ont réutilisé du code dans un contexte différent sans vérifier qu'il pouvait supporter les nouveaux paramètres lies a la puissance supérieure d'Ariane V par rapport a celle d'Ariane IV (la fusée pour laquelle le code avait été originellement écrit).
Par contre c'est tout a fait approprie pour shellshock ou des gens (Apache, dhcpd, …) ont donne un accès très ouvert a bash, hors de sa conception d'origine.
[^] # Re: Un avis différent sur bash
Posté par tyoup . Évalué à 1.
Bah le code peut aussi évoluer continuellement sans jamais révéler la fonctionnalité… Euh, la faille, je veux dire ;-).
[^] # Re: Un avis différent sur bash
Posté par djano . Évalué à 4.
Bien sur c'est possible.
Il est aussi possible que la faille ait pu être trouvée par ce biais.
Tu enfonces les portes ouvertes?
[^] # Re: Un avis différent sur bash
Posté par tyoup . Évalué à 1.
Si j'enfonce un truc, c'est pas une porte ouverte, c'est un argument péremptoire.
Faire évoluer continuellement du code ça garantit quoi ? Que le nombre de bug est décroissant ? Qu'un jour il n'y aura plus jamais de failles de sécurité ?
[^] # Re: Un avis différent sur bash
Posté par djano . Évalué à 2.
Non ça ne garanti pas que tous les bugs soit trouves ou que toutes les failles de sécurités soient bouchées.
Relis ce que j'ai écrit:
Ce que je dis c'est que ça modernise le code, ça rend la base de code a nouveau attrayante aux yeux des contributeurs externes, et que ça permet de faire une revue de code parce qu'en l’améliore continuellement, on est oblige de le lire. Donc il y a des chances que l'on trouve et corrige des bugs.
Ça m'arrive tous les jours dans mon boulot. Je trouve et corrige des bugs parce que j'essaie de factoriser le code. Lorsque je factorise le code, j'essaie de voir pourquoi 2 bouts de codes sont différents. Parfois 2 bouts de code très similaires different d'une manière subtile. Je demande a mes collègues plus expérimentés pourquoi ces codes diffèrent, et paf! c'est souvent un bug.
[^] # Re: Un avis différent sur bash
Posté par tyoup . Évalué à 0.
Je dirais bien "ça reste à vérifier" :). Déjà c'est pas dit qu'il y ait des gentils contributeurs externes qui corrigent tes bugs. Ensuite on sait que plus on fait d'évolutions plus le risque d'introduire des régressions est élevée. J'ai bossé sur plusieurs applications "legacy" et franchement c'est pas la panacée. Avec un nombre de lignes croissant et un nombre de développeurs décroissant, faire évoluer continuellement le code ça me paraît juste impensable.
My two cents.
# Pourquoi ce bash-isme ?
Posté par windu.2b . Évalué à 10.
Merci tout d'abord pour l'explication de cette faille. Ce que je souhaite cependant comprendre, c'est pourquoi ce bash-isme existe (permettre de passer une fonction à un processus-fils) ? Dans quel(s) cas, cela est-il utile ? Et pourquoi les autres shells n'ont jamais implémenté ce _bash-ism_e ? Pour une question de sécurité, je suppose ?
[^] # Re: Pourquoi ce bash-isme ?
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 2.
L’autre question que l’on peut se poser, c’est pourquoi tant de distributions ont-elles mis bash par défaut, ou pire en le faisant passer pour sh ?
Pour mes sessions, je préfère aussi utiliser un shell puissant (zsh dans mon cas), mais je ne comprends pas le besoin de l’imposer partout.
[^] # Re: Pourquoi ce bash-isme ?
Posté par barmic . Évalué à 5.
Debian pour le retirer a du développer dash, je présume qu'il n'y avait plus de shell plus simple que bash/tcsh qui pouvait servir de shell POSIX.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Troll
Posté par woprandi . Évalué à -3.
Pas envie d'attendre vendredi : http://blog.erratasec.com/2014/09/the-shockingly-bad-code-of-bash.html
[^] # Re: Troll
Posté par Zenitram (site web personnel) . Évalué à 10.
comme les langages : il y a que deux sortes de code : le code qui est critiqué, et le code qui n'est pas utilisé.
# Je pense avoir bien lu la dépèche mais...
Posté par FantastIX . Évalué à 6. Dernière modification le 29 septembre 2014 à 12:35.
… 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.
[^] # Re: Je pense avoir bien lu la dépèche mais...
Posté par FantastIX . Évalué à 5.
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/ .
[^] # Re: Je pense avoir bien lu la dépèche mais...
Posté par allcolor (site web personnel) . Évalué à 6.
Parce que dans le premier cas, l'exécution est faite à l'évaluation de l'environnement donc sans qu'on ne fasse rien d'autre que d’exécuter le shell avec la variable settée… tandis que dans le second cas, il faut appeler la fonction,ce qu'on ne peut pas faire si on ne contrôle pas le script, alors que dans le premier cas, on n'a rien à faire, ça sera exécuté.
[^] # Re: Je pense avoir bien lu la dépèche mais...
Posté par gouttegd . Évalué à 7.
Ici, le « code malfaisant » est systématiquement exécuté à la définition de la fonction, même si ladite fonction n’est jamais appelée par la suite. Alors qu’avec
le code malfaisant ne sera exécuté que si le shell appelle la fonction
mafonctionà un moment.Je ne me prononcerai pas sur « quelle faille est la plus conséquente » ; entre une fuite d’information (dont potentiellement les clefs privées du serveur TLS) et une exécution de code arbitraire, je ne suis pas sûr qu’une comparaison soit pertinente.
Exact, mais selon le compte en question, ça peut déjà permettre de faire des dégâts (par exemple, tu n’as pas forcément besoin des privilèges administrateurs pour envoyer du spam). Et ça peut toujours servir de « tête de pont » pour ensuite exploiter une éventuelle faille locale.
[^] # Re: Je pense avoir bien lu la dépèche mais...
Posté par FantastIX . Évalué à 2.
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 ;-) .
C'est bien ce que je pensais.
# Apparemment, tout ne serait pas terminé...
Posté par FantastIX . Évalué à 6.
Further flaws render Shellshock patch ineffective
Même après application des correctifs, les systèmes demeureraient vulnérables. À confirmer, j'imagine.
[^] # Re: Apparemment, tout ne serait pas terminé...
Posté par Aissen . Évalué à 4.
La source originale, avec plus de détails:
http://lcamtuf.blogspot.co.nz/2014/09/bash-bug-apply-unofficial-patch-now.html
[^] # Re: Apparemment, tout ne serait pas terminé...
Posté par Aissen . Évalué à 4.
Un outil bien pratique pour tester les différentes vulnérabilités shellshock:
https://github.com/hannob/bashcheck
# Preuve de plus que la programmation en shell est une mauvaise pratique ?
Posté par tyoup . Évalué à -10.
Pour moi, oui, c'est une belle preuve que la programmation en shell est une mauvaise pratique.
Mon trollomètre me disant que je serait déjà allé trop loin pour pouvoir argumenter un peu :
À vos trolls ! Prêts ?! Partez !!!
[^] # Re: Preuve de plus que la programmation en shell est une mauvaise pratique ?
Posté par Ph Husson (site web personnel) . Évalué à 5.
Il dit qu'il voit pas le rapport.
[^] # Re: Preuve de plus que la programmation en shell est une mauvaise pratique ?
Posté par tyoup . Évalué à 3.
le rat-porc est un animal de légende tout comme le troll
[^] # Re: Preuve de plus que la programmation en shell est une mauvaise pratique ?
Posté par Sufflope (site web personnel) . Évalué à 0.
Contrairement à l'homme-ours-porc qui est une vraie menace pour le climat. Je suis très sérieuxe.
[^] # Re: Preuve de plus que la programmation en shell est une mauvaise pratique ?
Posté par FantastIX . Évalué à 2.
Tout-à-fait. De plus, c'est un porc qui pique.
[^] # Re: Preuve de plus que la programmation en shell est une mauvaise pratique ?
Posté par tyoup . Évalué à 1.
Le cas que tu cites pique aussi.
[^] # Re: Preuve de plus que la programmation en shell est une mauvaise pratique ?
Posté par tyoup . Évalué à 2.
Le cactus i' te pique aussi.
[^] # Re: Preuve de plus que la programmation en shell est une mauvaise pratique ?
Posté par FantastIX . Évalué à 2.
Respect!
# Bug ou fonctionnalité ?
Posté par crusher . Évalué à 7.
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 ?
Si ce n'est pas le cas c'est bien un bug et non pas une fonctionnalité qui pose un problème de sécurité utilisée dans un certain contexte.
[^] # Re: Bug ou fonctionnalité ?
Posté par FantastIX . Évalué à 6. Dernière modification le 30 septembre 2014 à 21:54.
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…
[^] # Re: Bug ou fonctionnalité ?
Posté par barmic . Évalué à 4.
Non. Lors des injections arbitraires c'est celui qui reçoit qui valide ses entrées. C'est une sécurité beaucoup plus forte. Tu parle des sites web, ce n'est pas à ton navigateur de protéger les sites web, ce sont les sites web eux-même. Là il n'est pas possible de la part d'un script de se protéger.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bug ou fonctionnalité ?
Posté par claudex . Évalué à 8.
Je crois que tu as compris de travers son propos. Il dit que ce n'est pas à Bash de se protéger, comme ce n'est pas à une base SQL d'échapper les entrées qu'elle reçoit. C'est bien au site web d'échapper ce qu'il envoit quand il fait des requêtes SQL, et ce serait donc aussi aux site d'échapper ce qu'ils envoient avant de le passer à Bash.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Bug ou fonctionnalité ?
Posté par Sufflope (site web personnel) . Évalué à 0. Dernière modification le 01 octobre 2014 à 11:19.
Sachant qu'ils envoient généralement ce qu'ils ont reçu de l'utilisateur (humain ou non), je trouve assez paradoxal de dire que la BDD n'a pas a échapper ses entrées mais que le site doit échapper ses entrées.
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.
La conclusion est donc que la programmation défensive ça sert à rien, il ne faut qu'aucun programme ne valide/échappe ses entrées, mais que les blackhat se contente d'envoyer des Virus Belges.
[^] # Re: Bug ou fonctionnalité ?
Posté par FantastIX . Évalué à -1.
Faux. Sophisme, faux dilemme.
Faux. Autre sophisme, épouvantail.
[^] # Re: Bug ou fonctionnalité ?
Posté par Sufflope (site web personnel) . Évalué à 7.
Si l'un des autres moinsseurs avait l'amabilité de m'expliquer (autrement que l'abruti du dessus et son laconique et inutile « FAUX ! PAN SUR LES DOIGTS ! ») en quoi l'argument « ce n'est pas à moi de nettoyer mes entrées mais à l'autre de nettoyer sa sortie » qui est utilisé pour défendre SQL et bash ne s'appliquerait pas aussi au maillon antérieur qui lui aussi a peut-être la flemme de nettoyer et veut faire confiance au maillon encore antérieur…
Au moins je pourrais comprendre et être moins bête.
[^] # Re: Bug ou fonctionnalité ?
Posté par FantastIX . Évalué à 3.
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.
[^] # Re: Bug ou fonctionnalité ?
Posté par FantastIX . Évalué à 2.
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.
[^] # Re: Bug ou fonctionnalité ?
Posté par barmic . Évalué à 6.
Les bases SQL sont le seul exemples que je vois qui est ainsi. Toutes les autres entrées des scrits shell sont vérifiées (ou devrait l'être). C'est une bonne pratique qui est répété à tut tête par tout le monde. C'est au script de se prémunir d'un
./script.sh "toto;rm -rf /".Que les serveurs devraient vérifier qu'il n'y a pas d'injection de fonction dans les variables d'environnement oui ce serait bien (parce que bon tu peut toujours définir une fonction
printf), mais ça n'en ai pas moins une grosse faille de bash.Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bug ou fonctionnalité ?
Posté par Antoine . Évalué à 5. Dernière modification le 01 octobre 2014 à 11:58.
Il n'y a rien à échapper ici. C'est bash qui exécute du code en violation de sa propre API. Nulle part dans la doc de bash il n'est écrit que l'on peut exécuter du code en le passant dans une variable d'environnement, et il n'est pas non plus spécifié comment "échapper" ces valeurs.
Cela n'a rien à voir avec SQL où l'échappement fait officiellement partie des pratiques à respecter.
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 ; pas à l'appelant d'échapper au doigt mouillé en espérant se faufiler entre des bugs latents et encore inconnus.
[^] # Re: Bug ou fonctionnalité ?
Posté par FantastIX . Évalué à 1.
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 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.
[^] # Re: Bug ou fonctionnalité ?
Posté par FantastIX . Évalué à 2.
Flûte…!
L'analogi*e* pas l'analogi*que*! :D
[^] # Re: Bug ou fonctionnalité ?
Posté par Antoine . Évalué à 4.
Si je veux passer des données arbitraires à un programme fils, ce n'est pas à moi de les valider. Si bash est entre les deux, boum !
[^] # Re: Bug ou fonctionnalité ?
Posté par Moonz . Évalué à 5.
Il n’y a rien à valider dans une variable d’environnement : du point de vue du shell le contenu d’une variable d’environnement n’est pas censé avoir la moindre sémantique.
Question bête, tu proposes de l’échapper comment, le
() {? Le shell ne défini aucune séquence d’échappement pour le contenu d’une variable d’environnement (et pour cause, une variable d’environnement n’a pas de sémantique)[^] # Re: Bug ou fonctionnalité ?
Posté par Antoine . Évalué à 5.
Sans bash il n'y aurait pas eu de problème parce qu'il s'agit :
1) d'un bug spécifique à bash
2) au sein de l'implémentation d'une fonctionnalité spécifique à bash
Quant à prétendre qu'il y aurait une défaillance ailleurs, j'aimerais qu'on me montre la partie de la spec POSIX qui explique comment on "sécurise" les valeurs des variables d'environnement.
(parce que si on fait du code portable, on ne code pas pour bash, on code pour un standard donné)
[^] # Re: Bug ou fonctionnalité ?
Posté par FantastIX . Évalué à 1. Dernière modification le 01 octobre 2014 à 12:26.
Faux. Il y aurait probablement eu une erreur dans les logs, éventuellement, peut-être sans conséquence apparente.
Avec une expression régulière, par exemple? Pour séparer le nom de variable de sa valeur…?
[^] # Re: Bug ou fonctionnalité ?
Posté par Antoine . Évalué à 4.
Je parle de sécuriser les valeurs, pas de parser des chaînes "clé=valeur".
Tu dis qu'il faut sécuriser les valeurs en amont, je te demande donc ce que dit POSIX à ce sujet :-)
[^] # Re: Bug ou fonctionnalité ?
Posté par FantastIX . Évalué à 1.
En quoi "parser" ne répondrait pas à la question?
[^] # Re: Bug ou fonctionnalité ?
Posté par FantastIX . Évalué à 1.
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.
[^] # Re: Bug ou fonctionnalité ?
Posté par FantastIX . Évalué à 4.
Pfff… mettre un genoux à terre, faire acte de contrition et répéter: je ne le ferai plus.
Ben si, justement. Quel con, mais quel con!
[^] # Re: Bug ou fonctionnalité ?
Posté par groumly . Évalué à 6.
Bash n'a pas a executer du code que personne ne lui a demande d'executer. Quand tu exportes une fonction, tu ne demande pas a base d'executer du code.
Point a la ligne, ya rien d'autre a rajouter.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
# Tester pour server Linux avec Php
Posté par Frogg . Évalué à 2.
Bonjour à tous,
j'ai fait un script php qui est sensé essayer les 4 failles de bash avec différentes méthodes
https://github.com/Fro99666/froggShellShocker
J'ai l'impression (d’après mes tests) que la faille n°3 est encore présente dans mon apache2 de ma debian 6 (mise à jour hier), ce qui est assez gênant car elle semble facilement exploitable via un wget ou un curl …
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.