Licence CC BY

La vulnérabilité Shellshock

Une vulnérabilité dans Bash

Publié :
Auteur :
Catégories :

Après Heartbleed, qui permettait d'attaquer OpenSSL pour récupérer la clef privée utilisée par un serveur vulnérable1, c'est au tour de Shellshock de faire parler d'elle. Cette fois-ci, c'est Bash qui est touché et une exploitation de cette faille permet d'exécuter assez facilement du code arbitraire. De quoi laisser songeur…

En réalité, maintenant que les gens savent où regarder, ce n'est pas une, mais au moins six failles qui ont été découvertes. Cet article ne parle que de celle par qui « tout a commencé ».

Quelques CVE à regarder pour les intéressés :

  • 2014-6271
  • 2014-6277
  • 2014-6278
  • 2014-7169
  • 2014-7186
  • 2014-7187

  1. Et c'est même plus facile que ça en a l'air. Les gars de chez CloudFlare ont écrit un article très intéressant à ce sujet et ce ne sont bien évidemment pas les seuls

Le coupable : Bash

Bash est le shell du projet GNU publié sous licence libre (GPL3 pour les versions plus récentes1). La première version de Bash date de 1988, ce qui en fait un projet vénérable. C'est une donnée intéressante, car il paraitrait que Shellshock est exploitable dans Bash depuis une vingtaine d'années2. C'est une donnée intéressante à prendre en compte et très symbolique, car l'un des arguments en faveur du logiciel libre est la prétendue facilité de faire des audits « soi-même ». Quiconque a déjà regardé le code de Bash se rendra vite compte que les choses ne sont pas si simples. De la même manière, Heartbleed avait mis plus de deux ans à être découverte, alors qu'OpenSSL est une pièce logicielle majeure de l'internet de confiance d'aujourd'hui. À ce sujet, la FSF s'est fendu d'un article à ce sujet. Sa lecture alimente le débat.


  1. Apple utilise un fork interne de Bash, basé sur une version antérieure publiée sous GPL2 qu'ils font évoluer en parallèle. 

  2. Notez l'usage du conditionnel. 

La vulnérabilité

Bash offre plusieurs fonctionnalités peu connues. L'une d'entre elles consiste à définir une variable d'environnement pour une commande donnée.

1
2
3
4
sh$ env TEST="Bonjour" bash -c "printenv TEST"
Bonjour
sh$ printenv TEST
# error

La vulnérabilité Shellshock profite d'une erreur des développeurs de Bash justement dans cette fonctionnalité. Plus précisément, le loup se cache dans un cas particulier comme celui-ci :

1
2
sh$ env TEST='() { echo test; };' bash -c TEST
test

Ici, la variable d'environnement TEST contient une fonction qui exécutée par l'appel de bash. À noter que la fonction n'est pas exécutée si elle n'est pas appelée. Ça peut sembler légitime, mais ça aura très vite son importance. Ainsi :

1
2
sh$ env TEST='() { echo test; };' bash -c "echo tada"
tada

Il est donc possible de fournir du code arbitraire à une commande Bash via une variable d'environnement. Ce code ne sera exécuté que sur la demande de la commande. À noter que si ladite commande s'attend à ce que la variable d'environnement ne contienne qu'une chaine de caractère et l'utilise comme telle, le code ne sera pas non plus exécuté :

1
2
3
sh$ env TEST='() { echo test; };' bash -c "printenv TEST"
() { echo test
}

Ce que les gens de Bash n'ont certainement pas voulu implémenter, cependant, c'est ce comportement en particulier :

1
2
3
sh$ env TEST='() { echo test; }; echo "vulnerable"' bash -c "echo hello"
vulnerable
hello

Qu'est-ce qui est choquant ici ? Il faut regarder d'un peu plus près la commande qui, il faut l'avouer, n'est pas forcément très familière ou lisible. Globalement, elle est séparée en deux parties : env TEST='() { echo test; }; echo "vulnerable"' et bash -c "echo hello". Nous avons déjà vu la sémantique de tout cela : cela rajoute une variable d'environnement TEST pour l'exécution de la commande bash -c "echo hello". Cette variable d'environnement est définie comme une fonction qui affiche « test »… suivie d'une instruction echo "vulnerable".

