web-dev-qa-db-fra.com

Qu'est-ce que la vulnérabilité CVE-2014-6271 bash (Shellshock) et comment la réparer?

Récemment, il y a eu des nouvelles concernant "CVE-2014-6271" (voir SN-2362-1 ), qui est une vulnérabilité de Bash. Comment savoir si cela me concerne, comment puis-je régler le problème 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é.

bashsecurityshellshock
141
hexafraction

Qu'est ce que Bash?

Bash est le shell interactif par défaut sous Ubuntu. Lorsque vous vous connectez au terminal (via l'émulateur de terminal, sur un tty ou sur ssh), vous tapez généralement des commandes que bash lira et exécutera. 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). Seule bash est affectée par cette vulnérabilité.

Comment l'exploit m'affecte-t-il?

Bash et le système d’exploitation suivent un ensemble de variables d’environnement ​​décrivant l’utilisateur actuellement connecté, où rechercher les programmes sur le disque dur et d’autres fonctions similaires. En fabriquant une variable d’environnement avec une structure spécifique, un attaquant pourrait éventuellement exécuter du code au prochain démarrage de Bash.

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 Mitre le signale, l'utilisation de l'option sshd ForceCommand est un vecteur d'attaque. Les comptes dont Shell n'est pas bash ne sont pas affectés.
  • Vous incitant à définir la variable d'environnement.
  • Causer un autre programme pour définir une variable d'environnement pour avoir cette valeur spécialement construite. 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 le sien et ne touche pas d’autres variables d’environnement, cela suffit. ne seule variable d'environnement avec n'importe quel nom et une valeur spécialement construite suffit à l'exploit pour réussir.
  • Autres moyens que je n'ai pas mentionnés ici.

Une fois qu'ils ont défini cette variable, la prochaine fois que bash s'ouvre pour la raison any, le code de votre attaquant sera exécuté. Ceci est particulièrement inquiétant avec Sudo -s, car il génère bash en tant que super-utilisateur (une règle d'utilisateur administratif qui contrôle tout le 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 d'eux-mêmes dans le cadre de leur fonctionnement. Même dans ce cas, vous êtes vulnérable. Cependant, le /bin/sh d'Ubuntu n'étant pas bash, seuls les programmes qui appellent explicitement bash et non le shell de script par défaut sont concernés.

Selon Mitre:

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

Suis-je vulnérable?

Utilisez dpkg pour vérifier la version de votre paquet installé:

dpkg -s bash | grep Version

Cela recherchera des informations sur votre paquet bash et filtrera la sortie pour ne vous montrer que la version. Les versions corrigées 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 l'importance des mises à jour de sécurité, quel que soit le système d'exploitation utilisé ou la qualité de la maintenance.

Le SN Bulletin indique 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 possédez pas l'une de ces versions LTS, mais une version relativement récente, vous serez probablement en mesure de trouver un package corrigé.

Tout d'abord, vérifiez si vous

Si vous êtes vulnérable, vous devez d’abord récupérer les dernières listes de paquets:

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 qui inclut la version corrigée, et la seconde commande installe la version la plus récente (corrigée) de bash.

Bien que le bogue ne semble entrer en jeu que lorsque bash est créé, il est toujours judicieux de redémarrer immédiatement si possible.

126
hexafraction

J'ai volé ça hors de plus chez Hacker News . Si vous avez des problèmes avec votre mise en pension comme moi (Odroid-XU), cela devrait fonctionner si vous souhaitez appliquer des correctifs/construire à 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!

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

27
Bobby Saget

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 d’autres PPA pour recevoir ce correctif. Seul le suivant est nécessaire.

Sudo apt-get update

Sudo apt-get upgrade

Pour vous assurer que bash est corrigé correctement, 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
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 ce n'est pas téléchargé le correctif requis, installez le paquet 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 correctif a été appliqué:

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

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 compiler à partir des sources. Je voulais construire un fichier .deb, donc au moins le paquet géré est "conscient" que la version bash n'est pas celle par défaut. Je ne réussis pas à 100%. Cependant, le paquet est enregistré comme "plus récent" et le binaire bash finit par être corrigé. 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écompressé pour accéder à la source bash; et un sous-répertoire appelé debian.

J'ai apporté les modifications suivantes pour éviter les dépendances sur texlive: in 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 dans 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 de version, dans ce répertoire bash-4.2/, procédez comme suit:

bash-4.2$ dch --local patchCVE

... et remplissez les notes dans le journal des modifications lorsque cela vous est 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 la commande dpkg-buildpackage -us -uc ou debuild. Remarque - l'un ou l'autre va décompresser le code source du fichier Zip - annulant ainsi les correctifs que vous avez pu avoir! Néanmoins, exécutez l’une de ces méthodes une fois pour que la source soit décompressée et générée (notez que debuild peut toujours échouer à la fin en raison de texlive, mais il devrait décompresser et générer le source).

Ensuite, appliquez les patchs; notez que vous devriez utiliser -p1 ici, car vous vous trouvez actuellement dans le répertoire bash-4.2/:

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

Reconstruisez ensuite la version corrigée en lançant:

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 construire les fichiers .deb, exécutez:

bash-4.2$ fakeroot debian/rules binary

Cela enregistrera 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 quelque raison que ce soit, ce .deb contient un binaire non corrigé (?!), Je devais donc aussi:

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
sdaau