Tous les noyaux des fournisseurs Linux ne sont-ils pas sécurisés ? Une nouvelle étude dit oui, mais il existe une solution

Tous les noyaux des fournisseurs sont en proie à des failles de sécurité, selon un livre blanc du CIQ. La communauté Linux acceptera-t-elle un jour les noyaux stables en amont ?

Dans un nouveau livre blanc, Vendor Kernels, Bugs and Stability, la société de logiciels d'infrastructure et de Rocky Linux, CIQ, présente un argument convaincant selon lequel les noyaux des fournisseurs Linux sont en proie à des vulnérabilités de sécurité en raison de processus d'ingénierie défectueux qui rétroportent les correctifs.

Même si cela peut en choquer certains, c'est un secret de Polichinelle dans la communauté Linux. Comme l'a récemment déclaré Greg Kroah-Hartman, responsable du noyau stable Linux et membre éminent de l'équipe de sécurité du noyau : Pour être en sécurité, vous devez toujours utiliser le dernier noyau stable à long terme. Le mot clé ici est « dernier ». Il ne suffit pas d'utiliser un LTS. Vous devez utiliser la version la plus récente pour être aussi sécurisé que possible.

Malheureusement, presque personne ne le fait. Néanmoins, comme l'explique Kees Cook, ingénieur du noyau Linux chez Google : "Alors, que doit faire un fournisseur ? La réponse est simple : si cela est pénible : mettre à jour en permanence vers la dernière version du noyau, qu'elle soit majeure ou stable."

Pourquoi? Comme l'explique Kroah-Hartman : « Tout bug peut potentiellement constituer un problème de sécurité au niveau du noyau. »

Jonathan Corbet, développeur du noyau Linux et rédacteur en chef de LWN, est d'accord : « Dans le noyau, n'importe quel bug, si vous êtes assez intelligent, peut être exploitable pour compromettre le système. Le noyau se trouve à un endroit unique dans le monde. système... il transforme beaucoup de bugs ordinaires en vulnérabilités."

Ce que les ingénieurs du CIQ, Ronnie Sahlberg, Jonathan Maple et Jeremy Allison, ont fait, c'est d'attribuer des chiffres concrets à cette position. Leur article montre que -- avec les pratiques d'ingénierie actuelles -- presque tous les noyaux des fournisseurs sont intrinsèquement non sécurisés et que la sécurisation de ces noyaux est impossible.

En effet, les noyaux des fournisseurs Linux ont été créés en prenant un instantané d'une version Linux spécifique, puis en rétroportant les correctifs sélectionnés au fur et à mesure que des modifications se produisent dans l'arborescence Git en amont. Cette méthode, conçue à une époque où les pilotes de périphériques hors arborescence étaient répandus, vise à améliorer la stabilité et la sécurité en sélectionnant les modifications à rétroporter. Cet article examine comment cela fonctionne dans la pratique en analysant le taux de modification et le nombre de bogues dans Red Hat Enterprise Linux (RHEL) 8.8, version du noyau 4.18.0-477.27.1, en le comparant aux noyaux en amont de kernel.org.

Bien que les programmeurs aient examiné spécifiquement RHEL 8.8, il s'agit d'un problème général. Ils auraient obtenu les mêmes résultats s'ils avaient examiné SUSE, Ubuntu ou Debian Linux. Les distributions Linux à version continue telles que Arch, Gentoo et OpenSUSE Tumbleweed publient constamment les dernières mises à jour, mais elles ne sont pas utilisées dans les entreprises.

Leur analyse du noyau RHEL 8.8 révèle 111 750 validations individuelles dans le journal des modifications. Ces données, même si elles ne détaillent pas le contenu ou la taille des commits, fournissent une compréhension générale du processus de rétroportage. Initialement, le taux de rétroportage a été constant, mais il a diminué vers novembre 2021, puis de nouveau de manière significative en novembre 2022, ce qui correspond à la sortie de RHEL 8.5 et RHEL 8.7, respectivement. Selon les auteurs, cette tendance reflète une évolution vers un rétroportage plus conservateur afin d'améliorer la stabilité à mesure que le cycle de publication majeur progresse.

Leur examen a révélé 5 034 bogues non corrigés dans RHEL 8.6 ; 4 767 bogues non corrigés dans RHEL 8.7 ; et 4 594 bogues non corrigés dans RHEL 8.8.

Ces chiffres représentent des bogues connus avec des correctifs en amont qui n'ont pas été rétroportés vers RHEL. L'arrêt antérieur du rétroportage dans RHEL 8.6 et 8.7 a conduit à davantage de bogues non corrigés par rapport à RHEL 8.8. La pratique de Red Hat consistant à ne pas publier l'intégralité des modifications du code source ajoute à la complexité, ce qui entraîne d'éventuels faux positifs et négatifs dans les données avec lesquelles CIQ devait travailler. Malgré ces limitations, le CIQ rapporte que les vérifications manuelles suggèrent une grande précision dans l'identification des correctifs manquants.

Contrairement à l’hypothèse selon laquelle les bogues sont rapidement corrigés en amont, beaucoup persistent pendant de longues périodes avant d’être résolus. Ce retard a un impact sur la qualité du noyau, car le ralentissement du processus de rétroportage entraîne un nombre croissant de bogues connus et non corrigés, ce qui compromet la stabilité et la sécurité du noyau au fil du temps.

Depuis que les développeurs du noyau Linux ont pris en charge la gestion des vulnérabilités et expositions communes (CVE) de Linux, 270 nouvelles CVE en mars 2024 et 342 en avril 2024 ont été signalées. Ceux-ci ont déjà été corrigés dans la branche git stable du noyau Linux.

Pourtant, les chiffres soulignent l’importance d’utiliser des noyaux stables en amont pour une sécurité renforcée. Le volume de nouveaux CVE et l’absence de période d’embargo sur les correctifs nécessitent une approche proactive de la part des organisations pour évaluer et traiter ces vulnérabilités.

En outre, bien que RHEL 8.8 n'ait pas été activement développé depuis fin 2022, environ 10 % de tous les bogues nouvellement découverts l'affectent toujours. La dernière série majeure de corrections de bogues de RHEL 8.8 est arrivée en mai 2023. Il en va de même pour les autres distributions Linux d'entreprise plus anciennes (mais toujours prises en charge). Plus troublant encore, selon le CIQ : « Certains des correctifs manquants que nous avons examinés sont explicitement divulgués comme étant exploitables depuis l'espace utilisateur. »

Par conséquent, l’équipe CIQ a conclu que le modèle de noyau traditionnel du fournisseur, caractérisé par un rétroportage sélectif, était défectueux. Le nombre croissant de bogues connus et non corrigés suggère que les noyaux des fournisseurs sont moins sécurisés que les noyaux stables en amont. L'équipe préconise une transition vers l'utilisation de branches de noyau stables de kernel.org pour une meilleure sécurité et une meilleure gestion des bogues.

Selon les auteurs, « cela incite fortement » les clients soucieux de leur sécurité à adopter des noyaux stables plutôt que ceux spécifiques à un fournisseur. Ils affirment : « Nous pensons que le seul moyen réaliste pour un client de savoir qu'il utilise un noyau aussi sécurisé que possible est de passer à une branche de noyau stable. »

Cet article n'est pas une critique des ingénieurs du noyau dédiés aux fournisseurs Linux. Au lieu de cela, c'est une invitation pour l'industrie à se rallier aux noyaux stables de kernel.org comme solution optimale à long terme. Un tel changement permettrait aux ingénieurs de se concentrer davantage sur la correction des bogues spécifiques aux clients et sur l'amélioration des fonctionnalités plutôt que sur le processus de rétroportage à forte intensité de main-d'œuvre.

Ils tirent donc quatre conclusions essentielles :

• Le modèle de noyau du fournisseur est défectueux et irréparable.
• Les noyaux des fournisseurs sont intrinsèquement non sécurisés, les noyaux des fournisseurs stabilisés en fin de cycle étant particulièrement vulnérables.
  
• Le grand nombre de bogues ouverts connus rend leur analyse ou leur classification peu pratique.
  
• Les noyaux stables en amont offrent une bien meilleure protection contre les vulnérabilités de sécurité et les bogues dans le code du noyau.
  

Alors, les vendeurs le feront-ils ? Malgré toutes les bonnes raisons de sécurité qui justifient de passer à des noyaux stables en amont, il existe des contre-arguments qui se résument à ceci : si vous effectuez toujours une mise à niveau vers le noyau le plus récent, vous pouvez également rencontrer des problèmes de stabilité. Un programme qui fonctionne parfaitement avec le noyau 4.18.0-477.27.1 pourrait ne pas fonctionner avec 4.18.0-477.27.1.el8_8. Bien entendu, dans ce cas précis, le noyau le plus récent a corrigé un bug de sécurité important.

Tout cela se résume à un délicat exercice d’équilibre entre sécurité et stabilité. Certains grands développeurs du noyau Linux et CIQ se rangent du côté de la sécurité. Nous verrons ce que le reste de la communauté des fournisseurs Linux a à dire.