Shellshock (bug logiciel)

Shellshock , également connu sous le nom de Bashdoor , est une famille de bogues de sécurité dans le shell Unix Bash , dont le premier a été divulgué le 24 septembre 2014. Shellshock pourrait permettre à un attaquant de forcer Bash à exécuter des commandes arbitraires et d'obtenir un accès non autorisé à de nombreux services Internet, tels que les serveurs Web, qui utilisent Bash pour traiter les requêtes.

Le 12 septembre 2014, Stéphane Chazelas a informé le mainteneur de Bash, Chet Ramey de sa découverte du bug original, qu'il a appelé « Bashdoor ». En collaboration avec des experts en sécurité, M. Chazelas a développé un patch (correctif) pour le problème, qui avait alors reçu l'identifiant de vulnérabilité CVE - 2014-6271 . L'existence du bug a été annoncée au public le 24/09/2014, lorsque les mises à jour de Bash avec le correctif étaient prêtes à être distribuées.

Le bug découvert par Chazelas a provoqué l'exécution involontaire de commandes par Bash lorsque ces dernières étaient concaténées à la fin des définitions de fonctions stockées dans les valeurs des variables d'environnement . Quelques jours après sa publication, diverses vulnérabilités connexes ont été découvertes ( CVE - 2014-6277, CVE-2014-6278, CVE-2014-7169, CVE-2014-7186 et CVE-2014-7187 ). Ramey a résolu ces problèmes avec une série de correctifs supplémentaires.

Les attaquants ont exploité Shellshock dans les heures qui ont suivi la divulgation initiale en créant des botnets d'ordinateurs compromis pour effectuer des attaques par déni de service distribué et des analyses de vulnérabilité . Les sociétés de sécurité ont enregistré des millions d'attaques et de sondes liées au bug dans les jours qui ont suivi la divulgation.

En raison du potentiel de compromettre des millions de systèmes non corrigés, Shellshock a été comparé au bug Heartbleed en termes de gravité.

Le bug Shellshock affecte Bash , un programme que divers systèmes basés sur Unix utilisent pour exécuter des lignes de commande et des scripts de commande. Il est souvent installé comme interface de ligne de commande par défaut du système . L'analyse de l' historique du code source de Bash montre que le bug a été introduit le 5 août 1989 et publié dans la version 1.03 de Bash le 1er septembre 1989.

Shellshock est une vulnérabilité d'exécution de code arbitraire qui permet aux utilisateurs d'un système d'exécuter des commandes qui ne devraient pas leur être accessibles. Cela se produit grâce à la fonctionnalité « Exportation de fonctions » de Bash, grâce à laquelle un processus Bash peut partager des scripts de commande avec d'autres processus Bash qu'il exécute. Cette fonctionnalité est implémentée en codant les scripts dans une table partagée entre les processus, connue sous le nom de liste de variables d'environnement . Chaque nouveau processus Bash analyse cette table à la recherche de scripts codés, assemble chacun d'eux dans une commande qui définit ce script dans le nouveau processus et exécute cette commande. Le nouveau processus suppose que les scripts trouvés dans la liste proviennent d'un autre processus Bash, mais il ne peut pas le vérifier, ni vérifier que la commande qu'il a créée est une définition de script correctement formée. Par conséquent, un attaquant peut exécuter des commandes arbitraires sur le système ou exploiter d'autres bogues qui peuvent exister dans l'interpréteur de commandes de Bash, si l'attaquant a un moyen de manipuler la liste de variables d'environnement et de provoquer l'exécution de Bash. Au moment où le bogue a été découvert, Bash était installé sur macOS et de nombreux systèmes d'exploitation Linux comme interpréteur de commandes principal, de sorte que tout programme utilisant la systemfonction pour exécuter un autre programme utiliserait Bash pour le faire.

La présence du bug a été annoncée au public le 24/09/2014, lorsque les mises à jour de Bash avec le correctif étaient prêtes à être distribuées, bien qu'il ait fallu un certain temps pour que les ordinateurs soient mis à jour pour fermer le problème de sécurité potentiel.

Dans l'heure qui a suivi l'annonce de la vulnérabilité Bash, des rapports ont fait état de machines compromises par le bug. Le 25 septembre 2014, des botnets basés sur des ordinateurs compromis par des exploits basés sur le bug ont été utilisés par des attaquants pour des attaques par déni de service distribué (DDoS) et des analyses de vulnérabilité . Kaspersky Labs a signalé que des machines compromises dans une attaque, surnommée « Thanks-Rob », menaient des attaques DDoS contre trois cibles, qu'ils n'ont pas identifiées. Le 26 septembre 2014, un botnet lié à Shellshock surnommé « wopbot » a été signalé, qui était utilisé pour une attaque DDoS contre Akamai Technologies et pour analyser le ministère de la Défense des États-Unis .

Le 26 septembre, la société de sécurité Incapsula a enregistré 17 400 attaques sur plus de 1 800 domaines Web, provenant de 400 adresses IP uniques, au cours des 24 heures précédentes ; 55 % des attaques provenaient de Chine et des États-Unis. Au 30 septembre, la société de performance de sites Web CloudFlare a déclaré qu'elle suivait environ 1,5 million d'attaques et de sondes par jour liées au bug.

