Récemment, des nouvelles ont circulé concernant "CVE-2014-6271" (Voir USN-2362-1 ), qui est une vulnérabilité dans Bash. Comment puis-je savoir si je suis affecté par cette vulnérabilité, comment puis-je la corriger et pourquoi devrais-je m'en soucier ?
Ceci est conçu comme une réponse canonique pour cette vulnérabilité, en raison de sa portée et de sa gravité.
Bash est le Shell interactif par défaut dans Ubuntu. Lorsque vous vous interfacez avec le terminal (que ce soit via l'émulateur de terminal, sur un tty ou par ssh), vous tapez généralement des commandes qui bash va lire, et exécuter. Même si vous n'utilisez pas du tout le terminal, vous disposez toujours de Bash.
Sur Ubuntu, /bin/sh n'est pas bash (c'est dash). Seul bash est concerné par cette vulnérabilité.
Bash et l'OS gardent la trace d'un ensemble de variables d'environnement qui décrivent l'utilisateur actuellement connecté, où chercher des programmes sur le disque dur, et d'autres fonctions de ce type. En fabriquant une variable d'environnement avec une structure spécifique, un attaquant pourrait être en mesure d'exécuter du code au prochain démarrage de Bash.
L'attaquant peut définir cette variable d'environnement de plusieurs façons :
ForceCommand est un vecteur d'attaque. Les comptes dont Shell n'est pas bash ne sont pas affectés.Une fois qu'ils ont défini cette variable, la prochaine fois bash s'ouvre pour tout raison, le code de votre attaquant sera exécuté. Ceci est particulièrement redoutable avec sudo -s car il crée bash en tant que super-utilisateur (une règle d'utilisateur administratif qui a le droit d'utiliser le logiciel). complet le contrôle des données et des programmes de votre ordinateur). Même si vous ne démarrez bash qu'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 feront apparaître bash d'eux-mêmes dans le cadre de leur fonctionnement. Même dans ce cas, vous êtes vulnérable. Cependant, le programme Ubuntu /bin/sh n'est pas bash, donc seuls les programmes qui invoquent explicitement bash et non le script par défaut Shell sont affectés.
Selon Mitre :
vecteurs impliquant la fonction ForceCommand dans OpenSSH sshd, les modules mod_cgi et mod_cgid dans le serveur HTTP Apache, 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 frontière de privilèges de l'exécution de Bash.
Utilisez dpkg pour vérifier la version de votre paquet installé :
dpkg -s bash | grep VersionCela va chercher des informations sur votre bash et filtrer la sortie pour ne vous montrer que la version. Les versions fixes sont 4.3-7ubuntu1.4 , 4.2-2ubuntu2.5 y 4.1-2ubuntu3.4 .
Par exemple, je vois :
wlan1-loopback% dpkg -s bash | grep Version
Version: 4.3-7ubuntu1.4et peut déterminer que je ne suis pas vulnérable.
Le gestionnaire de mise à jour standard vous proposera cette mise à jour. Cet exemple illustre parfaitement l'importance des mises à jour de sécurité, quel que soit le système d'exploitation que vous utilisez ou son niveau de maintenance.
El Bulletin de l'USN 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 n'êtes pas sur l'une de ces versions LTS, mais que vous êtes sur une version raisonnablement récente, vous serez très probablement en mesure de trouver un paquet corrigé.
Tout d'abord, vérifiez si vous
Si vous êtes vulnérable, vous devez d'abord récupérer les listes de paquets les plus récentes :
sudo apt-get update && sudo apt-get install bashLa première commande s'assure que vous avez la liste de paquets 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 lancé, il est toujours préférable de redémarrer immédiatement si possible.
J'ai volé ça sur cft sur Hacker News . Si vous avez des problèmes avec vos dépôts comme moi (Odroid-XU), alors cela devrait bien fonctionner si vous voulez patcher/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 $TMPDIRAlors cours :
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 testAlors tout va bien !
AVERTISSEMENT : make install installera bash dans /usr/local/bin donc /bin/bash n'est pas modifié et peut être invoqué depuis curl ! !!
Remarque : le correctif de sécurité pour CVE-2014-7169 a été publié comme une mise à jour de sécurité standard. Il n'est pas nécessaire d'ajouter des ppa supplémentaires pour recevoir ce correctif. Seuls les éléments suivants sont nécessaires.
sudo apt-get update
sudo apt-get upgradePour vous assurer que vous avez patché bash correctement, exécutez la commande suivante
dpkg -s bash | grep VersionSi vous êtes sur 14.04 LTS, vous devriez voir une sortie de :
Version: 4.3-7ubuntu1.4Si vous êtes sur 12.04 LTS, votre sortie devrait être :
Version: 4.2-2ubuntu2.5
Si vous êtes sur 11.04 : utilisez les étapes suivantes (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; dones'il n'est pas téléchargé le patch requis alors 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 installPour voir si le patch a été appliqué :
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
J'utilise Natty 11.04, qui est EOL (et j'ai mis à jour /etc/apt/sources.list pour utiliser old-releases.ubuntu.com), donc je dois construire à partir des sources. Je voulais construire un .deb, pour qu'au moins le gestionnaire de paquets soit "conscient" que la version de bash n'est pas celle par défaut. Je n'ai pas réussi à 100% - cependant, le paquet est enregistré comme "plus récent" et l'icône bash binaire finit par être réparé, 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écompressé pour atteindre le fichier bash et un sous-répertoire appelé debian .
J'ai fait les changements suivants 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 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 la version, dans ce bash-4.2/ répertoire, faites :
bash-4.2$ dch --local patchCVE... et remplissez les notes dans le changelog quand on vous le demande. Cela garantira que le fichier .deb (et les métadonnées associées) est appelé (dans mon cas) bash_4.2-0ubuntu3patchCVE1_i386.deb .
Vous pouvez alors essayer de construire avec dpkg-buildpackage -us -uc ou debuild commande. Remarque - l'une ou l'autre de ces commandes déballera à nouveau les sources à partir du zip, ce qui annulera tous les correctifs que vous auriez pu avoir ! Lancez quand même l'une de ces commandes une fois pour que les sources soient décompressées et construites (remarque debuild peut encore échouer à la fin à cause de texlive, mais il devrait décompresser et construire la source).
Ensuite, appliquez les correctifs ; notez que vous devriez utiliser -p1 ici, parce qu'actuellement vous êtes dans le bash-4.2/ répertoire :
bash-4.2$ patch -p1 < ../bash_CVE-2014-6271.patch
bash-4.2$ patch -p1 < ../bash_CVE-2014-6271_plus.patch Puis reconstruire 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 construire les fichiers .deb, exécutez :
bash-4.2$ fakeroot debian/rules binaryCela permettra d'enregistrer les fichiers .deb dans le répertoire parent ; pour lister leur contenu :
bash-4.2$ dpkg -c ../bash_4.2-0ubuntu3patchCVE1_i386.debPour installer le fichier .deb :
bash-4.2$ sudo dpkg -i ../bash_4.2-0ubuntu3patchCVE1_i386.debCependant, pour une raison quelconque, ce .deb contient un binaire non corrigé ( ?!), et j'ai donc dû le faire 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 TestSystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
