Passer au contenu

ShellShock : une nouvelle faille pire qu’Heartbleed qui affecte les systèmes Unix, Linux et Mac OS X

Il faut s’attendre à un séisme d’une amplitude inégalée avec la découverte de la faille Shellshock qui affecte les systèmes Unix, Linux et Mac OS X….

Il faut s’attendre à un séisme d’une amplitude inégalée avec la découverte de la faille Shellshock qui affecte les systèmes Unix, Linux et Mac OS X. Selon Trend Micro, elle va impacter près d’un demi-milliard de serveurs web et d’objets connectés tels que les téléphones portables, routers et appareils médicaux.

Alors que la fameuse vulnérabilité HeartBleed n’impactait que la confidentialité des données, les conséquences de la vulnérabilité de la faille Shellshock seront d’autant plus fortes car l’attaque est réalisable via le réseau et permet d’exécuter du code à distance. Un cyber attaquant pourra ainsi impacter l’accessibilité, l’intégrité et la confidentialité des données.

shellshock-usa


Qu’est-ce que bash ?

Bash est à la fois un langage de programmation et ce qu’on appelle un shell. Un shell est une interface qui permet à un humain de dialoguer avec un ordinateur. (au lieu de cliquer sur des icônes et dans des fenêtres, on envoie des commandes à cette interface). Bash est très utilisé sur les serveurs Linux mais on retrouve aussi sur les serveurs Unix et BSD.

Quel est le principe de la vulnérabilité ?

Lors de l’exécution d’un programme bash, ce dernier charge des variables d’environnent. La valeur de cette variable peut être statique, mais bash autorise aussi à charger des fonctions. C’est dans le parsing de cette fonction que réside le problème. En effet un attaquant peut injecter des commandes à la fin de la fonction :

Env_Variable=’() { };

Que faut-il pour la vulnérabilité puisse être exploitée ?

Il faut que bash récupère une variable qui est défini par l’utilisateur. Cette variable peut être récupérée par exemple dans une session SSH, via un client SNMP mais il est probable que le principal vecteur d’exploitation soit le WEB.

Quel est l’impact de cette vulnérabilité ?

L’impact est extrêmement fort, car l’attaque est réalisable via le réseau et elle permet d’exécuter du code à distance. Ce qui permet à un attaquant d’impacter l’accessibilité, l’intégrité et la confidentialité des données. A titre de comparaison, la fameuse vulnérabilité HeartBleed n’impactait que la confidentialité. Et bash est très répandu…

🟣 Pour ne manquer aucune news sur le Journal du Geek, abonnez-vous sur Google Actualités. Et si vous nous adorez, on a une newsletter tous les matins.

20 commentaires
  1. ça cassera le mythe infondé qu’il n’y a pas de virus sur Linux et autres systèmes UNIX car il y a aussi pas mal de failles sur Linux (aucun système n’est infaillible).

    Un dev.

  2. ShellShock : une nouvelle faille _PIRE_ qu’Heartbleed qui affecte les systèmes Unix, Linux et Mac OS X

    Mouais …
    Certes les impacts lors d’une exploitation sont plus importants mais le périmètre des systèmes concernés est beaucoup plus faible, l’automatisation de l’exploit par des robots nettement plus complexe et aléatoire et surtout, une fois la faille patchée, vous êtes protégés, ce qui n’était pas le cas d’Heartbleed si vos clés privées avaient été aspirées.

  3. Vuais, on est entrain de tout mettre à jour chez nous :p

    Et +1 pour 8lack, le risque 0 n’existe pas et n’existera jamais.

  4. Bash sous Unix ? J’ai des doutes …
    KSH pour les HP-Ux
    Tcsh pour freebsd …

    Faites le test sur votre serveur:

    env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”

    @++

  5. @dino : bash existe sous Unix, la plupart du temps les systèmes UNIX ont KSH par défaut mais même dans ce cas ça n’empêche pas d’avoir également bash à côté. Suffit qu’il soit installé pour que la faille soit exploitable.

  6. @clymB : Oui, j’ai vu ça hier, mais il fallait compiler soi-même le patch sur Linux. Sinon, mise à jour faite ce matin dans ma boîte. Serveur RHEL 😀
    Des patchs sont déjà déployés sur les distris Debian, RedHat, Fedora, Ubuntu et CentOS.

    @djay : Non, pas une news à troll. Il y a une faille, autant la signaler. Surtout qu’elle est vraiment critique.

  7. Oui y a des failles dans le libre mais au moins on est informé dés leurs découvertes et les màj sont rapides.
    Par contre je suis même pas sûr qu’un serveur apache brut d’installation risque réellement quelque chose…
    En tous les cas ça me paraît bien moins grave que heartbleed, faudrait revoir le titre. Entre une potentielle attaque sur un serveur qui demande un minimum de temps humain et la mise à mal de l’ensemble des échanges cryptées y a un océan non?

  8. 8lack 0ut, ça fait un bail que les virus sont existant sur Linux et tout ses dérivés, ça fait longtemps que cette “Légende Urbaine” n’à pu lieu d’être, j’pense pas qu’un Linuxien pense qu’il soit à l’abris des virus… C’est juste que c’est moins visé que Windaube ou Macintosh, même si la tendance s’inverse au fur et à mesure que le temps passe.

  9. Moue moue moue tout ca me laisse dubitatif et pue le troll.

    heartbleed affectait les certificats SSL qui ont donc vocation a être accessible publiquement tandis que bash est un shell…un shell n’a pas vocation à etre publique…avant de l’atteindre il faut par exemple passer par ssh

    Alors oui aucun système n’est infaillible mais comparer une faille d’un service (openssl donc) accessible publiquement dans la majorité des cas et un shell qui n’a pas vocation à etre publique (mis a part dans un environnement mutualisé comme une plateforme de dev par exemple), c’est assez “lol” de mon point de vue

    ca revient par exemple au meme de dire “mon dieu, une faille permet a des pirates d’acceder a la gestion d’eau chaude du batiment” mais si il n’ont aucun acces au batiment, en quoi cela peut vous affecter? => en rien

    et ceci n’a rien d’un troll…

    un admin sys

  10. De plus la faille permet juste d’executer du code arbitraire, ce qui est déjà énorme, mais pas directement de faire une excalation de droits. Donc meme au pire si vous faites tourner un serveur web avec du bash (genre en CGI mais faut déjà être assez con), vous ne serez pas pour autant en mesure de tout faire avec cette faille…

    Pis bon, déjà corrigée alors…

  11. Précisons tout de même que pour que la sécurité soit totalement compromise, il faut que la machine soit un serveur (qu’elle accepte des requêtes par des non-utilisateurs), qu’elle permette de définir des variables d’environnement à partir desdites requêtes, et que tout ça se passe en root (la possibilité de définir des variables d’environnement en root étant déjà un problème en soit).

  12. D’accord avec Ted et Bainos. On ne peut nier l’existence d’une faille de sécurité. Pour qu’elle soit grave, il faut déjà avoir un accès au serveur, donc il est déjà compromis, avant même exploitation exploitation d’icelle.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *