Nouvelle vulnérabilité du noyau découverte par Virtuozzo et corrigée en direct par KernelCare

Il y a un mois, l'équipe de Virtuozzoa découvert une nouvelle vulnérabilité de sécurité dans le noyau - CVE-2020-14305. Elle corrompt la mémoire dans les noyaux de v3.5 à v4.10 et affecte diverses distributions Linux. KernelCare prépare les correctifs pour cette CVE qui seront disponibles cette semaine. Lisez cet article pour savoir comment la vulnérabilité a été découverte et quelles sont les mesures d'atténuation.

Une CVE de corruption de mémoire (CVE-2020-14305) a été découverte début juin par l'ingénieur du noyau Linux de Virtuozzo, Vasily Averin. La vulnérabilité affecte diverses distributions Linux : Red Hat Enterprise Linux 7, Debian 8 et 9, Ubuntu 14.04 et 16.04, UEK 3 et 4, Centos 7 ALT et les noyaux de 3.5 à 4.10. Si le port IPV6 1720 est ouvert sur le nœud, s'y connecter corrompt la mémoire. En particulier, l'équipe FastVPS - l'utilisateur qui a signalé ce bug à l'équipe Virtuozzo - a fait l'expérience de la corruption d'un élément dans la dalle kmalloc-192. La vulnérabilité est corrigée dans Virtuozzo Hybrid Server 7.0 Update14 et ReadyKernel 108.

Selon RedHat, ce problème est considéré comme ayant un impact modéré car il est limité à l'utilisation du port 1720 de l'IPV6 et à un module particulier pour la voix sur IP H.323.

Pour résoudre ce problème, l'équipe Virtuozzo a créé un correctif pour Virtuozzo 7 et l'équipe KernelCare a créé les correctifs pour les autres distros Linux affectées pour une distribution sans redémarrage.

L'équipe de KernelCare tient à remercier l'équipe Virtuozzo et Vasily Averin pour avoir découvert ce bogue et nous avoir donné la possibilité de fournir à nos clients les correctifs contre CVE-2020-14305 si rapidement.

Calendrier de publication des correctifs de KernelCare

Voici le calendrier de publication des correctifs de KernelCare :

• Lundi 6 juillet : RHEL7, Debian8 & 9, Ubuntu 14.04 & 16.04, 
• Jeudi 9 juillet : Unbreakable Enterprise Kernel 3 & 4, CentOS 7.

Instructions d'atténuation

Aucune mesure d'atténuation particulière n'est nécessaire pour la correction de cette vulnérabilité. Si votre noyau est affecté et que vous utilisez KernelCare, les correctifs seront appliqués automatiquement en fonction de vos paramètres de mise à jour (par défaut, l'agent KernelCare vérifie les correctifs toutes les 4 heures).

Si vous utilisez votre KernelCare - vos correctifs seront livrés automatiquement par KernelCare et vous n'avez rien à faire de plus. Sinon, c'est le bon moment pour vous inscrire à un essai de 30 jours. Aucune carte de crédit n'est requise.

Comment le CVE-2020-14305 a-t-il été découvert ?

L'équipe Virtuozzo a fourni à KernelCare les détails exclusifs sur la façon dont ce CVE a été découvert. Cela a été possible grâce à l'aide de leur client - l'équipe FastVPS. 

"Je tiens à remercier l'équipe FastVPS pour avoir signalé ce bug, leur engagement, leur patience et leur collaboration à cet égard. Sans leur collaboration, cette vulnérabilité n'aurait peut-être pas été découverte du tout", a déclaré Vasily Averin, ingénieur du noyau Linux chez Virtuozzo.

Continuez à lire pour connaître toute l'histoire. 

En cherchant dans les dumps de crashs, l'équipe Virtuozzo a trouvé la cause des crashs - il s'agissait d'une corruption de la mémoire dans la dalle kmalloc-192 où sont stockés différents objets du noyau de 128 à 192 octets. Ils avaient déjà reçu des rapports sur la corruption de ces objets auparavant, mais à chaque fois, les recherches se sont heurtées à un mur.

Il était très difficile d'enquêter sur la corruption de la mémoire en raison de sa nature. Souvent, les corruptions de mémoire échappent simplement à la détection, par exemple, si la mémoire inutilisée est corrompue. Parfois, on peut avoir de la chance lorsque la corruption n'endommage pas quelque chose de critique. Mais même si elle conduit à un crash du noyau, il est difficile de comprendre que la raison du crash était la corruption de la mémoire.

Il est encore plus difficile de comprendre la nature de la corruption. Habituellement, cela est dû à l'utilisation après la libération et vous devez donc vérifier l'allocation, l'initialisation, le comptage de référence et la libération des objets corrompus. Cependant, dans le cas de la dalle kmalloc-192, les choses sont pires - elle est utilisée pour conserver un grand nombre d'objets différents. L'équipe Virtuozzo a essayé de traquer les plus populaires et a échoué.

Cependant, de temps en temps, l'équipe Virtuozzo a trouvé quelque chose. En février, Vasily a découvert un bogue qui provoquait une corruption de la mémoire dans kmalloc-192.

Il espérait avoir résolu le problème. Mais un jour, FastVPS est arrivé avec le même problème. L'équipe de Vasily leur a demandé de reproduire le problème sur le noyau avec le correctif ci-dessus mais cela n'a pas aidé, le problème s'est répété.

Habituellement, dans de tels cas, Virtuozzo utilise le débogage du noyau avec le débogage supplémentaire tout usage. Les clients n'utilisent pas les noyaux de débogage en production car cela diminue considérablement les performances et c'est totalement inacceptable pour nos hôtes. Cependant, FastVPS a déplacé le noyau de débogage en production. Ils ont souffert un certain temps, mais comme le problème ne s'est pas reproduit, ils sont revenus au noyau normal.

Pour attraper le problème sur le noyau régulier, Virtuozzo a demandé à FastVPN d'activer le slub_debug. 

Il diminue également les performances et augmente la consommation de mémoire, effectue des vérifications supplémentaires de la mémoire lors de l'allocation et de la libération des objets, et vous permet de suivre la façon dont un objet corrompu a été utilisé dans le passé. Mais malgré tout, le problème ne s'est pas reproduit et les nœuds avec slub_debug activé fonctionnaient bien. Mais finalement, au début du mois de juin, l'équipe Virtuozzo a reçu un rapport du nœud avec le slub_debug activé. Grâce à ce rapport, l'équipe a compris quel objet était à l'origine de la corruption de la mémoire et a également compris la nature de la corruption - il ne s'agissait pas d'une utilisation après la libération mais d'un accès au-delà de l'objet, ce qui est considérablement plus rare.

Cela a essentiellement aidé à l'enquête et quelques jours plus tard, Vasily a découvert la cause du problème.

Pour savoir quand le correctif sera disponible immédiatement, suivez cet article de blog ou notre Twitter et Facebook et Facebook.