Le 6 octobre, il a été largement rapporté que les serveurs Yahoo! avaient été compromis dans une attaque liée au problème Shellshock. Pourtant, le lendemain, il a été nié que c'était Shellshock qui avait spécifiquement permis ces attaques.

Serveur Web basé sur CGI

Lorsqu'un serveur Web utilise l' interface CGI (Common Gateway Interface ) pour gérer une demande de document, il copie certaines informations de la demande dans la liste des variables d'environnement, puis délègue la demande à un programme de gestion. Si le gestionnaire est un script Bash ou s'il exécute Bash, Bash recevra les variables d'environnement transmises par le serveur et les traitera comme décrit ci-dessus. Cela permet à un attaquant de déclencher la vulnérabilité Shellshock avec une demande de document spécialement conçue.

La documentation de sécurité du serveur Web Apache , très utilisé , stipule : « Les scripts CGI peuvent… être extrêmement dangereux s'ils ne sont pas soigneusement vérifiés » et d'autres méthodes de gestion des requêtes du serveur Web sont généralement utilisées à la place. Il existe un certain nombre de services en ligne qui tentent de tester la vulnérabilité des serveurs Web exposés à Internet.

Serveur OpenSSH

OpenSSH dispose d'une fonctionnalité « ForceCommand », où une commande fixe est exécutée lorsque l'utilisateur se connecte, au lieu d'exécuter simplement un shell de commande non restreint. La commande fixe est exécutée même si l'utilisateur a spécifié qu'une autre commande doit être exécutée ; dans ce cas, la commande d'origine est placée dans la variable d'environnement « SSH_ORIGINAL_COMMAND ». Lorsque la commande forcée est exécutée dans un shell Bash (si le shell de l'utilisateur est défini sur Bash), le shell Bash analysera la variable d'environnement SSH_ORIGINAL_COMMAND au démarrage et exécutera les commandes qui y sont intégrées. L'utilisateur a utilisé son accès shell restreint pour obtenir un accès shell non restreint, en utilisant le bug Shellshock.

Clients DHCP

Certains clients DHCP peuvent également transmettre des commandes à Bash. Un système vulnérable pourrait être attaqué lors de la connexion à un réseau Wi-Fi ouvert. Un client DHCP demande et obtient généralement une adresse IP auprès d'un serveur DHCP, mais il peut également se voir proposer une série d'options supplémentaires. Un serveur DHCP malveillant pourrait fournir, dans l'une de ces options, une chaîne conçue pour exécuter du code sur un poste de travail ou un ordinateur portable vulnérable.

Serveur Qmail

Lors de l'utilisation de Bash pour traiter des messages électroniques (par exemple via .forward ou qmail-alias piping), le serveur de messagerie qmail transmet une entrée externe d'une manière qui peut exploiter une version vulnérable de Bash.

Shell restreint IBM HMC

Le bug peut être exploité pour accéder à Bash depuis le shell restreint de la console IBM Hardware Management Console , une petite variante Linux destinée aux administrateurs système. IBM a publié un correctif pour résoudre ce problème.

Le responsable de Bash a été averti de la première découverte du bug le 12/09/2014 ; un correctif a rapidement suivi. Quelques entreprises et distributeurs ont été informés avant que l'affaire ne soit divulguée publiquement le 24/09/2014 avec l'identifiant CVE CVE - 2014-6271. Cependant, après la publication du correctif, des rapports ultérieurs ont fait état de vulnérabilités différentes, mais liées.

Le 26 septembre 2014, deux contributeurs open source, David A. Wheeler et Norihiro Tanaka, ont noté que des problèmes supplémentaires étaient présents, même après avoir appliqué les correctifs les plus récents sur les systèmes. Dans un courriel adressé aux listes de diffusion oss-sec et bash-bug, Wheeler a écrit : « Ce correctif ne fait que poursuivre le travail de « whack-a-mole » [ sic ] consistant à corriger les erreurs d'analyse qui ont commencé avec le premier correctif. L'analyseur de Bash est certain d'avoir de très nombreuses autres vulnérabilités ».

Le 27 septembre 2014, Michał Zalewski de Google Inc. a annoncé sa découverte d'autres vulnérabilités de Bash, l'une basée sur le fait que Bash est généralement compilé sans randomisation de la disposition de l'espace d'adressage . Le 1er octobre, Zalewski a publié les détails des bugs finaux et a confirmé qu'un correctif de Florian Weimer de Red Hat publié le 25 septembre les prévient effectivement. Il a fait cela en utilisant une technique de fuzzing à l'aide d'un utilitaire logiciel connu sous le nom d' american fuzzy lop .

Cette forme originale de la vulnérabilité ( CVE - 2014-6271) implique une variable d'environnement spécialement conçue contenant une définition de fonction exportée, suivie de commandes arbitraires. Bash exécute de manière incorrecte les commandes de fin lorsqu'il importe la fonction. La vulnérabilité peut être testée avec la commande suivante :

env x = '() { :;}; echo vulnérable' bash -c "echo ceci est un test"

