OpenBSD 7.9: deux pannes parsemées qui ont permis l'escalade des privilèges locaux

Aujourd'hui, une chaîne d'exploitation des privilèges locaux contre OpenBSD 7.9 a été rendue publique qui, selon le rapport publié par la société de sécurité Calif, permet à un attaquant de prendre racine en exploitant deux échecs corrigés en septembre. Les correctifs pour les deux défaillances sont déjà disponibles et distribués comme errata en septembre; le premier (un débordement complet en shmat (4)) a été corrigé le 14 septembre sous forme d'errata 018 et le second (une utilisation après utilisation dans le compte de référence) a été corrigé le 30 septembre sous forme d'errata 026. Les corrections sont disponibles via syspatch et, selon OpenBSD, couvrent toutes les architectures. Pour l'instant, il n'y a pas de CVE affecté à l'un ou l'autre des deux échecs ou preuve publique d'utilisation dans des attaques ciblées.

Faits confirmés: le vecteur initial est un débordement complet dans la fonction d'attachement de mémoire partagée shmat (4), hérité de la définition originale du noyau BSD pour le compteur add-on shm _ nattch comme un court avec 16 bit signe (maximum 32.767). OpenBSD n'a pas élargi ce type et l'explosion en profite, créant suffisamment de segments de mémoire partagés et de nombreux processus, qui peuvent dépasser sa limite et faire la valeur wrap à négatif. Le deuxième morceau de la chaîne est une défaillance dans le compte de référence qui se traduit par utilisation après utilisation. Calif a publié une analyse technique et un code de test de concept après la livraison des correctifs par OpenBSD.

Comment fonctionne la chaîne - explication technique reconstruite à partir du rapport: l'attaquant cartographie des dizaines de segments de mémoire partagée et crée de nombreux processus pour gonfler shm _ natch au-delà de 32.767; lorsque le compteur se enveloppe, une condition de carrière est créée qui peut faire sortir le noyau des objets encore utilisés par d'autres processus. De là, l'explosion profite également d'une écriture hors limites qui modifie les compteurs d'adhésion multitast dans les structures du noyau. Lorsque la socket affectée est fermée, les opérations de décrément résultantes finissent par lire ou écraser les entrées de table de page, Je rends une page utilisateur accessible en mode supervision et ainsi éviter les protections matérielles SMAP et SMP. Avec la mémoire du noyau dans l'espace de supervision, l'explosion peut écraser un pointeur de fonction situé dans une direction du noyau qui est prévisible dans cette machine et exécuter le code avec les privilèges du noyau.

Important : OpenBSD inclut KARL, un mécanisme de randomisation qui soulage le binaire du noyau pour randomiser la fonction et les adresses de données. Cependant, selon le chercheur (Andrew Griffiths) cité par Calif, les plongeurs de mémoire du noyau restent déterministes : à la fois le boot et le best-fit assignent les premières structures (y compris les pointeurs utilisés par les contrôleurs d'interface lo0 et enc0) dans des directions reproductibles dans la même machine entre les redémarrages. Cette prévisibilité permet à l'explosion de cibler un pointeur de fonction sans exiger une vulnérabilité supplémentaire de la divulgation de l'information.

Quels impacts réels cela peut avoir : sur les systèmes vulnérables sans correctifs, un attaquant avec accès local (c'est-à-dire capable de faire fonctionner des processus sur la machine affectée) pourrait acquérir des privilèges root. Ce n'est pas une explosion à distance.: nécessite une exécution locale, comme l'accès non privilégié de l'utilisateur ou la possibilité d'exécuter des processus dans un conteneur ou une session. Il affecte donc directement les serveurs ou les stations où les utilisateurs non entièrement fiables ont la capacité d'exécuter le code, les environnements multi-utilisateurs et les services qui donnent l'exécution à des processus tiers.

Confirmé contre estimé ou incertain: il est un fait que les correctifs ont été libérés et que Calif a publié le PoC. Il s'agit d'une estimation raisonnable (soutenue par la technique expliquée) que la chaîne permet d'échapper au SMAP/SMEP et de s'enraciner dans la configuration décrite; cependant, il est encore incertain si cette chaîne a été exploitée dans des environnements réels avant correction (il n'y a pas de preuves publiques). Il n'y a pas non plus de CVE assigné au moment de la publication, ce qui laisse une certaine incertitude dans la communication coordonnée entre les coordinateurs de la CVE et ceux de la CVE.

Mesures spécifiques à prendre par les administrateurs et les utilisateurs d'OpenBSD en ce moment: mettre à jour et appliquer les errata publiées. OpenBSD a distribué les corrections par syspatch; les administrateurs doivent exécuter syspatch et redémarrer les systèmes pour que les corrections du noyau aient effet. L'information officielle d'errata et l'outil de syspatch sont disponibles sur les pages OpenBSD: OpenBSD errata et homme syspatch. En outre, jusqu'à ce que les correctifs soient appliqués, les gestionnaires devraient restreindre l'accès local : limiter les comptes avec la capacité d'exécuter les processus, resserrer les conteneurs et les compartiments, et examiner les configurations qui permettent aux utilisateurs non privilégiés de créer de grandes quantités de segments de mémoire partagée ou de processus de masse.

Recommandations supplémentaires en matière de sécurité opérationnelle : effectuer l'intégrité et la vérification du système après la mise à jour (vérifier les binaires, les dossiers de démarrage et l'activité anormale), faire pivoter les pouvoirs privilégiés s'il y a un soupçon d'engagement et envisager la séparation des services qui acceptent le code de tiers dans des hôtes dédiés qui peuvent être redémarrés et mis à jour plus facilement. Pour les environnements à risque élevé, limiter ou surveiller l'utilisation d'un partage de mémoire peu fiable et utiliser des contrôles d'accès supplémentaires (p. ex. listes de contrôle au niveau de l'application).

Mesures de durcissement proposées par le découvreur et son évaluation: Calif propose quatre lignes d'atténuation à long terme : safe-unlinking pour les listes liées au noyau(déjà utilisé dans FreeBSD et NetBSD), cartographie autoréférentiel des tableaux de pages, Randomisation de l'expéditeur de la mémoire du noyau et limite les contrôles par compilateur. Ces propositions s'attaquent aux causes structurelles de l'explosion : l'absence de liens sûrs réduit l'efficacité des corruptions de listes liées, la randomisation de la table de pages autoréférentiels et l'affectation rend difficile la prédiction des directions, et la vérification des limites aiderait à détecter des erreurs d'écriture hors de portée ou des dépassements. Ce sont des solutions architecturales qui nécessitent des travaux de mise en œuvre et de validation et qui ne remplacent pas la correction d'erreurs spécifiques, mais qui sont un plan de défense en profondeur.

Ce qu'il faut surveiller dans les prochaines semaines : confirmation du CVE (s) assigné, mises à jour supplémentaires OpenBSD qui améliorent l'atténuation architecturale, et rapports d'utilisation active dans la nature. La réponse de la communauté OpenBSD aux propositions de durcissement de Calif et à tout changement dans les missions de mémoire KARL ou noyau sera également pertinente.

En résumé: Si vous gérez des systèmes OpenBSD, appliquez les errats et redémarrez. La chaîne publiée montre une voie technique pour échapper aux protections matérielles et se débarrasser des vulnérabilités locales, mais les corrections sont déjà disponibles et leur installation est l'action la plus immédiate et efficace. Maintenir la réduction de l'accès local comme mesure temporaire tout en stabilisant les améliorations à long terme au cœur du système.