URL: https://linuxfr.org/news/une-faille-nommee-shellshock Title: Une faille nommée « shellshock » Authors: Collectif bubar🦥, Benoît Sibaud, esdeem, Altor, david.g, Bruno Michel, Salk, Maxime, palm123 et BAud Date: 2014年09月27日T10:29:03+02:00 License: CC By-SA Tags: shellshock, bash, cve-2014-6271, cve-2014-7169, selinux, sécurité et cve Score: 82 « 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](http://fr.wikipedia.org/wiki/Obusite) des combattants de la première guerre mondiale et l'interface système [shell](http://fr.wikipedia.org/wiki/Shell_(informatique)). 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. ---- [Redhat : Frequently Asked Questions about the Shellshock Bash flaws](https://securityblog.redhat.com/2014/09/26/frequently-asked-questions-about-the-shellshock-bash-flaws/) [Redhat : Bash specially-crafted environment variables code injection attack](https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/) [Annonce initiale sur la liste Open Source Security](http://seclists.org/oss-sec/2014/q3/650) [CERTFR-2014-ALE-006 : Vulnérabilité dans GNU bash](http://www.cert.ssi.gouv.fr/site/CERTFR-2014-ALE-006/index.html) [ShellShock.fr : explications et testeur en ligne](http://www.shellshock.fr/) [GitHub : Security vulnerability in bash addressed](https://github.com/blog/1893-security-vulnerability-in-bash-addressed) [Shellshock DHCP RCE Proof of Concept](https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/) [Journal initial sur LinuxFr.org : Mets à jour ton bash. Maintenant.](http://linuxfr.org/users/tankey/journaux/mets-a-jour-ton-bash-maintenant) [Free Software Foundation statement on the GNU Bash "shellshock" vulnerability ](http://www.fsf.org/news/free-software-foundation-statement-on-the-gnu-bash-shellshock-vulnerability) [01Net : Interview exclusive: « J’ai découvert la faille Shellshock par hasard »](http://www.01net.com/editorial/627624/j-ai-decouvert-la-faille-shellshock-par-hasard/) [shellshocker.net : explications et testeur en ligne](https://shellshocker.net/) ---- ## 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](http://ubuntu.com) 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** ```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 : mafonction ``` **La même chose, pour passer la fonction à un sous-shell** ```shell env mafonction='() { echo "bonjour vous"; }' bash -c 'mafonction;' ``` On préfixe 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** ```shell 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 : ```shell 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/sh` pointe 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](https://github.com/mubix/shellshocker-pocs) À 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](http://danwalsh.livejournal.com/) à 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](http://www.qnap.com/useng/index.php?lang=en-us&sn=885&c=3036&sc=&n=22457) (cf [article Next INpact](http://www.nextinpact.com/news/90133-faille-bash-nas-ne-sont-pas-epargnes.htm)) ## Chronologie des évènements - Stéphane Chazelas rapporte le problème à Redhat (bug déclaré le [14 septembre](https://bugzilla.redhat.com/show_bug.cgi?id=1141597)) ; - Le CVE-2014-6271 lui est attribué ; - Le 24 septembre, ce [CVE](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271) 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](https://cve.mitre.org/cgi-bin/cvename.cgi?name=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 : - [Debian](https://www.debian.org/security/2014/dsa-3032) - Ubuntu [1](http://www.ubuntu.com/usn/usn-2363-1/) et [2](http://www.ubuntu.com/usn/usn-2363-2/) - Redhat [1](https://rhn.redhat.com/errata/RHSA-2014-1293.html), [2](https://rhn.redhat.com/errata/RHSA-2014-1294.html) et [3](https://rhn.redhat.com/errata/RHSA-2014-1295.html), - [Mageia](http://advisories.mageia.org/MGASA-2014-0388.html) - [Suse](http://support.novell.com/security/cve/CVE-2014-6271.html) - Fedora [1](https://lists.fedoraproject.org/pipermail/package-announce/2014-September/138675.html), [2](https://lists.fedoraproject.org/pipermail/package-announce/2014-September/138583.html) et [3](https://lists.fedoraproject.org/pipermail/package-announce/2014-September/139077.html) - [ArchLinux](https://lists.archlinux.org/pipermail/arch-security/2014-September/000099.html) - [Gentoo](http://www.gentoo.org/security/en/glsa/glsa-201409-09.xml) - etc... #### Le second problème, CVE-2014-7169 - Le test : ``cd /tmp; rm -f echo; env 'x=() { (a)=>\' bash -c "echo date"; cat echo`` doit retourner que le fichier "/tmp/echo" n'existe pas. - Les annonces : - [Debian](https://www.debian.org/security/2014/dsa-3035) - [Ubuntu](http://www.ubuntu.com/usn/usn-2364-1/) - Redhat [1](https://rhn.redhat.com/errata/RHSA-2014-1306.html), [2](https://rhn.redhat.com/errata/RHSA-2014-1311.html) et [3](https://rhn.redhat.com/errata/RHSA-2014-1312.html) - [Mageia](http://advisories.mageia.org/MGASA-2014-0393.html) - Suse [1](http://support.novell.com/security/cve/CVE-2014-7169.html), [2](http://support.novell.com/security/cve/CVE-2014-7187.html) et [3](http://support.novell.com/security/cve/CVE-2014-7187.html) - Fedora [1](https://lists.fedoraproject.org/pipermail/package-announce/2014-September/138679.html), [2](https://lists.fedoraproject.org/pipermail/package-announce/2014-September/138687.html) et [3](https://lists.fedoraproject.org/pipermail/package-announce/2014-September/139129.html) - [ArchLinux](https://lists.archlinux.org/pipermail/arch-security/2014-September/000099.html) - [Gentoo](http://www.gentoo.org/security/en/glsa/glsa-201409-10.xml) - etc.. #### Les [CVE-2014-6277](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6277), [CVE-2014-7186](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7186) et [CVE-2014-7187](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7187) ne sont pas publics à ce jour (infos chez Redhat [0](https://access.redhat.com/security/cve/CVE-2014-6277), [1](https://bugzilla.redhat.com/show_bug.cgi?id=1146791) et [2](https://bugzilla.redhat.com/show_bug.cgi?id=1146804)). - 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é](https://svnweb.freebsd.org/ports?view=revision&revision=369341) 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](http://www.ft.com/cms/s/0/27961e52-44d9-11e4-ab0c-00144feabdc0.html) - [traduite en français par l'April](http://www.april.org/declaration-de-la-free-software-foundation-sur-la-faille-shellblock-de-gnu-bash)), la presse spécialisée puis la presse généraliste ont multiplié les articles : pire que la faille Heartbleed ? ([Slate.fr](http://www.slate.fr/story/92601/bash-nouveau-bug-pire-heartbleed), [LMI](http://www.lemondeinformatique.fr/actualites/lire-plus-grave-que-heartbleed-la-faille-shellshock-affecte-l-interpreteur-bash-de-gnu-linux-et-mac-os-x-58751.html), [Silicon.fr](http://www.silicon.fr/shell-shock-faille-bash-hauteur-heartbleed-96976.html), [L'Express](http://lexpansion.lexpress.fr/high-tech/shellshock-une-faille-informatique-plus-grave-que-heartbleed_1579286.html), [20minutes](http://www.20minutes.fr/high-tech/1449883-20140925-bash-bug-vraiment-pire-heartbleed), [HuffingtonPost](http://www.huffingtonpost.com/2014/09/25/shellshock-bug_n_5883474.html), [New Zealand Herald](http://www.nzherald.co.nz/business/news/article.cfm?c_id=3&objectid=11331892)), « _panique_ » ([Courrier International](http://www.courrierinternational.com/article/2014/09/26/shellshock-la-faille-qui-seme-la-panique)), « _mégafaille_ » ([01Net](http://www.01net.com/editorial/627512/la-megafaille-shellshock-secoue-le-monde-linux-et-max-os/)), « horrible » ([ZdNet](http://www.zdnet.fr/actualites/decryptage-shell-shock-un-obus-dans-les-dents-de-bash-39806945.htm)), « _premières attaques_ » ([01net](http://www.01net.com/editorial/627588/shellshock-les-premieres-attaques-deferlent-sur-la-toile/)), « _plus grande menace de l'histoire du web_ » ([ParisMatch](http://www.parismatch.com/Actu/International/Shellshock-La-plus-grande-menace-du-l-histoire-du-Web-600178), si si), « _500 millions de serveurs web vulnérables_ » ([La Tribune](http://www.latribune.fr/technos-medias/internet/20140926tribaba365da3/shellshock-500-millions-de-serveurs-web-seraient-vulnerables-a-cette-faille.html), [Washington Post](http://www.washingtonpost.com/news/morning-mix/wp/2014/09/26/shellshock-bug-affects-macs-and-many-other-internet-connected-devices/)), « _Google et Amazon ont patchés_ » - super on est sauvés alors - ([WallStreetJournal](http://blogs.wsj.com/digits/2014/09/25/google-and-amazon-respond-to-shellshock-security-flaw/)), d'autres failles Bash à prévoir ([ArsTechnica](http://arstechnica.com/security/2014/09/still-more-vulnerabilities-in-bash-shellshock-becomes-whack-a-mole/)), « _ver fou ShellShock_ » ([Wired](http://www.wired.com/2014/09/internet-braces-crazy-shellshock-worm/) ou le [blog de R. Graham](http://blog.erratasec.com/2014/09/bash-shellshock-bug-is-wormable.html)), « _internet bâti sur de la glace fine_ » ([Financial Times](http://www.ft.com/cms/s/0/27961e52-44d9-11e4-ab0c-00144feabdc0.html)), 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](https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=bash) est forcément très sûr, peut-être que personne ne l'avait vraiment regardé jusque là.

AltStyle によって変換されたページ (->オリジナル) /