Dans les systèmes affectés par la vulnérabilité, les commandes ci-dessus afficheront le mot « vulnérable » suite à l'exécution par Bash de la commande « echo vulnerable » , qui a été intégrée dans la variable d'environnement spécialement conçue nommée « x » .

Découverte par Michał Zalewski , la vulnérabilité CVE - 2014-6277, qui concerne l'analyse des définitions de fonctions dans les variables d'environnement par Bash, peut provoquer une erreur de segmentation .

Également découvert par Michał Zalewski , ce bug ( CVE - 2014-6278) concerne l'analyse des définitions de fonctions dans les variables d'environnement par Bash.

Le jour même où la vulnérabilité originale a été publiée, Tavis Ormandy a découvert ce bug associé ( CVE - 2014-7169), qui est illustré dans le code suivant :

env X = '() { (a)=>\' bash -c "écho date" ; cat echo

Sur un système vulnérable, cela exécuterait la commande « date » de manière involontaire.

Voici un exemple de système doté d'un correctif pour CVE-2014-6271 mais pas pour CVE-2014-7169 :

$ X = '() { (a)=>\' bash -c "echo date" bash : X : ligne 1 : erreur de syntaxe près du jeton inattendu `=' bash : X : ligne 1 : `' bash : erreur lors de l'importation de la définition de fonction pour `X' $ cat echo Fri Sep 26 01:37:16 UTC 2014

Le système affiche des erreurs de syntaxe, notifiant à l'utilisateur que CVE-2014-6271 a été évité, mais écrit toujours un fichier nommé « echo » dans le répertoire de travail, contenant le résultat de l'appel « date ».

Un système corrigé pour CVE-2014-6271 et CVE-2014-7169 affichera simplement le mot « date » et le fichier « echo » ne sera pas créé, comme indiqué ci-dessous :

$ X = '() { (a)=>\' bash -c "echo date" date $ cat echo cat : echo : Aucun fichier ou répertoire de ce type

Florian Weimer et Todd Sabin ont découvert ce bug ( CVE - 2014-7186), qui est lié à une erreur d'accès mémoire hors limites dans le code de l'analyseur Bash.

Un exemple de vulnérabilité, qui exploite l'utilisation de plusieurs déclarations « <<EOF» ( documents « ici » imbriqués ) :

bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' || echo "CVE-2014-7186 vulnérable, redir_stack"

Un système vulnérable affichera le texte « CVE-2014-7186 vulnérable, redir_stack ».

Également découvert par Florian Weimer, CVE - 2014-7187 est une erreur d'un octet dans le code de l'analyseur Bash, permettant un accès mémoire hors limites.

Un exemple de vulnérabilité, qui exploite l'utilisation de plusieurs déclarations « done » :

( pour x dans { 1 ..200 } ; do echo " pour x $x dans ; do : " ; terminé ; pour x dans { 1 ..200 } ; do echo terminé ; terminé ) | bash || echo " CVE-2014-7187 vulnérable, word_lineno "

Un système vulnérable affichera le texte « CVE-2014-7187 vulnérable, word_lineno ». Ce test nécessite un shell qui prend en charge l'expansion des accolades .

Jusqu'au 24 septembre 2014, le mainteneur de Bash Chet Ramey a fourni une version de correctif bash43-025 de Bash 4.3 pour CVE-2014-6271, qui était déjà empaquetée par les mainteneurs de la distribution. Le 24 septembre, bash43-026 a suivi, pour CVE-2014-7169. Puis CVE-2014-7186 a été découvert. Florian Weimer de Red Hat a publié un code de correctif pour cela « officieusement » le 25 septembre, que Ramey a incorporé dans Bash sous le nom bash43-027. — Ces correctifs ne fournissent que le code source , utile uniquement pour ceux qui savent comment compiler (« reconstruire ») un nouveau fichier exécutable binaire Bash à partir du fichier de correctif et des fichiers de code source restants. Les correctifs ont ajouté un préfixe de nom de variable lorsque les fonctions sont exportées ; cela a empêché des variables arbitraires de déclencher la vulnérabilité et a permis à d'autres programmes de supprimer les fonctions Bash de l'environnement.

Le lendemain, Red Hat a officiellement présenté les mises à jour pour Red Hat Enterprise Linux , après une autre journée pour Fedora 21. [ Canonical Ltd. a présenté les mises à jour pour ses versions Ubuntu Long Term Support le samedi 27 septembre ; le dimanche, il y avait des mises à jour pour SUSE Linux Enterprise . Le lundi et le mardi suivants, à la fin du mois, les mises à jour de Mac OS X sont apparues.

Le 1er octobre 2014, Michał Zalewski de Google Inc. a finalement déclaré que le code de Weimer et bash43-027 avaient corrigé non seulement les trois premiers bugs mais aussi les trois autres qui ont été publiés après bash43-027, y compris ses deux propres découvertes. Cela signifie qu'après les mises à jour de distribution précédentes, aucune autre mise à jour n'a été nécessaire pour couvrir les six problèmes.

Tous ces éléments ont également été abordés pour la console de gestion du matériel IBM.