Quand on regarde le résultat, on voit que la commande echo hello a bien été exécutée. On voit aussi que la fonction stockée dans TEST, elle, ne l'a pas été. Par contre, et c'est là que le bât blesse, l'instruction l'a été. On voit que « vulnerable » a été imprimée à l'écran. Shellshock, c'est cette exécution involontaire.

Pourquoi c'est mal ? Un exemple avec Apache et les scripts CGI

Il n'est pas forcément évident de voir quel est le problème ici. En tout cas, je ne l'ai personnellement pas vu directement. Ça devient tout de suite plus clair quand on s'intéresse à l'utilisation qui est faite de la fonctionnalité à l'origine du scandale. Le fonctionnement d'Apache et des scripts CGI est un exemple à la fois parlant et simple à comprendre.

CGI stocke les headers de vos requêtes HTTP dans des variables d'environnement. Et si vous vous amusez à tricher avec votre User Agent ?

1
curl -k http://site-vulnerable.org/cgi-bin/test -H "User-Agent: () { :;}; cp /etc/passwd /srv/http/public"

L'argument -H de curl permet de redéfinir le header de votre requête HTTP. Ce qui veut dire que votre User Agent aura comme valeur, lorsque curl fera une requête HTTP pour télécharger la page demandée, User-Agent: () { :;}; cp /etc/passwd /srv/http/public.

Conséquence ? Une variable d'environnement pour l'User-Agent sera crée… Exploitant la vulnérabilité Shellshock, l'instruction cp /etc/passwd /srv/http/public sera exécutée !

Contremesures

Pour savoir si votre machine utilisant Bash (Linux ou OS X, par exemple) est vulnérable, vous pouvez simplement utiliser la commande présentée à la fin de la Section « Vulnérabilité », à savoir :

1
sh$ env TEST='() { echo test; }; echo "vulnerable"' bash -c "echo hello"

Si « vulnerable » apparait sur votre écran, c'est que vous êtes vulnérables. Dans ce cas-là, il vous faudra patcher/mettre à jour votre version de bash. À noter que les patchs qui ont été émis ne sont que des correctifs temporaires. La vraie solution pour contrer Shellshock est de recoder un parseur beaucoup plus robuste. Le vrai danger de Shellshock réside dans son extrême facilité d'exploitation et sa présence dans une très large majorité des serveurs. Il ne sera pas si évident de s'en débarrasser, notamment dans les systèmes embarqués. Affaire à suivre, donc.

Crédit icône : http://aaronkondziela.com/2014/09/shellshock-logo-for-bash-vulnerability/ (CC BY 4.0)


13 commentaires

Staff

s/features/fonctionnalités non ?

Je reprends ma lecture.

PS : s/fix/correctifs.

PPS : Malgré ces quelques barbarismes, l'article est clair et me semble précis ; bien loin des délires qu'on a pu lire dans les journaux grand public ces derniers jours.

Édité

Un petit article sympa sur le code de Bash.

bien loin des délires qu'on a pu lire dans les journaux grand public ces derniers jours.

J'ai pas lu les dits articles, mais je pense que ça vient de la difficulté de la chose. Rien que dans l'article, je n'explique pas ce qu'est un shell, ni un script CGI, ni même ce qu'est une variable d'environnement…

Bonjour

Un article de Linuxfr expliquant bien la faille aussi, et qui relativise l'impact de cette faille sur les systèmes embarqués, qui utilisent majoritairement busybox, dont l'implémentation de Bash n'est pas sensible à cette faille.

+0 -0

Perso j'ai appris l'existence de cette faille par un ami qui a lu un article sur 20minutes.fr. Le journal avait demandé son avis à un expert en sécurité qui bosse chez… Microsoft…

Merci pour ce très bon article qui, même s'il fait sûrement l'impasse sur des choses très techniques, a le mérite d'être très clair, je ne savais même pas qu'on pouvait mettre une fonction dans une variable d'environnement, bon à savoir (même si je ne vois pas dans quels cas cela peut être utile :-° )

A graphical interface is like a joke: if you have to explain it, that's shit. | Les logiciels Deuchnord

+0 -0

qui relativise l'impact de cette faille sur les systèmes embarqués

bendia

Même avec un bash vulnérable, cette faille n'est pas si catastrophique que ça: il faut pouvoir l'exploiter. On parle des scripts CGI ci-dessus, ils ne s'exécutent pas avec les droits root. J'ai vu des articles parler de vulnérabilités via ssh, avant de préciser qu'il s'agissait de vulnérabilité post-authentification.

Il n'y a pas à mon sens de risque direct de compromission de la sécurité avec cette faille, si les droits ont été bien pensés. Cela dit, il y a deux grand risques: on peut se servir de cette faille pour faire du déni de service (au minimum sur le service qu'on utilise pour exploiter la faille), et on peut utiliser cet accès pour exploiter d'autres vulnérabilités. Cela dit, sur un système embarqué, même en devenant root, vous n'aurez pas forcément tout pouvoir sur le système. Les parties critiques sont souvent isolées physiquement des systèmes multimédia.

En résumé, shellshock est une grosse faille de sécurité, mais c'est pas pour autant la fin du monde, ses potentialités dépendent trop du reste du système qui l'héberge.

PS: en plus de la possibilité de DDoS, il y a la possibilité d'utiliser la machine dans un réseau de zombis

Édité

+0 -0

Cela dit, sur un système embarqué, même en devenant root, vous n'aurez pas forcément tout pouvoir sur le système. Les parties critiques sont souvent isolées physiquement des systèmes multimédia.

Prenons exemple sur les boxs Internet qui sont souvent en root pour tout chez nos fournisseurs français avec un système Linux dessus (mais plutôt busybox que bash pour le shell). Une telle faille te permettrait de prendre le contrôle de la box et d'éventuellement capter et rediriger tout le trafic réseau (bonjour les arnaques ou les tentatives de récurpération de données personnelles comme le mot de passe sur un site non HTTPS par exemple).

Ça peut facilement aller très loin…

Amateur de Logiciel Libre et de la distribution GNU/Linux Fedora.

+0 -0

On en revient à ce que je disais: le problème n'est pas dans la faille bash qui pose problème, c'est un mauvais design de la box au niveau des droits et une confiance dans le médium pour l'authentification et le secret des données. Les set-top box font vraiment tourner leurs services en root en 2014 ? dire que je trouve qu'on est assez light sur la sécurité dans ma boîte… Mais bon, dans l'embarqué, ça ne m'étonne pas plus que ça. C'est un domaine où il est plus important de réduire les coûts que de blinder la sécurité, vu que les clients ne sont pas prêts à payer plus cher pour de la sécurité logicielle.

+0 -0

J'ai travaillé pour SFR et les boxs sont des solutions maisons, aps des set-up boxs et la conception de ces boîters date de 2005 en terme de logique logicielle (le matériel évolue mais le logiciel sous-jacent garde la conception de l'époque).

L'ANSSI commence à peine (2012-2013) à faire des audits et exiger une sécurité minimale des équipements des opérateurs téléphoniques. Il faut du temps pour mettre ça en place et changer la logique interne… Il y a des solutions à base de conteneurs applicatifs (LXC) pour essayer d'améliorer la situation (même si ce n'est pas totalement suffisant) mais ça ne se déploie pas comme ça sur des millions de machines qui doivent avoir un taux de panne bas (en théorie). ;)

Amateur de Logiciel Libre et de la distribution GNU/Linux Fedora.

+0 -0

Je crois qu'il y a une typo tout au début de l'article :

[…] C'est au tour de Shellsock de […]

Shellshock

Sinon l'article est très bon. J'ai réellement galéré à trouver un article censé qui expliquait correctement et en détail quelle était cette vulnérabilité il y a une semaine… Il ressemblait beaucoup à celui-ci dans la forme (en Anglais) : c'est pas du tout une critique de plagia ou quoi, c'est au contraire une très bonne chose car cet article était, je trouve, excellent.

Edit Arius: Corrigé, merci.

Édité

Happiness is a warm puppy

+3 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte