Warning message

This translation is outdated. For the most up-to-date information, please refer to the English version.

VHOST-NET GUEST TO HOST ESCAPE - Vulnérabilité Noyau - CVE-2019-14835

Public Date: September 17, 2019, 12:00 am
Updated -
Ongoing Status
Important Impact

Récapitulatif 

Une vulnérabilité de dépassement de mémoire tampon a été détectée dans la fonctionnalité de virtualisation de réseau du noyau Linux, qui pourrait être utilisée de manière abusive lors de la migration live d’invités de VM. Un utilisateur invité privilégié peut transmettre des descripteurs de longueur non valide à l'hôte lorsqu'une migration live est en cours, et augmenter son niveau de privilèges sur l'hôte.

Détails techniques et contexte 

La vulnérabilité est nommée CVE-2019-14835 et comporte un niveau de sévérité Important.

Cette faille ne peut être exploitée que lors de migrations live d'invités. Les correctifs et autres mesures d'atténuation sont détaillés ci-dessous.


CVE-2019-14835 - kernel: vhost-net: guest to host kernel escape during migration

Une vulnérabilité de dépassement de mémoire tampon a été détectée dans la fonctionnalité de virtualisation de réseau du noyau Linux, qui pourrait être utilisée de manière abusive lors de la migration live d’invités de VM. Un utilisateur invité privilégié peut transmettre des descripteurs de longueur non valide à l'hôte lorsqu'une migration live est en cours, et augmenter son niveau de privilèges sur l'hôte. Il est peu probable que cela affecte les systèmes à hôte unique où la migration live d'invité n'est pas configurée.

Remerciements

Red Hat aimerait remercier Peter Pi de l’équipe Tencent Blade.

Références supplémentaires 

https://www.openwall.com/lists/oss-security/2019/09/17/1

https://www.redhat.com/en/blog/introduction-virtio-networking-and-vhost-net

https://www.redhat.com/en/blog/deep-dive-virtio-networking-and-vhost-net 

https://bugzilla.redhat.com/show_bug.cgi?id=1750727

Produits concernés

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

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

  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 7
  • Red Hat Enterprise Linux 8
  • Red Hat Virtualization 
  • Red Hat OpenStack Platform (noyau d'envoi d'images) 
  • Virtualisation conteneur-natif (CNV)

Bien que les conteneurs Linux de Red Hat ne soient pas directement affectés par les problèmes du noyau, leur sécurité dépend de l'intégrité de l'environnement du noyau hôte. Red Hat vous recommande d'utiliser les versions les plus récentes de vos images de conteneurs. L'index de santé des conteneurs (Container Health Index), qui fait partie du Red Hat Container Catalog, peut toujours être utilisé pour vérifier le statut de sécurité des conteneurs Red Hat. Pour protéger l'accès des conteneurs utilisés, vous devrez veiller à ce que l'hôte du conteneur (tel que Red Hat Enterprise Linux, Red Hat CoreOS ou Atomic Host) ait bien été mis à jour pour éviter la possibilité de ces attaques. Red Hat a publié une mise à jour d'Atomic Host pour ce cas d'utilisation.

Diagnostiquer votre vulnérabilité

Utiliser le script de détection ci-dessous pour déterminer si votre système est actuellement concerné par cette faille de sécurité. Pour vérifier la légitimité du script, vous pouvez télécharger la signature GPG détachée également.

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

Version en cours : 1.0


Action

Nous conseillons à tous les clients de Red Hat exécutant des versions de produits Red Hat affectés de procéder aux mises à jour dès que les correctifs sont disponibles. On conseille aux clients d'appliquer les mises à jour qui conviennent immédiatement.

REMARQUES

À l'heure actuelle, il n'existe aucune méthode fiable pour détecter si code malveillant exploitant une faille de sécurité a été exécuté avec succès sur un système, en raison du bas niveau de la méthode d'exploitation.

Red Hat Product Security recommande vivement aux clients de consulter le profil de menace d’attaques de leurs systèmes, en particulier les charges de travail multi-tenant. Envisagez de corriger les systèmes de priorité supérieure nécessitant des capacités de migration d'invité.

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

En savoir plus sur le kpatch : Est-ce que les correctifs de noyau (Kernel Patches) (kpatch) sont pris en charge dans RHEL 7 ?

Mises à jour pour les produits concernés

