Modèle de menaces et spécificités de l'évaluation des vulnérabilités dans le noyau Linux

Linus Torvalds a intégré dans le noyau un document régissant le processus de gestion des erreurs liées à la sécurité, définissant le modèle de menace, expliquant quelles erreurs dans le noyau sont considérées comme des vulnérabilités et traitant des actions sur les erreurs identifiées à l'aide de l'IA. Le document a été préparé par Willy Tarreau, auteur de HAProxy et développeur expérimenté du noyau Linux, qui a été responsable de l'entretien de plusieurs branches stables du noyau. Comme base, des accords ont été atteints lors de la discussion des vulnérabilités critiques récemment découvertes dans le noyau (1, 2, 3, 4), révélées avant la publication des correctifs et pour lesquelles, grâce à l'IA, des exploitations fonctionnelles ont pu être immédiatement créées.

La majorité des erreurs de sécurité doit être traitée publiquement afin d'attirer le plus large public et de trouver la solution optimale. Un message privé d'urgence concernant les vulnérabilités facilement exploitables, menaçant de nombreux utilisateurs et permettant d'obtenir des privilèges ou capacités élargis, doit être envoyé à une liste de diffusion séparée.

Les vulnérabilités identifiées à l'aide d'assistants IA doivent toujours être discutées publiquement, car de tels problèmes sont souvent découverts simultanément par plusieurs chercheurs. Il ne faut pas divulguer dans le rapport l'exploit — il suffit de mentionner qu'il est disponible et de le fournir de façon privée en réponse à une demande de la personne responsable.

Les règles de présentation des rapports, créés avec l'aide d'assistants IA, sont décrites séparément. De tels rapports sont très nombreux et ils permettent parfois d'identifier des erreurs dans des parties du code mal révisées, mais les responsables les ignorent souvent à cause de leur faible qualité et de leurs imprécisions. Les principales exigences pour les rapports générés avec le soutien de l'IA sont :

• Brevité, sans superflu et avec les points essentiels et les détails importants au début.
• Uniquement du texte brut sans balises Markdown ni décoration.
• Compréhension du modèle de menace et indication des faits vérifiables (par exemple, « l'erreur permet à tout utilisateur d'obtenir CAP_NET_ADMIN »), et non des élucubrations théoriques et des conjectures sur les conséquences de la vulnérabilité.
• Avant d'envoyer le rapport, il est impératif de tester soigneusement le bon fonctionnement de l'exploit généré par l'IA et de s'assurer qu'il est possible de reproduire le problème.
• Impliquer l'IA dans le développement et les tests de la correction du problème identifié.

Selon les statistiques des accompagnateurs, la plupart des rapports d'erreurs envoyés sous le prétexte de corriger des vulnérabilités ne sont pas des vulnérabilités et doivent être traités comme des erreurs ordinaires. Un modèle de menace du noyau Linux a été décrit pour distinguer les vulnérabilités des erreurs ordinaires. Parmi les possibilités et garanties dont la violation peut être considérée comme une vulnérabilité :

• Isolation au niveau des utilisateurs : accès aux fichiers uniquement pour le propriétaire, la mémoire du processus est inaccessible aux autres utilisateurs, ptrace est interdit pour les processus d'autres utilisateurs, isolation IPC et communications réseau.
• Protection basée sur des capabilities : sans CAP_SYS_ADMIN, il n'est pas possible de modifier la configuration du noyau, la mémoire, l'état du système ; sans CAP_NET_ADMIN, il n'est pas possible de modifier les paramètres réseau ou d'intercepter le trafic ; sans CAP_SYS_PTRACE, il n'est pas possible de suivre les processus d'autres utilisateurs.
• L'espace de noms des identifiants d'utilisateurs (CONFIG_USER_NS) permet aux utilisateurs non privilégiés de créer leurs propres environnements isolés qui ne peuvent pas influencer l'espace de noms global, par exemple, en modifiant l'heure, en chargeant des modules ou en montant des dispositifs de blocs.
• Les interfaces de débogage (/proc/kmsg, perf, debugfs), par lesquelles on peut accéder à des informations confidentielles, ne sont accessibles qu'après accord explicite de l'administrateur.

Les fonctionnalités qui ne sont pas considérées comme des vulnérabilités :

• Utilisation de branches de noyau obsolètes.
• Compilation avec l'activation d'options de développement ou de sécurité réduite (par exemple, CONFIG_NOMMU).
• Configuration de paramètres sysctl non sécurisés, options de ligne de commande, droits d'accès dans le système de fichiers, capabilities ou ouverture d'accès à des interfaces privilégiées pour des utilisateurs non privilégiés (par exemple, accès en écriture dans procfs et debugfs).
• Problèmes dans des fonctions destinées uniquement au développement et au débogage du noyau, telles que LOCKDEP, KASAN et FAULT_INJECTION, qui ne sont pas destinées à être incluses dans des configurations de production.
• Problèmes dans les pilotes, modules et sous-systèmes situés dans la section STAGING ou marqués comme expérimentaux, non sécurisés ou non fonctionnels.
• Utilisation de modules noyau tiers ou de forks non officiels du noyau.
• Exigence de privilèges excessifs, tels que la nécessité d'exécuter des actions avec des droits root ou par un utilisateur ayant des droits CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_RAWIO et CAP_SYS_MODULE.
• Attaques théoriques nécessitant des conditions de laboratoire, des milliards de tentatives, l'émulation ou la modification du matériel, des coûts disproportionnés et des configurations irréalistes (par exemple, des systèmes avec des dizaines de milliers de cœurs de CPU).
• Contournement des mécanismes de protection (par exemple, ASLR) sans démonstration d'un exploit. Absence de vérifications des arguments et des codes d'erreur retournés, n'ayant pas de conséquences évidentes.
• Fuites d'informations aléatoires, non contrôlées par l'attaquant, telles que des données résiduelles dans les messages d'erreur et des fuites d'adresses/pointeurs en mémoire noyau sans possibilité d'exploitation directe.
• Erreurs lors du montage d'images disque corrompues, si le pilote n'est pas déclaré comme convenable pour une utilisation avec des supports non fiables. Problèmes avec les images disque pouvant être détectés et résolus via l'exécution de l'outil fsck.
• Attaques nécessitant un accès physique au matériel, la modification de matériel ou la connexion d'appareils matériels, tels que des cartes pour attaques DMA et des analyseurs logiques, si le système n'est pas spécialement configuré pour se protéger contre de telles attaques (IOMMU).
• Régressions de fonctionnalité et de performance, résolues par la configuration des droits et des limites.

Source : opennet.ru