Comment fonctionne CVE-2014-7169? Répartition du code de test

L’insecte

CVE-2014-7169 est un bogue dans l’parsingur de bash. L’parsingur de Bash utilise une variable eol_ungetc_lookahead pour annuler les caractères sur les lignes. Cette variable n’était pas correctement réinitialisée à partir de la fonction reset_parser , appelée par exemple sur certaines erreurs de syntaxe. En utilisant ce bogue, il est possible d’injecter un caractère au début de la prochaine ligne d’entrée bash.

Le code de test force donc une erreur de syntaxe, en utilisant soit (a)= ou la function aa , ajoute le caractère de redirection à append à la ligne suivante > , et ajoute une ligne continue \ , qui mène à la version du code de test:

 () { (a)=>\ () { function a a>\ 

Lorsque bash est exécuté, il traite les variables de l’environnement, trouve que la variable X est une fonction exscope et l’évalue pour importer la fonction. Mais l’évaluation échoue avec une erreur d’parsing, laissant le caractère > dans la variable eol_ungetc_lookahead . Ensuite, lors de l’parsing syntaxique de l’argument echo date , il ajoute le caractère > , conduisant à >echo date , la date exécution redirigée vers un fichier nommé echo .

Sa relation avec le bug précédent

Le bogue ci-dessus est évidemment très différent du bogue original de shellshock. Il y a effectivement plusieurs problèmes:

• Bash évalue complètement une variable qui ressemble à une fonction exscope (commence par les quatre caractères () { ). CVE-2014-6271.
• Dans certaines conditions, il est possible d’injecter un caractère dans une variable ungetc, qui sera ajoutée à la ligne suivante. CVE-2014-7169.
• Bash permet de traiter chaque variable d’environnement comme une fonction exscope, à condition qu’elle commence par les quatre caractères () { . CVE-2014-6271, CVE-2014-7169, tous les autres CVE dans lesquels un bogue est déclenché dans l’parsingur de bash.
• Il y a une stack limitée pour la redirection ici-doc, et il n’y a pas de vérification du débordement. CVE-2014-7186, qui entraîne une corruption de la mémoire et peut probablement être utilisé pour l’exécution de code arbitraire.
• Il y a une stack limitée pour les structures de contrôle nestedes ( select / for / while ), avec des contrôles pour le débordement. Cette stack est toujours corrompue. CVE-2014-7187.

Les correctifs

• Le premier patch limite bash à l’évaluation d’une définition de fonction unique dans chaque variable qui ressemble à une fonction exscope.
• Le second correctif réinitialise correctement eol_ungetc_lookahead sur reset_parser .
• Le troisième patch modifie la manière dont les fonctions sont exscopes: elles sont maintenant exscopes dans des variables nommées BASH_FUNC_functionname%% .

Surface d’attaque

Le gros problème est que chaque variable d’environnement peut être utilisée comme vecteur d’attaque. Généralement, les attaquants ne peuvent pas contrôler les variables d’environnement arbitraires, sinon il existe déjà d’autres attaques connues (pensez à LD_PRELOAD , PATH , IFS , …).

sudo n’est pas affecté car il dépouille les fonctions bash exscopes de l’environnement, comme mentionné par Gilles sur security.SE .

ssh est affecté. Les installations sshd typiques permettent uniquement un ensemble limité de variables d’environnement à exporter comme configuré dans AcceptEnv dans sshd_config , par exemple: LANG et LC_* . Même avec cette approche de liste blanche agressive, en shellshock, n’importe quelle variable pourrait être un vecteur d’attaque.

Non seulement chaque variable d’environnement était un vecteur d’attaque potentiel, mais elle exposait un parsingur de plus de 6000 lignes.

Leçons apsockets

system , popen et autres sont potentiellement dangereux. Vous devez non seulement faire attention à leurs arguments: même lorsque les arguments sont fixés à la compilation, l’environnement est un vecteur d’attaque potentiel. Utilisez fork()/execve() , de préférence avec un environnement propre (mais limitez au moins l’environnement aux variables en liste blanche, de préférence avec leurs valeurs vérifiées). Rappelez-vous qu’un système de bonne qualité fait ce qu’il est censé faire, alors qu’un système sécurisé fait ce qu’il est censé faire et rien de plus . Invoquer un shell complet ne rend rien plus difficile.

La complexité est l’ennemi de la sécurité. Ces jours-ci, vous pouvez facilement trouver des personnes recommandant des coquilles plus simples. La plupart des shells sont exempts de shellshock en ne supportant pas du tout les fonctions exscopes. Inversement, bash a reçu de nombreuses fonctionnalités de sécurité au fil des ans (vous devez l’appeler avec -p pour éviter de laisser des privilèges au démarrage, il assainit IFS, …), donc ne présumez pas que je préconise de changer de shell, c’est plus un conseil général.

Certains extraits du chapitre “Programmation sécurisée pour Linux et UNIX HOWTO” de David Wheeler sur les variables d’environnement méritent encore d’être relus.

§5.2.3 ¶1:

Pour les programmes setuid / setgid sécurisés, la courte liste des variables d’environnement nécessaires en entrée (le cas échéant) doit être soigneusement extraite. Ensuite, l’environnement entier doit être effacé, suivi par la réinitialisation d’un petit ensemble de variables d’environnement nécessaires à des valeurs sûres. Il n’y a vraiment pas de meilleur moyen si vous appelez des programmes subordonnés. il n’y a pas de méthode pratique pour lister “toutes les valeurs dangereuses”.

§5.2.3 ¶6:

Si vous avez vraiment besoin de valeurs fournies par l’utilisateur, vérifiez d’abord les valeurs (pour vous assurer que les valeurs correspondent à un modèle pour les valeurs légales et qu’elles sont dans une longueur maximale raisonnable).

En agitant beaucoup les mains, je soupçonne que le nouvel exploit fait ce qui suit:

1. La barre oblique inverse permet de contourner le correctif d’origine, de sorte que la chaîne est toujours évaluée.
2. Le > combine avec echo tant que redirection de sortie pour le shell bash
3. Avec l’évaluation de l’ echo pour définir la fonction, la seule partie de l’argument -c restant à exécuter est la date , dont la sortie va à un echo nom de fichier au lieu de la sortie standard.

C’est ce que je peux faire de mieux en lisant la source bash , mais je pense que la barre oblique inverse facilite une sorte de dépassement de tampon qui permet de fusionner la chaîne d’environnement et l’argument de -c .