Exploitation des références nulles dans le noyau Linux
Il a été récemment annoncé que des chercheurs de l'équipe Google Project Zero ont développé une méthode pour exploiter les vulnérabilités du noyau Linux causées par le déréférencement du pointeur NULL.
Jusqu'à présent, les problèmes du noyau liés au déréférencement de pointeurs NULL n'ont pas reçu l'attention qu'ils méritaient , car il était considéré comme irréaliste de transformer de tels problèmes en attaques permettant une élévation de privilèges ou l'exécution de son propre code (le mappage de processus non privilégiés vers la région inférieure de l'espace d'adressage est interdit).
En règle générale, de telles erreurs entraînent la génération d'avertissements « oops » par le noyau, après quoi les tâches problématiques sont terminées et l'état est rétabli sans qu'il soit nécessaire d'arrêter le système.
La nouvelle méthode d'attaque est basée sur la gestion des états « oops » , qui peuvent entraîner une augmentation de la valeur du compteur de références (refcount), ce qui peut à son tour provoquer un débordement du compteur et libérer la mémoire associée au refcount.
Dans ce cas, l'exploitation est réduite à des manipulations typiques des attaques use-after-free (une situation se présente où le compteur de références de l'objet devient nul, la mémoire est libérée, mais en fait il existe des liens fonctionnels pointant vers la mémoire libérée).
Actuellement, lorsqu'une déréférencement nul se produit dans le contexte d'un processus sous Linux, le noyau génère une erreur oops , différente d'un kernel panic. Un kernel panic survient lorsque le noyau détermine qu'il est impossible de poursuivre l'exécution en toute sécurité et doit donc l'interrompre. En revanche, lors d'une erreur oops, le noyau ne bloque pas l'exécution ; il tente plutôt de récupérer au mieux et de reprendre l'exécution.
Le déréférencement d'un pointeur NULL est utilisé ici comme moyen de générer l'état "oops" de manière contrôlée. Le problème est qu'il faut environ 232 appels d'état "oops" pour atteindre un débordement de refcount 32 bits.
Concrètement, il faut environ huit jours de génération continue d'états hors contexte (OOP) pour mener à bien une attaque exploitant la faille proposée. En cas de succès, cette faille permet d'exécuter du code au niveau du noyau.
Le déréférencement du pointeur NULL utilisé dans l'exploit a été corrigé en octobre, mais comme des problèmes similaires ne sont pas rares et étaient auparavant traités comme des bogues, et non comme des vulnérabilités, les développeurs ajouteront une protection générale au noyau Linux pour empêcher les attaques qui manipulent la génération de " oups ."
Dans le cas d'une tâche, cela signifie supprimer la pile de noyau existante et aller directement à make_task_dead qui appelle do_exit. Le noyau publiera également sur dmesg un journal de "crash" et une trace du noyau indiquant dans quel état se trouvait le noyau lorsque l'erreur s'est produite. Cela peut sembler un choix étrange lorsque la corruption de la mémoire s'est clairement produite ; cependant, l'intention est de faciliter la détection et la journalisation des bogues du noyau selon la philosophie selon laquelle un système en cours d'exécution est beaucoup plus facile à déboguer qu'un système en panne.
Plus précisément , le noyau 6.2 inclut des modifications visant à limiter le nombre maximal d'erreurs (« oops ») . Une fois cette limite atteinte, fixée par défaut à 10 000 erreurs (vous pouvez la modifier à l'aide du paramètre `oops_limit`), le noyau initie une transition vers un état de « panique », suivie d'un redémarrage, ce qui empêche d'atteindre le nombre d'itérations nécessaire pour réinitialiser le compteur de références à zéro.
Il est également prévu que la restriction soit transférée aux branches du noyau précédemment publiées, mais toujours prises en charge, ainsi qu'aux packages de noyau des distributions populaires.
Enfin, si vous souhaitez en savoir plus à ce sujet , vous trouverez les détails en suivant ce lien.