Question Qu'est-ce que la vulnérabilité CVE-2014-6271 bash (Shellshock) et comment y remédier?


Récemment, il y a eu des nouvelles concernant "CVE-2014-6271" (Voir USN-2362-1), qui est une vulnérabilité dans Bash. Comment puis-je savoir si cela m'affecte, comment puis-je y remédier, et pourquoi devrais-je m'en soucier?

Ceci est conçu comme une réponse canonique à cette vulnérabilité, en raison de sa portée et de sa gravité.


140
2017-09-24 21:48


origine


"Comment je le répare?" -> lancez simplement votre gestionnaire de mise à niveau! En réalité, Ubuntu publie des mises à jour de sécurité, il y a une équipe de sécurité dédiée. S'il vous plaît ne pas poster des réponses sur la construction de Bash à partir de la source!; Il est inutile et compliqué de maintenir votre système à l'avenir. - gertvdijk
De plus, le CVE supplémentaire pour le correctif incomplet. CVE-2014-7169 - gertvdijk
S'il vous plaît faire publier des réponses sur la construction à partir des sources. Qu'elles le fassent ou non, certaines personnes ont d'anciens serveurs Ubuntu, et la construction à partir de la source peut être leur seule option. - GaryO
Oups, désolé je viens de réaliser que je mets au lieu de tiret bash dans le test. Peu importe, ça va. - Matt H
Lis: oss-sec: Re: CVE-2014-6271: exécution de code à distance via bash. Le bug Bash n'a toujours pas été corrigé - blade19899


Réponses:


Qu'est-ce que Bash?

Bash est le shell interactif par défaut dans Ubuntu. Lorsque vous effectuez l’interfaçage avec le terminal (via l’émulateur de terminal, via un tty ou ssh), vous tapez généralement des commandes bash va lire et exécuter. Même si vous n'utilisez pas du tout le terminal, vous avez toujours Bash.

Sur Ubuntu, /bin/sh n'est pas bash (c'est un tiret). Seul Bash est affecté par cette vulnérabilité.

Comment l'exploit me touche-t-il?

Bash et le système d’exploitation suivent un ensemble de Variables d'environnement qui décrivent l'utilisateur actuellement connecté, où rechercher des programmes sur le disque dur et d'autres fonctions similaires. En créant une variable d'environnement avec une structure spécifique, un attaquant pourrait exécuter du code la prochaine fois que Bash démarre.

L'attaquant peut définir cette variable d'environnement de plusieurs manières:

  • Connectez-vous à distance à un service tel que SSH avec une configuration spécifique telle que git over ssh. Comme l'indique Mitre, l'utilisation du sshd ForceCommand l'option est un vecteur d'attaque. Les comptes dont le shell n'est pas bash ne sont pas affectés.
  • Vous incitant à définir la variable d'environnement.
  • Faire en sorte qu'un autre programme définisse une variable d'environnement pour avoir cette valeur spécialement conçue. Par exemple, vous pouvez avoir un serveur Web et un script qui doivent définir une variable d'environnement avec un contenu utilisateur spécifique. Même si ce script crée ses propres et ne touche pas d'autres variables d'environnement, c'est suffisant. Une variable d'environnement unique avec n'importe quel nom et une valeur spécialement construite suffit pour que l'exploit réussisse.
  • Je n'ai pas mentionné d'autres façons ici.

Une fois qu'ils ont défini cette variable, la prochaine fois bash ouvre pour tout raison, le code de votre attaquant sera exécuté. Ceci est particulièrement effrayant avec sudo -s, car il apparaît comme le super-utilisateur (une règle d’administrateur qui a plein contrôle des données et des programmes de votre ordinateur). Même si vous ne démarrez que bash en tant qu'utilisateur standard, les fichiers de cet utilisateur peuvent être supprimés.

Il est important de noter que même si vous n'utilisez pas bash vous-même, de nombreux programmes apparaîtront par eux-mêmes dans le cadre de leur opération. Même dans ce cas, vous êtes vulnérable. Cependant, Ubuntu's /bin/sh n'est pas bash, donc seuls les programmes qui invoquent explicitement bash et non le shell de script par défaut sont affectés.

Selon Mitre:

