Trois autres bogues du noyau zombie prouvent qu'il faut appliquer des correctifs de manière systématique.

Très récemment, une vulnérabilité connue de longue date, appelée Spectre, a refait surface en raison d'une exploitation rendue publique, et l'absence de correctifs a fait que cette vulnérabilité bien connue représente à nouveau un danger.

Et, une fois de plus, quelque chose de similaire s'est produit. Cette fois, les chercheurs en sécurité ont trouvé trois bogues critiques dans un code du noyau Linux vieux de 15 ans. Un code aussi vieux aurait déjà dû faire l'objet d'un examen approfondi à la recherche de bogues - et personne ne sait combien de fois ces vulnérabilités ont été exploitées par des acteurs malveillants dans l'intervalle.

Des correctifs ont maintenant été publiés pourCentOS 8, Oracle EL8, RHEL8, CloudLinux 7h, CloudLinux 8, AlmaLinux OS, Ubuntu Bionic HWE, Debian 10, Debian 10 Cloud, Debian 9 Backports et Proxmox VE6.

En outre, des correctifs sont désormais disponibles pour CloudLinux 6h, CloudLinux 7, CentOS 7, CentOS 7-plus, Oracle EL7 et RHEL 7.

Dans cet article, nous décrivons les trois vulnérabilités qui viennent d'être découvertes, nous expliquons pourquoi le code source ouvert n'est pas toujours examiné aussi attentivement qu'il le devrait (ou par les bonnes personnes) et nous soulignons l'importance de l'application systématique de correctifs.

Contenu

1. Un vieux code qui revient nous hanter

2. Défauts de codage évidents

3. Vous êtes vulnérable même si vous n'utilisez pas SCSI.

4. Ce n'est pas parce que le code est open-source et qu'on peut le regarder gratuitement que .....

5. Les correctifs peuvent sauver vos serveurs

6. Envisagez l'application de correctifs automatisés

7. Calendrier de publication des correctifs

Un vieux code qui revient nous hanter

Ce qui est surprenant avec de nombreux systèmes d'exploitation modernes, c'est que le code sous-jacent peut être assez ancien. Alors que Linux évoluait depuis ses origines en 1991, le noyau a été continuellement mis à jour, mais cela ne signifie pas qu'il y a eu une réécriture complète du noyau Linux. Du code a été ajouté, mis à jour et supprimé, mais pas en une seule fois.

Par conséquent, la version moderne et actuelle du système d'exploitation Linux que vous utilisez peut contenir du code vieux de plusieurs décennies. Et c'est dans du code vieux de plus de dix ans que trois vulnérabilités ont été découvertes - enregistrées sous le nom de CVE-2021-27363, CVE-2021-27364 et CVE-2021-27365.

Nous ne discuterons pas des trois vulnérabilités en profondeur dans cet article - vous pouvez lire l'article original sur GRIMM.. Mais voici un aperçu rapide.

Les chercheurs de GRIMM étaient, comme ils l'ont dit, en train d'examiner par hasard le code du noyau Linux lorsqu'une vulnérabilité de sécurité extrêmement visible leur a sauté aux yeux. Dans la série de trois bogues signalés par la société, le premier bogue était tout à fait évident. Il reflétait également un manque de sensibilisation aux risques de sécurité au moment où le code a été écrit.

Ce code était présent sur toutes les versions du noyau jusqu'à 5.11.3. Cela se traduit par des bogues affectant toutes les distributions Linux et toutes les versions remontant à 15 ans.

Défauts de codage évidents

L'équipe du GRIMM a trouvé un problème dans le code du pilote SCSI. Il était évident : le programmeur avait négligé de spécifier un paramètre de longueur lors de l'inclusion du char *buf dans une zone du code. Sans validation de la longueur, un attaquant pouvait, avec un peu d'effort, exploiter ce code pour lancer une attaque.

Les deuxième et troisième vulnérabilités étaient situées dans le sous-système iSCSI de Linux. Dans la deuxième, le programmeur a utilisé une adresse du noyau comme identifiant (ce qui pourrait permettre à un attaquant de contourner l'espace d'adressage du noyau). Randomisation de la disposition de l'espace d'adressage du noyau) et dans la troisième, le programmeur a négligé de valider les données utilisateur dans le noyau.

Ces trois vulnérabilités mettent en évidence des défauts de programmation courants qui entraînent des problèmes de sécurité, mais au moment où le code a été écrit, les programmeurs n'étaient pas vraiment conscients de ces problèmes. Aujourd'hui, ces failles de programmation permettent à un acteur malveillant d'exécuter une attaque locale d'élévation de privilèges dans plusieurs distributions Linux.

Vous êtes vulnérable même si vous n'utilisez pas SCSI.

