Support technique
Documentation
Connexion
Nous contacter
Les nouvelles fonctionnalités du noyau Linux constituent une nouvelle surface d'attaque.
Joao Correia
29 décembre 2022 - Évangéliste technique
Le noyau Linux s'est développé en termes de portée et de fonctionnalités au fil des ans. Nouveaux ordonnanceurs, nouveaux pilotes, nouveaux systèmes de fichiers, nouveaux protocoles de communication, nouvelles failles de sécurité... oh, attendez. Cette dernière n'est pas comme les autres. En fait, les nouvelles failles de sécurité sont souvent le résultat de fonctionnalités nouvellement ajoutées. Bien sûr, toutes les nouvelles fonctionnalités n'ajoutent pas de nouvelles failles de sécurité, mais celles qui le font témoignent d'une base de code massive, sujette à des interactions inattendues, obscures et obscures qui donnent lieu à des situations dangereuses.
Comment la fonctionnalité est-elle ajoutée ?
Chaque sous-système du noyau a, à un moment donné, été suffisamment utile à quelqu'un pour qu'il soit soumis pour être inclus dans la base de code principale du noyau. La plupart, sinon la totalité, de ces sous-systèmes pourraient probablement être implémentés dans l'espace utilisateur plutôt que directement dans le noyau, mais le but ultime de celui qui soumet un tel code est de gagner chaque once de performance possible. Le fait d'être directement à l'intérieur de l'espace d'exécution du noyau signifie qu'il y a moins de changements de contexte, un accès direct à des régions de mémoire autrement hors de portée, et généralement des appels plus faciles et plus rapides à d'autres fonctionnalités de base et à l'accès au matériel.
Au fil des ans, cela a conduit à une prolifération, par exemple, de la prise en charge des systèmes de fichiers (il y a maintenant des dizaines de systèmes de fichiers différents pris en charge directement par le noyau), NTFS, exFAT, XFS, et bien d'autres encore - et ils ont tous une raison impérieuse de faire partie du noyau. On peut dire la même chose des modules de filtrage de paquets, des protocoles de réseau - tout le tralala. D'innombrables autres font le tour des soumissions de code, des révisions et des réécritures pour une inclusion future (ZFS, quelqu'un ?). De combien de systèmes de fichiers avez-vous réellement besoin sur un système donné ?
Il en va de même pour le débogage, car il existe de multiples fonctionnalités pour assurer le débogage dans le noyau. Parfois, elles se font même concurrence et ne peuvent pas être activées en même temps.
C'est similaire à ça :
Alors, quel est le piège ?
Lorsque le noyau Linux a été lancé, l'Internet n'était qu'un grain de poussière comparé à ce qu'il est aujourd'hui. Le nombre de systèmes en réseau et même le nombre total de réseaux dans le monde pouvaient être comptabilisés et répertoriés relativement facilement. Vous connaissiez probablement par leur nom les opérateurs travaillant sur les systèmes auxquels vous vous connectiez régulièrement. La cybersécurité n'existait pas.
Ainsi, l'ajout de nouvelles fonctionnalités au noyau a permis d'élargir le champ d'application du projet et d'étendre la portée d'un excellent logiciel, tout en permettant une grande expansion de la base d'utilisateurs, qui s'est transformée en un groupe central d'enthousiastes de Linux qui ont dirigé le projet lorsqu'il a atteint une taille suffisante.
Il n'y avait pas beaucoup de raisons de ne pas inclure quelque chose de nouveau et d'intéressant pour quelqu'un. L'inverse était vrai : plus de fonctionnalités signifiait plus d'utilisateurs intéressés.
Les choses ont changé. Plutôt beaucoup, en fait.
Laissez vos bagages à la porte
Il s'avère que l'ajout de nombreux éléments de code complexes dans quelque chose qui se développe par accrétion donne parfois des résultats inattendus.
Prenons l'exemple du sous-système Berkley Packet Filter (BPF). Initialement conçu et proposé comme un moyen d'ajouter de nouvelles implémentations de pare-feu sur mesure, il permet aux utilisateurs d'ajouter ce qui revient à n'importe quel code et de l'exécuter dans le contexte d'exécution du noyau Linux. Il a également été à l'origine de dizaines de vulnérabilités, dont certaines assez graves, au cours des dernières années. Compte tenu de son objectif, ce n'est pas totalement inattendu.
D'autres ne sont pas aussi clairs dans les risques qu'ils présentent.
Prenons un autre exemple. L'année dernière, le sous-système ksmbd a été proposé et accepté dans le noyau. Il est quelque peu similaire à Samba (c'est-à-dire qu'il permet l'utilisation du partage de fichiers SMB directement, plutôt que de s'appuyer sur un logiciel séparé). En fin de compte, il devrait permettre des vitesses de transfert SMB plus rapides en s'appuyant sur des profondeurs de pile d'appel plus courtes (en appelant les fonctions du noyau directement plutôt qu'en passant par l'ABI du noyau, comme Samba). Connaître l'histoire de SMB en matière de vulnérabilités, de vers, d'exploits et autres histoires désagréables pourrait donner quelques raisons de s'inquiéter, mais c'est dans le noyau qu'il est allé, sponsorisé par Samsung. Bien sûr, la cybersécurité étant ce qu'elle est, il y a quelques jours à peine, il a été révélé publiquement que une vulnérabilité de risque 10 (sur 10) existait dans ksmbdtelle qu'elle existe dans la base de code du noyau 5.15 (utilisé par Ubuntu 22.04, par exemple).
Nous ne nous contentons pas d'ajouter de nouvelles fonctionnalités. Nous ajoutons tous les bogues et les interactions inattendues entre le nouveau et l'ancien code qui, malheureusement, ne sont visibles que dans les systèmes de production.
Un (autre) morceau de charbon pour Noël
Ainsi, tout comme l'infâme Log4j de l'année dernière, la période des fêtes est un terrain fertile pour l'apparition de vulnérabilités très dangereuses. Tout comme les administrateurs système et les équipes de sécurité ont eu du mal à s'attaquer à Log4j et à appliquer des correctifs à temps, cette nouvelle vulnérabilité ksmbd est une autre vulnérabilité du type "corrigez maintenant ou vous serez piraté". Elle est exploitable à distance, facile à déclencher et donne un accès complet au système. Jusqu'à présent, il semble qu'un utilisateur doive être authentifié sur un partage pour pouvoir la déclencher - c'est donc une bonne nouvelle, mais c'est quand même assez sérieux. "Patch now" est un euphémisme.
De plus, pourquoi les nouvelles vulnérabilités apparaissent-elles lorsque les équipes informatiques ont des équipes réduites et sont plus lentes à réagir ? Oh, attendez...
Considérations sur les causes profondes
Il ne s'agit pas d'un article sur des sous-systèmes spécifiques. Il ne s'agit même pas d'une critique du noyau lui-même ou de son processus de développement - son succès indéniable est évident. Mais, et il y a toujours un "mais", peut-être que les nouveaux sous-systèmes devraient rester en test plus longtemps. Ou, lorsque des fonctionnalités similaires sont déjà réalisables dans l'espace utilisateur, l'inclusion du noyau ne devrait peut-être pas être acceptée du tout. Chacun a toujours une histoire convaincante derrière une demande, et c'est toujours la "meilleure chose" depuis le pain tranché. Le diable proverbial est, dans ce cas, dans les détails (de mise en œuvre).
Tout comme le paysage de la sécurité devient de plus en plus dangereux, il est peut-être temps de renforcer les conditions d'acceptation des nouveaux systèmes. Après tout, le nombre d'yeux disponibles pour surveiller les choses est limité.
Il y a des centaines de milliers de lignes de code dans le noyau, et il n'est pas possible de tenir compte de toutes les interactions bizarrement belles entre le tout nouveau code et toutes les vieilles parties dignes d'être sauvées qui restent des premiers jours. Qui peut garantir qu'un nouveau système de fichiers ajouté ne fera pas sauter un fusible lorsqu'il sera utilisé dans un système avec un planificateur qui n'est presque jamais utilisé ? Les suites de tests sont-elles assez bonnes pour en tenir compte ? Ou est-ce simplement une autre surprise qui attend de frapper les équipes informatiques lors des prochaines fêtes de fin d'année ?
Pour ma part, j'aimerais pouvoir savourer mon lait de poule au lieu de m'inquiéter de la présence de pirates informatiques dans mes systèmes à Noël.
