Kernel Local Privilege Escalation "Dirty COW" - CVE-2016-5195

Public Date: October 26, 2016, 09:33
Mis à jour October 24, 2024, 11:52 - Chinese, Simplified Anglais Japanese Korean
Resolved État
Important Impact

Red Hat Product Security a découvert une vulnérabilité dans le noyau Linux. Cette vulnérabilité s'est vue attribuée CVE-2016-5195. Ce problème a été rendu public le 19 octobre 2016 et a été classifié Important. Ce phénomène est ce que les media appellent « Dirty COW ».

Informations générales

On a détecté une condition de concurrence dans la manière dont le sous-système de mémoire du noyau Linux compromet la Copie pour l'écriture des mappages de mémoire privés en lecture-seule. Un utilisateur local sans privilèges peut exploiter cette faille pour obtenir une permission écriture sur des mappages de mémoire qui sont normalement en lecture-seule, et accroître ainsi ses privilèges sur le système.

Cela peut porter à des abus si un attaquant souhaite modifier des fichiers setuid existants par des instructions d'élévation des privilèges, et cette technique a déjà été utilisée. Ce problème affecte la plupart des distributions les plus modernes de Linux.

Red Hat Product Security a évalué l'impact de sécurité à un niveau Important.

Produits concernés

Les versions de produits Red Hat suivants sont concernées :

  • Red Hat Enterprise Linux 5
  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 7
  • Red Hat Enterprise MRG 2
  • Red Hat Openshift Online v2
  • Red Hat Virtualization (RHEV-H/RHV-H)

Description et impact de l'attaque

Cette faille permet à un attaquant avec un compte de système local de modifier les fichiers binaires sur disque, en éludant les mécanismes d’autorisation standard qui empêcheraient normalement la modification si on ne possède pas les permissions appropriées. Il est possible de le faire en mettant en concurrence l’appel système madvise(MADV_DONTNEED) tout en ayant la page du mmapped exécutable dans la mémoire.

Diagnostiquer votre vulnérabilité

Déterminer si votre système est vulnérable

Action

On conseille à tous les clients Red Hat utilisant actuellement les versions de noyau affectées de mettre leur noyau à jour le plus rapidement possible dès que les correctifs sont disponibles. Les informations sur les paquets concernés, ainsi que les mesures de mitigation recommandées sont notées ci-dessous. Un redémarrage du système s'impose pour que la mise à niveau du noyau puisse avoir lieu.

Mises à jour des produits concernés

Un kpatch est maintenant à la disposition des clients qui exécutent Red Hat Enterprise Linux 7.2 ou version ultérieure. Veuillez ouvrir un dossier d'assistance pour accéder au kpatch.

Pour savoir ce qu'est-ce qu'un kpatch : Est-ce que les correctifs de noyau ou Kernel Patches (kpatch) sont pris en charge dans RHEL 7 ?


Produit Paquet Alerte/Mise à jour
Red Hat Enterprise Linux 7 noyau RHSA-2016:2098
Red Hat Enterprise Linux 7 kernel-rt RHSA-2016:2110
Red Hat Enterprise Linux 7.1 Extended Update Support* noyau RHSA-2016:2118
Red Hat Enterprise Linux 6 noyau RHSA-2016:2105
Red Hat Enterprise Linux 6.7 Extended Update Support* noyau RHSA-2016:2106
Red Hat Enterprise Linux 6.6 Extended Update Support* noyau RHSA-2016:2128
Red Hat Enterprise Linux 6.5 Advanced Update Support** noyau RHSA-2016:2120
Red Hat Enterprise Linux 6.4 Advanced Update Support** noyau RHSA-2016:2133
Red Hat Enterprise Linux 6.2 Advanced Update Support** noyau RHSA-2016:2132
Red Hat Enterprise Linux 5 noyau RHSA-2016:2124
Red Hat Enterprise Linux 5.9 Long Life noyau RHSA-2016:2126
Red Hat Enterprise Linux 5.6 Long Life noyau RHSA-2016:2127
RHEL Atomic Host noyau en attente
Red Hat Enterprise MRG 2 kernel-rt RHSA-2016:2107
Red Hat Virtualization (RHEV-H/RHV-H) noyau en attente