Les trois dernières vulnérabilités concernent toutes les pilotes SCSI. SCSI, abréviation de small computer systems interface, est une norme de 1986 pour la connexion des ordinateurs et des périphériques. Elle a évolué au fil des ans et est toujours utilisée via des normes telles que Serial Attached SCSI (SAS) et iSCSI, qui est essentiellement SCSI sur TCP.

Mais même si votre charge de travail ne dépend pas de SCSI, ces vulnérabilités peuvent toujours affecter vos serveurs. La raison en est la façon dont les paquets du noyau Linux dépendent les uns des autres. Le code du pilote SCSI peut être chargé dans la mémoire de votre serveur même si vous n'avez pas de périphérique SCSI connecté à votre serveur, simplement à cause des dépendances.

Prenons un exemple simple : iSCSI, qui reste un moyen fiable d'accéder à des données centralisées sur un réseau. Si votre serveur appelle iSCSI, il appellera à son tour le code SCSI dans lequel les vulnérabilités ont été découvertes. Cela se produit automatiquement lorsque le noyau Linux identifie que la fonctionnalité d'un module peut être nécessaire et charge le module.

De leur côté, les acteurs de la menace peuvent profiter du fait que les modules sont automatiquement chargés à la demande pour exploiter des vulnérabilités dans un code que vous n'utiliserez peut-être jamais dans votre charge de travail.

Ce n'est pas parce que le code est open-source et qu'on peut le regarder gratuitement que .....

Il y a un aspect intéressant aux trois vulnérabilités qui viennent d'être énumérées. Le code source ouvert est, par définition, ouvert à l'examen. Le code est publié dans le domaine public et peut être consulté et expérimenté librement.

En théorie, du moins, cela pourrait signifier que le code source ouvert est hautement sécurisé parce qu'il est tellement ouvert à l'examen. C'est l'hypothèse que beaucoup de gens font à propos du code source ouvert.

Cependant, les trois vulnérabilités dont nous parlons ont été découvertes dans du code qui fait partie du noyau Linux depuis 15 ans. On aurait pu penser que ces vulnérabilités très visibles auraient été découvertes depuis longtemps - mais ce n'est pas le cas.

Ainsi, d'une certaine manière, l'hypothèse selon laquelle le code source ouvert est plus sûr parce qu'il est ouvert à l'examen est moins valable qu'il n'y paraît à première vue.

D'un autre côté, il est également difficile de savoir si des acteurs de menaces persistantes avancées (APT) ont découvert ces vulnérabilités avant les chercheurs en sécurité, et ce qu'ils ont fait de ces connaissances. Le simple volume de vulnérabilités du noyau Linux découvertes chaque année indique également qu'il existe de nombreuses vulnérabilités inconnues qui n'ont pas encore été découvertes et qui pourraient entraîner des violations de la sécurité.

Les correctifs peuvent sauver vos serveurs

Les vulnérabilités du noyau Linux continuent de s'accumuler et, apparemment, un code vieux de 15 ans peut encore surprendre. S'il est impossible de se prémunir contre les vulnérabilités qui n'ont pas encore été découvertes par les chercheurs en sécurité, il est possible de se prémunir contre les vulnérabilités et les exploits associés qui sont dans le domaine public. Il serait stupide de ne pas le faire.

L'application de correctifs contre les vulnérabilités connues renforce également votre système. Même si un acteur parvient à pénétrer dans votre réseau grâce à une vulnérabilité qui n'a pas encore été découverte par les chercheurs, les mouvements latéraux seront plus difficiles si vos systèmes sont systématiquement protégés contre les exploits connus.

Mais, comme nous le savons tous, il n'est pas facile de mettre en place des correctifs cohérents. Il faut souvent redémarrer, mettre les serveurs hors ligne et interrompre les services. Il faut également tenir compte des heures de travail nécessaires - l'application de correctifs prend du temps. C'est pour cette raison que les correctifs sont souvent négligés.

Envisagez l'application de correctifs automatisés

Les entreprises qui dépendent de systèmes d'exploitation basés sur Linux ont la possibilité de déployer des correctifs automatisés qui suppriment la nécessité d'appliquer manuellement les correctifs du système d'exploitation.

Dans le cas de la solution de correction automatique KernelCareelle offre l'avantage supplémentaire d'un correctif en direct, sans redémarrage. En d'autres termes, KernelCare peut patcher automatiquement vos serveurs et le faire en direct, sans nécessiter de redémarrage du serveur.

Cependant, quelle que soit la voie que vous choisissez - un patching manuel minutieux ou un outil de patching en direct tel que KernelCare - il est essentiel que vous apportiez des correctifs de manière cohérente afin de protéger votre charge de travail contre les menaces existantes et émergentes.

Calendrier de publication des correctifs

L'équipe de KernelCare travaille actuellement sur des correctifs sans redémarrage pour ces vulnérabilités. La distribution des premiers correctifs est prévue pour le 18 mars. Gardez un œil sur cet article de blog pour être informé de la sortie des correctifs.