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

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

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.

• Dans un cluster, la configuration de la stratégie de résiliencesur «Ne pas migrer de machines virtuelles» empêchera la migration des invités virtuels de ce cluster.  Consultez le Guide d'administration: Paramètres de stratégie de migration pour plus de détails.
• Il est possible d'empêcher des invités individuels de participer à la migration en les épinglant à des hôtes spécifiques ou en définissant Options de migration sur «Ne pas autoriser la migration».  Voir Guide de gestion: prévention de la migration automatique d'une machine virtuelle.

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.