*Un abonnement EUS actif est requis pour pouvoir accéder à ce correctif.

Veuillez contacter l'équipe de ventes de Red Hat ou bien, votre représentant commercial personnel pour obtenir plus d'informations et savoir si votre compte n'a pas d'abonnement EUS actif.

Qu'est- ce qu'un abonnement Red Hat Enterprise Linux Extended Update Support ?

*Un abonnement AUS actif est exigé pour pouvoir accéder à ce correctif dans RHEL 6.X AUS.

Mitigation

COMMENT CRÉER ET UTILISER LA SOLUTION DE CONTOURNEMENT SYSTEMTAP

La contre-mesure systemtap implique la création d’un module de noyau (comme un pilote) à l’aide d’un script systemtap, qui intercepte l’appel système vulnérable. Cette solution est une solution palliative utilisée jusqu'à ce qu’un noyau réparé soit chargé dans la machine affectée. Cette solution ne nécessite pas un redémarrage et s’applique à RHEL 5 6 et 7.

Il n'est pas possible de créer un module qui s'applique à tous les noyaux. Pas même pour une famille (par ex. les RHEL5,6 ou 7). Chaque version de noyau particulière requiert un .ko pour ce noyau donné (uname-r).

CONDITIONS PRÉALABLES

Pour pouvoir créer le module systemtap, les modules suivants sont requis :

  • systemtap-client
  • systemtap-devel
  • gcc (et dépendences)
  • kernel-devel-`uname -r`
  • kernel-debuginfo-`uname -r`
  • kernel-debuginfo-common-`uname -r`

ATTENTION : les packages de « noyau » ont besoin de la même version que le noyau en cours. Télécharger la dernière version empêchera systemtap de fonctionner. Veuillez télécharger la version exacte en cours.

OÙ PUIS-JE OBTENIR LES INFOS DE DÉBOGAGE

Veuillez consulter la Base de connaissance (KB) https://access.redhat.com/solutions/9907

COMMENT CRÉER LE MODULE

1. Une fois que vous aurez installé les packages, créer un fichier nommé dirtycow.stp avec le contenu suivant :

probe kernel.function("mem_write").call ? {
        $count = 0
}

probe syscall.ptrace {  // includes compat ptrace as well
        $request = 0xfff
}

probe begin {
        printk(0, "CVE-2016-5195 mitigation loaded")
}


probe end {
        printk(0, "CVE-2016-5195 mitigation unloaded")
}
										

2. Enregistrez le fichier. Le compiler par la commande suivante :

# stap -g -p 4 -m dirtycow_`uname -r|tr -cd [:digit:]` dirtycow.stp
dirtycow_26183985.ko
											

Dans l’exemple ci-dessus, le fichier .ko a un numéro identifiant la version du noyau. Dans ce cas, ce numéro correspond à 2.6.18-398.el5. Ce module peut être utilisé dans d’autres systèmes avec cette version de noyau exacte, sans avoir à installer debugs/debuginfos/systemtap. Il suffit de copier le fichier sur le serveur avec le même noyau, puis passez à l’étape suivante.

3. Pour pouvoir télécharger le module. exécuter la commande insmod <.ko file>. Exemple :

# insmod dirtycow_26183985.ko
												

4. Vérifiez s'il est chargé.

# lsmod| grep dirty
dirtycow_26183985   101688  0
													

5. Pour décharger le module, exécutez la commande rmmod ou redémarrer le système.

IMPORTANT

  • Le module ne survit pas à un nouvel amorçage : il ne sera pas chargé à nouveau après un nouveau démarrage système.
  • Après un nouveau démarrage système, le module doit être chargé manuellement à nouveau.
  • Si le noyau est mis à jour ou modifié, ce module ne sera pas chargé dans le nouveau noyau.
  • Si vous démarrez avec un noyau différent non réparé, il vous faudra télécharger un nouveau module compatible.
  • Un noyau corrigé n'a pas besoin du chargement de module.

Veuillez prendre note du bogue 1384344 pour les étapes de mitigation en détails.

Comments