La vulnérabilité du noyau de Mmap est reclassée
Nous avons couvert de toutes nouvelles vulnérabilités du noyau Linux dans quelques-uns de nos articles précédents, mais dans cet article, nous allons nous pencher sur une vulnérabilité qui a été réinscrite accidentellement. Les deux rapports - le réenregistrement erroné et l'enregistrement original - indiquent une vulnérabilité dans le mappage de la mémoire du noyau Linux où une situation de course peut se développer lorsqu'une fonction d'expansion de la mémoire est utilisée.
Nous couvrirons la vulnérabilité telle qu'elle est. Mais nous nous pencherons également sur une question clé révélée par la double liste : si les experts en sécurité peuvent si facilement perdre de vue une vulnérabilité existante, au point qu'une vulnérabilité est réinscrite comme "nouvelle" et "tout juste découverte", qu'en est-il de l'état de la gestion des vulnérabilités ?
Et qu'est-ce que cela signifie pour les utilisateurs de Linux dans le monde entier, vulnérables à d'innombrables stratégies offensives - mais dépendants de l'aide des experts en sécurité ?
Contenu
-
Comprendre la vulnérabilité du noyau mmap
-
Extension de la mémoire
-
Un rapide aperçu des conditions de course et de l'utilisation après-coup
-
Quel est l'impact de cette vulnérabilité particulière ?
-
Attendez, nous avons déjà été ici avant...
-
Il y a une plus grande question en jeu
-
La gestion efficace des vulnérabilités est extrêmement difficile
-
Gérer efficacement les vulnérabilités
-
Les correctifs sont essentiels
-
L'automatisation et la mise en place de correctifs en temps réel sont essentielles
-
Conclusion
Comprendre la vulnérabilité du noyau mmap
Les applications ont presque toujours besoin de conserver quelque chose dans la mémoire de l'ordinateur pendant qu'elles fonctionnent - sinon, elles ne seraient pas très utiles. À son tour, le noyau du système d'exploitation doit attribuer un espace mémoire à une application. La fonction utilisée pour demander cette allocation de mémoire s'appelle mmap, une fonction de mappage de la mémoire.
La mémoire d'un ordinateur est, bien entendu, limitée. Lors de l'attribution de la mémoire, le noyau doit gérer soigneusement les demandes - et réattribuer la mémoire inutilisée à une autre application si nécessaire.
Dans cette vulnérabilité spécifique, il existe un cas limite où deux applications différentes pourraient demander l'accès à la même mémoire. L'application qui arrive en dernier échoue dans sa demande. La raison pour laquelle cela crée une vulnérabilité est que cette deuxième application serait toujours capable de lire à partir d'un emplacement mémoire désormais invalide.
Cela déclencherait à son tour un plantage du noyau, ce qui pourrait signifier que les informations contenues dans cet emplacement mémoire sont divulguées. Ces informations peuvent aller de quelque chose de totalement inoffensif à une clé de chiffrement, et c'est là que réside le risque.
Extension de la mémoire
Il convient de noter que la cause de cette vulnérabilité réside dans la façon dont l'expansion de la mémoire est gérée. Le noyau gère la mémoire allouée en maintenant une liste de pages mémoire. À certains moments, une application peut avoir besoin de plus de mémoire - ou même de céder une partie de cette mémoire.
Par exemple, si l'utilisateur d'une application ouvre un fichier volumineux, l'application peut avoir besoin d'étendre son allocation de mémoire. Cette expansion peut être "ascendante" ou "descendante" par rapport à la mémoire qui lui est attribuée. En temps normal, cela ne pose pas de problème, mais l'expansion doit être gérée avec soin, sinon elle peut entraîner des problèmes - des interactions peuvent se produire entre plusieurs threads de la même application ou dans différentes applications.
Malheureusement, comme l'ont constaté les chercheurs qui ont découvert cette vulnérabilité, dans certains cas, les versions affectées du noyau Linux ne gèrent pas correctement l'expansion de la mémoire. En raison de cette vulnérabilité, une condition de course peut émerger entre certaines fonctions d'expansion - expand_downwards et expand_upwards - et les opérations de libération des tables de pages.
Un rapide aperçu des conditions de course et de l'utilisation après-coup
Il est utile de passer rapidement en revue les deux problèmes de sécurité courants qui entourent cette vulnérabilité. Premièrement, de nombreux problèmes de sécurité tournent autour des conditions de concurrence. Nous avons décrit ci-dessus comment la condition de course fonctionne dans cette vulnérabilité - deux applications demandant l'accès au même espace mémoire. L'application qui arrive "en retard" peut obtenir par erreur l'accès à la mémoire allouée à une autre application.
Il ne s'agit là que d'un exemple de condition de concurrence. En général, les situations de concurrence se produisent lorsque deux ou plusieurs threads - de la même application ou d'applications différentes - essaient d'accéder aux mêmes données. Il peut s'agir de données partagées ou d'un espace mémoire alloué. Les attaquants peuvent exploiter les erreurs créées par les conditions de course (y compris les plantages du noyau) pour toute une série d'attaques, du déni de service au siphonnage de données.
Un scénario de type "user-after-free" (UAF) se produit lorsqu'une application tente d'accéder à un élément de la mémoire après qu'il a été libéré. Par exemple, un pointeur dans une application pointe vers un ensemble de données en mémoire dynamique qui n'est plus utilisé - et donc libre - alors qu'en fait le pointeur aurait dû être mis à jour.
Là encore, les vulnérabilités de l'UAF permettent aux attaquants d'exploiter des erreurs de programmation pour déclencher une violation de la sécurité - en faisant planter un système ou en volant des données.
Quel est l'impact de cette vulnérabilité particulière ?
Actuellement, il n'y a pas d'exploits connus pour cette vulnérabilité dans la nature, mais comme toujours, il y a un risque qu'un exploit puisse émerger. Le risque qu'il apparaisse est moyen à faible étant donné la nécessité d'un accès au compte local pour exploiter la vulnérabilité. Néanmoins, avec un accès à un compte local, un attaquant peut créer un programme spécialement codé qui déclenche un "use-after-free" qui fait planter le noyau.
Comme effet secondaire de ce plantage, l'attaquant peut concevoir son programme de manière à voler des informations, par exemple en s'emparant du message d'erreur généré par le plantage, qui contient le contenu de la mémoire affectée. Les attaquants peuvent également faire référence au "core dump" créé à chaque fois que le noyau se bloque. Une attaque correctement exécutée peut exfiltrer ces informations vers une autre machine.
Cette vulnérabilité affecte les versions du noyau antérieures à 5.7.11. La plupart des distributions ont publié des correctifs pour cette vulnérabilité - si vous avez appliqué les correctifs associés, vos charges de travail seront protégées contre cette vulnérabilité. Et, bien sûr, KernelCare fournit des correctifs en direct pour cette vulnérabilité dans toutes les distributions qu'il prend en charge.
Attendez, nous avons déjà été ici avant...
Le CVE pour la vulnérabilité en question, CVE-2020-20200est récemment apparu comme réservé (en d'autres termes, une vulnérabilité a peut-être été identifiée, mais pas confirmée). Il s'avère que, il s'agissait d'un rapport dupliqué. La même vulnérabilité a en fait été signalée en novembre de l'année dernière sous le nom de CVE-2020-29369.
Les chercheurs qui ont réservé CVE-2020-20200 ne savaient manifestement pas que la vulnérabilité avait déjà été signalée. En conséquence, CVE-2020-20200 a simplement été repliée dans CVE-2020-29369. Ce n'est pas la première fois qu'une vulnérabilité de sécurité est signalée en double, et ce dernier exemple remet la question du double signalement - et ce qu'il implique - sous les projecteurs.
Même les personnes qui sont étroitement impliquées dans la sécurité du noyau Linux ont accepté la deuxième divulgation. Oui, il est positif que différentes personnes et équipes vérifient ces vulnérabilités, mais il est inquiétant que les vulnérabilités existantes puissent être si facilement oubliées dans le processus.
Il y a une plus grande question en jeu
On peut dire que le double signalement suggère un manque de sensibilisation aux vulnérabilités dans la communauté de la sécurité au sens large. Cette vulnérabilité particulière affecte des fonctionnalités fondamentales du noyau, mais le fait qu'elle ait été signalée deux fois suggère que son existence n'est pas aussi largement connue qu'elle aurait dû l'être.
Il est facile de rejeter la faute d'un manque de sensibilisation sur les experts en sécurité, mais le fait est que ces personnes et ces équipes se perdent tout simplement dans un flot de vulnérabilités. La vague croissante de problèmes de sécurité ne fait qu'anéantir toute possibilité réelle pour une seule personne ou même une équipe d'être constamment au courant des vulnérabilités critiques signalées.
En d'autres termes, nous disons que même les experts ne peuvent pas toujours faire face au flot de vulnérabilités qui sont découvertes.
La gestion efficace des vulnérabilités est extrêmement difficile
Si les experts en sécurité ont du mal à gérer les vulnérabilités, il va sans dire que le personnel en charge des opérations informatiques quotidiennes aura encore plus de mal. Un administrateur système typique est déjà submergé par les tâches quotidiennes - il aura de la chance s'il se souvient des cinq ou dix dernières vulnérabilités qui ont récemment nécessité un correctif. Mais des dizaines ou des centaines ? C'est peu probable.
Dans la vie réelle, cela signifie que les vulnérabilités seront mal gérées. De nombreuses vulnérabilités passeront simplement sous le radar. D'autres seront corrigées - mais, selon toute probabilité, longtemps après la publication du correctif.
Ce traitement "imparfait" des vulnérabilités est ce qui laisse une opportunité aux acteurs malveillants. Pire encore, les attaquants utilisent couramment des outils automatisés pour rechercher les vulnérabilités non corrigées. En d'autres termes, les correctifs fragmentaires ne sont pas très différents de l'absence de correctifs.
Gérer efficacement les vulnérabilités
La gestion des vulnérabilités bénéficie d'une série d'outils. Une gestion étroite des informations d'identification et des autorisations serait un outil clé, par exemple pour limiter les dégâts qu'un attaquant peut faire avec des informations d'identification volées.
De même, la surveillance de la sécurité peut aider à repérer une attaque en cours et vous donner la possibilité de limiter les dégâts. Et, bien sûr, les pare-feu et autres outils de sécurité peuvent arrêter les attaques automatiques avant qu'elles ne prennent racine.
Les correctifs sont essentiels
Pourtant, l'application rapide et cohérente de correctifs est de loin le moyen le plus efficace de gérer les vulnérabilités. Dans de nombreux cas, un correctif est publié pour une vulnérabilité bien avant l'apparition d'un exploit. Même lorsque les exploits sont diffusés dans la nature avant qu'un correctif ne soit disponible, la fenêtre entre l'exploit et le correctif est relativement étroite.
En revanche, si les correctifs sont inefficaces, le délai entre l'apparition d'un exploit dans la nature et l'application du correctif peut être de plusieurs années, voire indéfini.
Nous savons que l'application de correctifs est difficile. Par exemple, l'application des correctifs est perturbatrice, car elle nécessite souvent le redémarrage du serveur. L'application de correctifs pendant les fenêtres de maintenance est utile, mais les correctifs critiques doivent être appliqués même en dehors d'une fenêtre de maintenance.
L'automatisation et la mise en place de correctifs en temps réel sont essentielles
L'application de correctifs prend beaucoup de temps si elle est effectuée manuellement. L'automatisation des correctifs est une meilleure solution, car elle garantit que les correctifs sont appliqués de manière cohérente et sans la pression habituelle sur les ressources informatiques.
La manière la plus efficace de gérer les correctifs est, bien entendu, l'application automatique de correctifs combinée à des correctifs sans redémarrage. En d'autres termes, les correctifs sont appliqués en direct, sans nécessiter de redémarrage. L'application de correctifs en direct et sans redémarrage implique que les serveurs sont maintenus à jour, sans perturber les services sous-jacents.
Ce service est la raison d'être de KernelCare live patching qui consiste à appliquer automatiquement et en toute transparence des correctifs à vos serveurs sans nécessiter de redémarrage intempestif.
Conclusion
Il est extrêmement difficile de suivre le flot des vulnérabilités. Même les experts les plus impliqués dans la gestion des vulnérabilités se trompent parfois. Il ne fait donc aucun doute que les administrateurs système et les experts en sécurité d'entreprise commettront des erreurs similaires, à moins qu'ils n'utilisent des outils automatisés de pointe.
Les correctifs en direct, sans redémarrage et automatisés de KernelCare appliquent des correctifs pour la vulnérabilité mmap susmentionnée et de nombreux autres types de vulnérabilités dès que le correctif est publié. Des outils comme KernelCare sont donc essentiels dans la lutte permanente contre les vulnérabilités - et les exploits associés.