ProduitPackageAlerte / Mise à jour
Red Hat Enterprise Linux 8 (z-stream)noyauRHSA-2019:2827
Red Hat Enterprise Linux 8kernel-rtRHSA-2019:2828
Red Hat Enterprise Linux 7 (z-stream)noyauRHSA-2019:2829
Red Hat Enterprise Linux 7kernel-rtRHSA-2019:2830
Red Hat Enterprise Linux 7kpatch-patchRHSA-2019:2854
Red Hat Enterprise Linux 6 (z-stream)noyauRHSA-2019:2863
Red Hat Virtualization 4.3redhat-virtualization-hostRHSA-2019:2889
Red Hat Virtualization 4.2redhat-virtualization-host

en attente

Prévention

Option n ° 1 Désactiver vhost-net

La fonctionnalité Vhost-net peut être désactivée par invité. Voir DISABLING VHOST-NET.

Sinon, le module de noyau nommé 'vhost_net' qui contient le code affecté peut être mis en liste noire à l'aide des techniques standard de mise en liste noire. Voir Comment ajouter un module de noyau à la liste noire pour l'empêcher de se charger automatiquement?pour obtenir des instructions sur la manière d'effectuer la tâche. 

Les invités utilisant la fonctionnalité vhost-net doivent être redémarrés pour que les modifications puissent prendre effet.

Option n ° 2 Désactivation de la migration en direct d'invité

Le problème n'est exploitable qu’en provenance de l'invité que lorsque la migration live est en cours. Éviter la migration soit en désactivant complètement la migration automatique, ou bien, en ne migrant pas manuellement les invités vers un autre hôte, est un moyen efficace d'éviter l'exploitation.

CNV - Désactiver le support de migration live

Désactivez la fonctionnalité de migration live en supprimant le champ "LiveMigration" des données: feature-gates: dans le fichier de configuration kubevirt-config, situé dans l'espace de noms kubevirt

Procédure
Editez le fichier de configuration kubevirt-config et supprimez LiveMigration de la ligne `feature-gates`:

$ oc modifier configmap kubevirt-config -n kubevirt
...
données :
  feature-gates: "LiveMigration"
Supprimez le terme «LiveMigration» dans la ligne ci-dessus.

Les pods virt-api et virt-controller doivent être redémarrés pour appliquer les modifications.

$ oc delete pod virt-api -n kube-system
$ oc delete pod virt-controller -n kube-system

Red Hat Virtualisation - désactivation de la migration automatique

Les migrations peuvent être désactivées au niveau du cluster ou pour des invités individuels.  En règle générale, Red Hat Virtualization migrera automatiquement les invités vers d'autres hôtes au sein d'un cluster en fonction des mesures de charge, de la compatibilité, de la résilience et des règles de disponibilité.  Les invités peuvent également être migrés pendant la maintenance, car les hôtes d'un cluster sont mis en mode maintenance.

La stratégie de migration automatique peut être contrôlée au niveau du cluster ou dans une configuration d'hôte individuelle.

Pour vous assurer que les invités ne sont pas migrés lorsqu'un hôte est mis en mode de maintenance, assurez-vous que les invités soient configurés avec l'option « Ne pas autoriser la migration » ou bien fermez tous les invités de cet hôte avant de le mettre en mode de maintenance.

On conseille à nos clients de prendre une approche basée risque pour résoudre ce problème. Les systèmes qui exigent des niveaux de sécurité et de confiance élevés doivent être réglés en premier, et doivent être isolés des systèmes suspects tant que la durée de traitement nécessaire n'a pas été encore appliquée à ces systèmes pour en réduire le risque d'exploitation.

Impact sur la performance

La mise à jour du noyau vers une version contenant le correctif n'aura aucun impact notable sur les performances.

Un impact sur les performances est attendu si on utilise comme méthode la désactivation de vhost-net. Les mesures exactes dépendront de la charge réseau sur le système.

Playbook Ansible

De plus, un playbook de mesures de mitigation est disponible, qui empêche le chargement du module de noyau vulnérable. Ce playbook va redémarrer vos systèmes pour s'assurer que le module est déchargé. Pour l'utiliser, spécifiez les noms d'inventaire des systèmes cibles dans la variable HOSTS. Par exemple :

ansible-playbook -e HOSTS=myhost1,myhost2 CVE-2019-14835_blacklist_mitigate.yml

Une signature GPG détachée est également disponible.


Mesures de mitigation avec Ansible

Version en cours : 1.0