vecteurs impliquant la fonctionnalité ForceCommand dans OpenSSH sshd, les modules mod_cgi et mod_cgid dans le serveur HTTP Apache, les scripts exécutés par des clients DHCP non spécifiés et d'autres situations dans lesquelles la configuration de l'environnement se produit à travers une limite de privilèges.

Suis-je vulnérable?

Utilisez dpkg pour vérifier la version du paquet installé:

dpkg -s bash | grep Version

Cela recherchera des informations sur votre bash package, et filtrer la sortie pour vous montrer uniquement la version. Les versions fixes sont 4.3-7ubuntu1.4, 4.2-2ubuntu2.5, et 4.1-2ubuntu3.4.

Par exemple, je vois:

wlan1-loopback% dpkg -s bash | grep Version
Version: 4.3-7ubuntu1.4

et peut déterminer que je ne suis pas vulnérable.

Comment puis-je mettre à jour?

Le gestionnaire de mise à jour standard vous proposera cette mise à jour. Ceci est un excellent exemple de la façon dont les mises à jour de sécurité sont importantes, quel que soit le système d'exploitation utilisé ou sa maintenance.

le Bulletin USN déclare que de nouvelles versions ont été publiées pour Ubuntu 14.04 Trusty Tahr, 12.04 Precise Pangolin et 10.04 Lucid Lynx. Si vous ne vous trouvez pas sur l'une de ces versions LTS, mais sur une version relativement récente, vous pourrez probablement trouver un package corrigé.

Tout d'abord, vérifiez si vous

Si vous êtes vulnérable, vous devez d'abord saisir les listes de paquets les plus récentes:

sudo apt-get update && sudo apt-get install bash

La première commande vérifie que vous disposez de la liste de packages la plus récente incluant la version corrigée et que la seconde commande installe la version la plus récente (fixe) de bash.

Bien que le bogue semble seulement entrer en jeu lorsque bash est généré, il est toujours conseillé de redémarrer immédiatement si possible.


127
2017-09-24 21:48



Pardon, vous êtes vulnérable. Le patch d'origine ne résout pas tout le problème. Voir cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7169 AFAIAA, il y a actuellement non correctif publiquement disponible. Voir par exemple people.canonical.com/~ubuntu-security/cve/pkg/bash.html - Mormegil
@ hexafraction Où lisez-vous que 12.10 reçoit une mise à jour pour cela? Je ne pense pas, 12.10, 13.04, 13.10 sont très en fin de vie! Et aussi, les dépôts de backport sont non utilisé pour les mises à jour de sécurité. - gertvdijk
@ hexafraction Non, ils ne le font pas! C'est tout l'intérêt d'être en fin de vie: plus de soutien. - gertvdijk
@ MichaelHärtl Si vous êtes sur Ubuntu 12.10, vous pouvez télécharger la version 12.04 de bash depuis packages.ubuntu.com/precise/bash et installez-le manuellement. - David
Le correctif pour CVE-2014-7169 est disponible dans le gestionnaire de mise à jour (pour moi). - Calmarius


A volé ceci de cft over chez Hacker News. Si vous avez des problèmes avec vos mises en pension comme moi (Odroid-XU), alors cela devrait fonctionner si vous voulez patcher / compiler à partir des sources.

TMPDIR=/tmp/bash-src
mkdir $TMPDIR
cd $TMPDIR
#download bash
wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
#download all patches
for i in $(seq -f "%03g" 1 999); do 
  wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i
  if [[ $? -ne "0" ]]; then
    MAX=$(expr $i - 1)
    break;
  fi
done
tar zxf bash-4.3.tar.gz 
cd bash-4.3
#apply all patches
for i in $(seq -f "%03g" 1 $MAX);do
  echo apply patch bash43-$i
  patch -p0 < ../bash43-$i
done
#build and install
./configure && make
sudo make install
cd ../..
rm -r $TMPDIR

Puis lancez:

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

Et si vous obtenez:

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

Alors vous êtes tous bons!


ATTENTION: make install installera bash dans /usr/local/bin, alors /bin/bash n'est pas modifié et peut être invoqué à partir de curl !!


27
2017-09-25 02:30



