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...
[^] # Re: Bug ou fonctionnalité ?
Posté par FantastIX . En réponse à la dépêche Une faille nommée « shellshock ». É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...