Kees Cook a introduit de nouveaux correctifs pour améliorer la sécurité de la pile du noyau Linux

Linux/Unix

Kees Cook, ancien administrateur système en chef de kernel.org et chef de l'équipe de sécurité Ubuntu, travaillant maintenant chez Google pour protéger Android et ChromeOS, a publié un ensemble de correctifs qui randomisent les décalages de la pile du noyau lors du traitement des appels système. Les correctifs améliorent la sécurité du noyau en modifiant l'emplacement de la pile, lou cela rend les attaques de pile beaucoup plus difficiles et moins réussies

L'idée originale du patch appartient au projet PaX RANDKSTACK. En 2019, Elena Reshetova, ingénieure chez Intel, a tenté de créer une implémentation de cette idée, susceptible d'être incluse dans la composition principale du noyau Linux.

Par la suite, l'initiative a été prise par Kees Cook qui a présenté une implémentation adaptée à la version principale du noyau et dont les correctifs sont prévus pour la version 5.13 de Linux.

Le mode sera désactivé par défaut et pour l'activer, le paramètre de ligne de commande du noyau est proposé "Randomize_kstack_offset = activé / désactivé»Et paramètres CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT, De plus, la surcharge liée à l'activation du mode est estimée à environ 1% de perte de performances.

L'essence de la protection proposée est de choisir un décalage de pile aléatoire à chaque appel système, ce qui complique la détermination de la disposition de la pile en mémoire même si des informations d'adresse sont reçues, puisque l'adresse de base de la pile changera au prochain appel.

Contrairement à la mise en œuvre de PAX RANDKSTACK, dans les patchs proposés pour inclusion dans le noyau, la randomisation n'est pas effectuée au stade initial, mais après avoir défini la structure pt_regs, ce qui rend impossible l'utilisation de méthodes basées sur ptrace pour déterminer un décalage aléatoire lors d'un appel système de longue durée.

Alors que les protections de la pile du noyau Linux se sont constamment améliorées (mappage de pile basé sur vmap avec des pages de protection, suppression de thread_info, STACKLEAK), les attaquants ont dû trouver de nouvelles façons pour que leurs exploits fonctionnent.

Ils ont et continuent de s'appuyer sur le déterminisme de la pile du noyau, dans les situations où VMAP_STACK et THREAD_INFO_IN_TASK_STRUCT ils n'étaient pas pertinents. Par exemple, les attaques récentes suivantes auraient été entravées si le décalage de pile n'était pas déterministe entre les appels système

Le but de la fonction randomize_kstack_offset est d'ajouter un décalage aléatoire après que pt_regs a été poussé sur la pile et avant que le reste de la pile de threads soit utilisé pendant le traitement des appels système, et changez-le chaque fois qu'un processus émet un appel système. La source du caractère aléatoire est actuellement définie par l'architecture (mais x86 utilise l'octet de poids faible de rdtsc ()).

Des améliorations futures sont possibles pour différentes sources d'entropie, mais en dehors de la portée de ce patch. Aussi, pour ajouter plus d'imprévisibilité, de nouveaux décalages sont choisis à la fin des appels système (dont le temps devrait être moins facile à mesurer depuis l'espace utilisateur qu'au moment de la saisie de l'appel système) et stockés dans une variable par CPU, afin que la durée de vie de la valeur ne reste pas explicitement liée à une seule tâche.

Il n'y a pas de changements visibles pour cela sur x86 car l'économiseur de pile est déjà désactivé de manière inconditionnelle pour l'unité de compilation, mais le changement est requis dans arm64. Malheureusement, aucun attribut ne peut être utilisé pour désactiver l'économiseur de pile pour des fonctions spécifiques. Comparaison avec la fonction PaX RANDKSTACK: La fonction RANDKSTACK randomise l'emplacement du début de la pile (cpu_current_top_of_stack), c'est-à-dire qu'elle inclut l'emplacement de la structure pt_regs sur la pile.

Au départ ce patch a suivi la même approche, mais au cours de discussions récentes, il a été déterminé comme étant de peu de valeur car si la fonctionnalité ptrace était disponible pour un attaquant, vous pouvez utiliser PTRACE_PEEKUSR pour lire / écrire différents décalages sur la structure pt_regs, observer le comportement du cache des accès pt_regs et découvrir le décalage de pile aléatoire.

Enfin, il est mentionné que la mise en œuvre initiale prend en charge les processeurs ARM64 et x86 / x86_64.


Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont marqués avec *

*

*

  1. Responsable des données : AB Internet Networks 2008 SL
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.