Voici comment construire bash 3.2 avec le patch sur debian lenny: gist.github.com/mattwhite/86de50d30134129e44ef - Matt White
-1. Pas besoin de construire à partir des sources. Ubuntu a un correctif de sécurité dans les référentiels. Si vous avez des "problèmes avec votre repo", corrigez cela à la place. Si vous ne recevez pas de mises à niveau de sécurité, vous serez probablement vulnérable à bien d’autres égards! - gertvdijk
@Matt White Merci! Vous venez de m'économiser quelques heures :) - Florian Fida
@FlorianFida Ceci est AskUbuntu! Tout le monde sur ce site est censé publier des réponses dans le cadre de l'utilisation d'Ubuntu. - gertvdijk
@ MichaelHärtl 12.10 est la fin de vie. Il ne reçoit plus aucune mise à jour de sécurité depuis longtemps. Améliorer!!! - gertvdijk


Remarque: Le correctif de sécurité pour CVE-2014-7169 a été publié en tant que mise à jour de sécurité standard. Il n'est pas nécessaire d'ajouter des ppa supplémentaires pour recevoir ce patch. Seuls les éléments suivants sont nécessaires.

sudo apt-get update

sudo apt-get upgrade

Pour vous assurer que vous avez correctement corrigé bash, exécutez la commande suivante

dpkg -s bash | grep Version

Si vous êtes sur 14.04 LTS, vous devriez voir un résultat de:

Version: 4.3-7ubuntu1.4

Si vous êtes sur 12.04 LTS, votre sortie devrait être:

 Version: 4.2-2ubuntu2.5

9
2017-09-25 18:30



C'était correct, mais un correctif officiel est maintenant disponible, la mise à jour de sécurité a donc été publiée. Par conséquent, ces étapes ne sont plus nécessaires. - Robie Basak
C'est correct. Je vais modifier le message ci-dessus. Je vous remercie. - branch.lizard


Si vous êtes sur 11.04: utilisez les étapes ci-dessous (cela a fonctionné pour moi)

cd ~/
mkdir bash
wget https://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
for i in $(seq -f "%03g" 0 25); do wget https://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done

si le fichier requis n'est pas téléchargé, installez le package ftp

apt-get install ftp
for i in $(seq -f "%03g" 0 25); do wget https://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done
tar zxvf bash-4.3.tar.gz
cd bash-4.3
for i in $(seq -f "%03g" 0 25);do patch -p0 < ../bash43-$i; done
./configure && make && make install
apt-get install build-essential
./configure && make && make install

Pour voir si le patch a été appliqué:

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

1
2017-09-25 17:13





J'utilise Natty 11.04, qui est EOL (et j'ai mis à jour /etc/apt/sources.list pour utiliser old-releases.ubuntu.com), je dois donc créer à partir des sources. Je voulais créer un fichier .deb, donc au moins la gestion des paquets est "consciente" que la version bash n'est pas la version par défaut. Je ne suis pas à 100% réussi - cependant, le paquet est enregistré comme "plus récent" et le bash binaire se termine fixé, alors voici ce que j'ai fait:

apt-get source bash
wget https://gist.githubusercontent.com/drj11/e85ca2d7503f28ebfde8/raw/31bd53ed2e47b220d3c728f5440758e0f76769de/gistfile1.c -O bash_CVE-2014-6271.patch
wget https://gist.githubusercontent.com/drj11/239e04c686f0886253fa/raw/046e697da6d4491c3b733b0207811c55ceb9d927/gistfile1.c -O bash_CVE-2014-6271_plus.patch
cd bash-4.2/

Maintenant, dans le (sous) répertoire bash-4.2/, il y a: un fichier bash-4.2.tar.xz, qui doit être déballé pour arriver au bash la source; et un sous-répertoire appelé debian.

J'ai apporté les modifications suivantes pour éviter les dépendances sur texlive: dans bash-4.2/debian/control:

Source: bash
...
Build-Depends: autoconf, autotools-dev, patch, bison, libncurses5-dev,
# texinfo, debhelper (>= 5), texi2html, locales, gettext, sharutils, time, xz-ut
ils
 debhelper (>= 5), locales, gettext, sharutils, time, xz-utils
# Build-Depends-Indep: texlive-latex-base, ghostscript
Build-Depends-Indep: ghostscript

... et en bash-4.2/debian/rules:

binary-doc: bash-install #bash-doc-build
        dh_testdir
        dh_testroot
        mkdir -p $(d_doc)/usr/share/doc/$(p)
        dh_installdocs -p$(p_doc) 
ifeq ($(with_gfdl),yes)
        #cp -p build-bash/doc/bashref.pdf $(d_doc)/usr/share/doc/$(p)/.
        #dh_link -p$(p_doc) \
        #    /usr/share/doc/$(p)/bashref.pdf /usr/share/doc/$(p_doc)/bashref.pdf
else
        rm -f $(d_doc)/usr/share/doc-base/bashref
endif
        rm -f $(d_doc)/usr/share/info/dir*
        #cp -p build-bash/doc/bash.html build-bash/doc/bash.pdf \
        #    $(d_doc)/usr/share/doc/$(p)/
        #dh_link -p$(p_doc) \
        #    /usr/share/doc/$(p)/bash.html /usr/share/doc/$(p_doc)/bash.html \
        #    /usr/share/doc/$(p)/bash.pdf /usr/share/doc/$(p_doc)/bash.pdf
        dh_installchangelogs -p$(p_doc) bash/CWRU/changelog
        ...

Pour changer la version, dans cette bash-4.2/ répertoire, faire:

bash-4.2$ dch --local patchCVE

... et remplissez les notes dans le journal des modifications lorsque demandé. Cela garantira que le .deb (et les métadonnées associées) est appelé (dans mon cas) bash_4.2-0ubuntu3patchCVE1_i386.deb.

Ensuite, vous pouvez essayer de construire avec dpkg-buildpackage -us -uc ou debuild commander. Note - l'un ou l'autre re-décompactera la source du zip - remplaçant ainsi tous les patchs que vous avez pu avoir! Néanmoins, exécutez l’une d’elles une fois pour que la source soit décompressée et construite (note debuild peut encore échouer à la fin en raison de texlive, mais il devrait décompresser et construire la source).

Ensuite, appliquez les patchs; notez que vous devriez utiliser -p1 ici, parce que vous êtes actuellement dans le bash-4.2/ annuaire:

bash-4.2$ patch -p1 < ../bash_CVE-2014-6271.patch 
bash-4.2$ patch -p1 < ../bash_CVE-2014-6271_plus.patch 

Ensuite, reconstruisez la version corrigée en exécutant:

bash-4.2$ fakeroot debian/rules build 

Cela reconstruirait l'exécutable; pour le tester:

bash-4.2$ env VAR='() { :;}; echo Bash is vulnerable!' ./build-bash/bash -c "echo Bash Test"

Pour générer les fichiers .deb, exécutez:

bash-4.2$ fakeroot debian/rules binary

Cela va enregistrer les fichiers .deb dans le répertoire parent; pour lister leur contenu:

bash-4.2$ dpkg -c ../bash_4.2-0ubuntu3patchCVE1_i386.deb

Pour installer le .deb:

bash-4.2$ sudo dpkg -i ../bash_4.2-0ubuntu3patchCVE1_i386.deb

Cependant, pour une raison quelconque, ce fichier .deb contient un fichier binaire non corrigé (?!), Je devais donc en plus:

bash-4.2$ sudo cp bash-4.2/build-bash/bash /bin/

... et après cela, le test a commencé à passer correctement pour moi:

$ env VAR='() { :;}; echo Bash is!' bash -c "echo Bash Test"
bash: warning: VAR: ignoring function definition attempt
bash: error importing function definition for `VAR'
Bash Test

0
2017-09-28 10:16



Question: La question d'origine indique 1 vecteur d'attaque possible en tant que "scripts exécutés par des clients DHCP non spécifiés". Qu'est-ce que ça veut dire? Est-ce que cela signifie que / sbin / dhclient <- d'Ubuntu est vulnérable? - Bran
Je pense que les clients non spécifiés signifient que Ubuntu a un / sbin / dhclient infecté, qui exécute alors des commandes qui mènent au script bash qui lance le shellshock. Est-ce ce que les clients DHCP sont vulnérables aux shellshocks? (J'espère que cela a du sens, voir mon message ci-dessus du 10 octobre) - Bran