Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Aller au contenu

grsecurity

Un article de Wikipédia, l'encyclopédie libre.

grsecurity
Description de l'image Grsecurity logo.svg.

Informations
Créateur Brad Spengler
Première version
Dépôt grsecurity.net/downloadVoir et modifier les données sur Wikidata
État du projet en développement actif
Écrit en C
Système d'exploitation LinuxVoir et modifier les données sur Wikidata
Type PatchVoir et modifier les données sur Wikidata
Licence GPLv2
Documentation https://en.wikibooks.org/wiki/Grsecurity
Site web https://grsecurity.net/

modifier - modifier le code - voir Wikidata (aide)

grsecurity est une modification augmentant la sécurité pour le noyau Linux distribué sous la licence publique générale GNU version 2. Il inclut différents éléments, dont PaX, un système de contrôle d'accès à base de rôles et différents moyens de renforcer la sécurité générale du noyau.

Histoire

[modifier | modifier le code]

Le projet grsecurity a vu le jour en février 2000, sous le nom de "GRKERNSEC", sous forme de mises a jour des modifications de sécurité du projet Openwall pour des noyaux Linux plus récents. En 2001, grsecurity se met à inclure PaX, puis se dote d'un système d'ACL nommé "Oblivion", écrit par Michael Dalton, qui fut amélioré pour se doter d'un mode d'auto-apprentissage, puis se transformera en Contrôle d'accès à base de rôles en 2003[1].

À la suite de la perte de son principal sponsor, Brad Spengler annonce, le , que le développement du projet pourrait être arrêté[2],[3]. Toutefois, il semble que le développement continue à un rythme aussi soutenu qu'auparavant après une phase où les contributions se faisaient plus rares entre janvier et .

Depuis , à la suite de violations répétées de la license de grsecurity (GPLv2) ainsi que de sa marque déposée d'acteurs majeurs de l'industrie du Linux embarqué, la disponibilité des modifications en stables est devenue limitée aux clients commerciaux de la société. L'élément déclencheur fut l'utilisation de la marque "grsecurity" par WindRiver sur certains leurs produits en fin de vie, tirant profit de la notoriété du nom en matière de sécurité, sans contribuer en retour et en y intégrant des modifications à la qualité douteuse[4],[5],[6],[7]. Les versions de tests des correctifs de grsecurity et les correctifs sur des fonctionnalités des espaces utilisateurs, restent accessibles au public[8],[9].

Depuis le , tous les correctifs sont distribués uniquement aux clients de la société. La licence du patch, GPLv2, reste inchangée[10].

Fonctionnalités

[modifier | modifier le code]

Grsecurity inclut PaX, une modification du noyau Linux renforçant significativement sa sécurité. PaX n'est plus disponible hors de grsecurity depuis 2017[10].

grsecurity offre différents moyens d'améliorer l'audit du noyau Linux. Il est ainsi possible d'auditer certains utilisateurs ou groupes, les opérations de montage (GRKERNSEC_AUDIT_MOUNT), l'exécution de binaires (GRKERNSEC_EXECLOG), la création de chroots (GRKERNSEC_CHROOT_EXECLOG), l'usage de ptrace (GRKERNSEC_AUDIT_PTRACE), …

L'option GRKERNSEC_CHROOT permet de durcir significativement la securité des chroots, qui n'ont pas été conçus comme un mécanisme de sécurité. Il existe aujourd'hui des solutions de sandboxing bien plus sûres, comme AppArmor par exemple.

L'option GRKERNSEC_TPE permet de définir un gid ne pouvant pas exécuter de binaires hors de dossiers en lecture seule pour les utilisateurs non-privilégiés, et appartenant à l'utilisateur root.

En 2002, GRKERNSEC_KMEM est implémenté[11], restreignant l'acces a /dev/kmem, /dev/mem, /dev/port, ... réduisant significativement la surface d'attaque du noyau. Cette fonctionnalité fut implémentée dans le noyau linux en 2019 par Matthew Garrett dans le cadre de l'option CONFIG_SECURITY_LOCKDOWN_LSM[12].

En 2004, GRKERNSEC_HIDESYM est implémenté, restreignant les informations disponibles aux utilisateurs non-privilégiés au sujet du noyau: symboles, modules chargés, adresses mémoires,[1]... Cette fonctionnalité fut partiellement implémentée en 2010 dans le noyau linux via l'option kptr_restrict[13].

En 2009, PAX_USERCOPY est intégré, ajoutant des vérifications lors de la copie (y compris partielle) d'objets présents sur le tas entre l'espace noyau et l'espace utilisateur: leurs tailles est vérifiée, et certains objets (contenant par exemple les informations utilisateur ou les droits de fichiers) ne peuvent tout simplement plus être copiés depuis/vers l'espace noyau. Cette fonctionnalité a pour effet de réduire les primitives de lecture du la mémoire du noyau par des utilisateurs, mais également d'écrasement de mémoire lors de copies vers l'espace noyau[14].

La même année, GRKERNSEC_MODHARDEN est également implémenté, interdisant le chargement de modules noyau aux utilisateurs non-privilégiés, ne leur permettant donc pas d'agrandir arbitrairement la surface d'attaque du noyau[14]. Cette option fut proposé à l'adoption dans le noyau linux par Dan Rosenberg en novembre 2010, à la suite de la publication de l'élévation de privilèges nommée can-i-haz-modharden.c exploitant CVE-2010-2959 par Jon Oberheide, mais ne fut pas intégrée[15],[16],[17].

En 2010, GRKERNSEC_DMESG, restreignant l'accès au journal du noyau au utilisateurs privilégiés, fut proposé à l'adoption dans le noyau linux par Dan Rosenberg, sous forme d'une option nommée CONFIG_SECURITY_DMESG_RESTRICT[18].

En 2011, GRKERNSEC_BRUTE est ajouté, détectant et invalidant les tentatives d'attaques par recherche exhaustive. Cette option a pour effet de réduire l'efficacité d'exploits ayant une composante probabiliste, et de renforcer celle de l'ASLR: quand un processus fils d'un daemon est interrompu de maniere suspecte, le processus père ne pourra recréer de fils pendant une certaine durée[14],[19]. Cette fonctionnalité fut qualifiée dans Phrack de hautement efficace contre l'exploitation de certains types de bogues[20].

Une variante de GRKERNSEC_BRUTE est implémentée quelques mois plus tard[1]: GRKERNSEC_KERN_LOCKOUT. Quand PaX détecte une activité suspecte, en plus d'immédiatement terminer le processus fautif, si ce dernier tourne en tant que root, le système est immédiatement arrêté. Si l'utilisateur n'est pas root, tous ses processus sont terminés, et la création de nouveaux processus lui sont interdits[21].

En avril 2011, Dan Rosenberg et Jon Oberheide publient "Stackjacking: your way grsec/pax to bypass" aux conférence Hackito Ergo Sum et Infiltrate[22], détaillant 4 techniques pour effectuer une élévation de privilèges sous grsecurity, en ne présupposant qu'une seule primitive d'écriture arbitraire[23]:

  • kstack self-discovery, consistant à tirer partie de la réutilisation de la pile entre chaque appel système pour fuiter du contenu présent en mémoire, permettant de retrouver l'adresse mémoire de la base de la pile.
  • Rosengrope, abusant le membre addr_limit de la structure thread_info via la primitive d'écriture arbitraire afin de rendre floue la séparation entre l'espace mémoire utilisateur et l'espace noyau.
  • Obergrope, une alternative a Rosengrope, utilisant la primitive d'écriture pour manipuler la pile d'un processus fils afin de générer une primitive de lecture pour obtenir d'adresse de la structure task_struct.
  • Stackjacking, écrasant la structure task_struct présente sur la pile pour élever les privilèges du processus courant.

En réponse, plusieurs contre-mesures furent implémentées[24]:

  • thread_info fut déplacée dans sa propre zone mémoire isolée, en dehors de la pile.
  • PAX_RANDKSTACK, effaçant les données présentes sur la pile de l'espace noyau entre chaque appel système.
  • PAX_USERCOPY fut améliorié, afin de ne permettre qu'à une liste restreinte de structures de l'espace d'être exposées à l'espace utilisateur.

En 2012, GRKERNSEC_BPF_HARDEN est implémenté, masquant les constantes présentes dans le code eBPF, en réponse à un article détaillant comment contourner SMEP via ce dernier. Le noyau Linux utilise une protection différente, préférant décaler le début code eBPF de manière aléatoire, offrant une protection moins coûteuse en performances, mais également plus faibles, cette dernière étant facilement contournable par un attaquant possédant une primitive de lecture arbitraire[25],[26]. En 2016, l'approche choisit par grsecurity fut finalement adoptée par le noyaux Linux[27].

En fevrier 2012, afin de renforcer l'efficacité de l'ASLR fourni par PaX, GRKERNSEC_PROC_MEMMAP est ajoutée, interdisant l'accès aux fichiers présents dans le dossier /proc/pid contenant des informations sur la mémoire des processus, si l'accès est initié par un processus avec un pid différent[1],[28].

En 2013, à la suite d'un article publié par Exodus Intelligence sur une exécution de code arbitraire sur le logiciel Asterisk[29], GRKERNSEC_RAND_THREADSTACK fut implémentée, ajoutant un décalage aléatoire de 8 bits a la pile des threads en espace utilisateur[30],[31].

En juin 2013, GRKERNSEC_PERF_HARDEN est ajoutée, afin de réduire drastiquement la surface d'attaque du noyau, en interdisant l'usage de l'infrastructure d'observation des performances aux utilisateurs non-privilégiés[28].

En janvier 2014, GRKERNSEC_RANDSTRUCT est implémenté, changeant de manière aléatoire la représentation en mémoire de structures contenant exclusivement des pointeurs sur fonctions, ainsi que celle explicitement annotées comme sujettes à ce traitement[28]. Cette fonctionnalité fut partiellement intégrée au noyau Linux en juin 2017 par Kees Cook[32],[33].

En mars 2014, GRKERNSEC_JIT_HARDEN est ajoutée, améliorant la protection fournie par GRKERNSEC_BPF_HARDEN en utilisant une constante différente par instruction BPF contenant une value immédiate pour son masquage, empêchant un attaquant possédant une primitive de lecture arbitraire de lancer une attaque par recherche exhaustive de générer des instructions arbitraires[28].

Le 5 avril 2014, un hacker nommé "comex/PinkiePie"[34] publia une vidéo démontrant une élévation de privilèges sous grsecurity[35]. Grâce aux indices présents dans la vidéo quant-aux vecteurs utilisés (un dépassement de la pile d'un processus noyau, couplé à une attaque sur BPF fournissant une primitive de lecture/écriture arbitraire), l'attaque résultat en l'implémentation de deux nouvelles mesures de sécurité[26]:

  • GRKERNSEC_KSTACKOVERFLOW, ajoutant une page mémoire non-mappée sous le tas des piles des processus du noyau, rendant leurs possibles débordements inexploitables. Une approche similaire, nommée VMAP_STACK, fut adoptée dans le noyau Linux en 2017[36],[37],[38].
  • L'interdiction de l'interpréteur BPF d'accéder à la mémoire en dehors de son tampon alloué, ainsi qu'une approche moins laxiste en cas de contenu invalide.

En octobre 2018, RESPECTRE est publié, détectant et neutralisant automatiquement via un plugin pour GCC les gadgets d'exploitation de la vulnérabilité Spectre et ses dérivés[39],[40].

En 2021, AUTOSLAB est implémenté via un plugin gcc, isolant automatiquement les objets alloués sur le tas en espace noyau par types[41]. Cette approche est similaire à celle utilisé par Apple en 2022 via kmalloc_type[42], ou encore PartitionaAlloc dans Chrome, qui sont elles manuelles[43]. Cette isolation complexifie significativement l'exploitation de use-after-free et de confusion de types[44].

Divers bogues de sécurité sont également corrigés longtemps à l'avance, comme par exemple :

  • L'utilisation de move_pages() pour contourner l'ASLR d'executables suid, corrigé en 2009 dans grsecurity, mais seulement en 2017 dans le noyau Linux[45],[46].
  • L'abus de wchan pour lire la mémoire du noyau, corrigé en 2004 dans grsecurity, mais seulement en 2015 dans le noyau Linux[47],[45].

Contrôle d'accès à base de rôles

[modifier | modifier le code]

Il s'agit d'un système de contrôle d'accès obligatoire (de l'anglais, mandatory access control). Il est utilisé par exemple dans le cas où il est utile de restreindre l'accès à certaines ressources au seul utilisateur root (qui a normalement accès à toutes les ressources).

La politique de sécurisation de grsecurity se démarque des autres modèles de sécurité en cela qu'elle ne prétend pas trouver et retirer les failles existantes, mais les rendre inutiles. Ainsi, chaque processus d'un système peut être limité à ne pouvoir effectuer que les tâches pour lesquelles l'administrateur l'y autorise, espérant ainsi éviter qu'un attaquant puisse compromettre le système tout entier. Ce correctif de sécurité suppose donc que le noyau Linux est exempt de bug exploitable.

Utilisateurs historiques notables

[modifier | modifier le code]

À la suite de l'indisponibilité publique de grsecurity, les utilisateurs cités ci-dessous n'en font plus usage, sans mention explicite.

Hebergeurs

[modifier | modifier le code]

Distributions Linux

[modifier | modifier le code]

Notes et références

[modifier | modifier le code]
  1. ↑ a b c et d (en) Bradley Spengler, « The case for grsecurity » [PDF].
  2. ↑ Brad Spengler, New (final?) grsecurity release and important announcement, 27 décembre 2008
  3. ↑ « La fin de Grsecurity ? », Linuxfr, .
  4. ↑ (en) Silviu Stahie, « Grsecurity Forced by Multi-Billion Dollar Company to Release Patches Only to Sponsors », sur softpedia.com, (consulté le ).
  5. ↑ « Grsecurity stable patches to be limited to sponsors [LWN.net] », sur lwn.net (consulté le ).
  6. ↑ « grsecurity », sur grsecurity.net (consulté le ).
  7. ↑ « Gentoo Forums :: Voir le sujet - Intel Subsidiary's Violations Made Grsec withdraw Stable? », sur forums.gentoo.org (consulté le ).
  8. ↑ (en) Brad Spengler et The PaX Team, « Important Notice Regarding Public Availability of Stable Patches », sur grsecurity.net, (consulté le ).
  9. ↑ (en) « grsecurity downloads page », sur grsecurity.net (consulté le ).
  10. ↑ a et b (en) Brad Spengler & The PaX Team, « Grsecurity Passing the Baton », sur grsecurity.com, (consulté le ).
  11. ↑ (en) « oss-sec: Silently (or obliviously) partially-fixed CONFIG_STRICT_DEVMEM bypass », sur seclists.org (consulté le ).
  12. ↑ (en) « lockdown: Restrict /dev/{mem,kmem,port} when the kernel is locked down · torvalds/linux@9b9d8dd », sur GitHub (consulté le ).
  13. ↑ « kptr_restrict for hiding kernel pointers [LWN.net] », sur lwn.net (consulté le ).
  14. ↑ a b et c (en) « Grsecurity/Appendix/Grsecurity and PaX Configuration Options - Wikibooks, open books for an open world », sur en.wikibooks.org (consulté le ).
  15. ↑ (en) Jon Oberheide, « i-can-haz-modharden.c » Accès libre.
  16. ↑ « LKML: Dan Rosenberg: [PATCH RFC] Restrictions on module loading », sur lkml.org (consulté le ).
  17. ↑ « NVD - CVE-2010-2959 », sur nvd.nist.gov (consulté le ).
  18. ↑ « LKML: Dan Rosenberg: [PATCH] Restrict unprivileged access to kernel syslog », sur lkml.org (consulté le ).
  19. ↑ (en) « GRKERNSEC_BRUTE Exploit Bruteforcing Protection », sur xorl %eax, %eax, (consulté le ).
  20. ↑ « .:: Phrack Magazine ::. », sur phrack.org (consulté le ).
  21. ↑ (en) « GRKERNSEC_KERN_LOCKOUT Active Kernel Exploit Response », sur xorl %eax, %eax, (consulté le ).
  22. ↑ « Stackjacking Your Way to grsec/PaX Bypass | Jon Oberheide », sur jon.oberheide.org (consulté le ).
  23. ↑ Jon Oberheide, jonoberheide/stackjacking, (lire en ligne)
  24. ↑ « grsecurity forums • View topic - Much Ado About Nothing: A Response in Text and Code », sur forums.grsecurity.net (consulté le ).
  25. ↑ Keegan, « Attacking hardened Linux systems with kernel JIT spraying », sur main is usually a function, (consulté le ).
  26. ↑ a et b « grsecurity forums • View topic - Linux Kernel BPF JIT Spraying », sur forums.grsecurity.net (consulté le ).
  27. ↑ « bpf: add generic constant blinding for use in jits - kernel/git/torvalds/linux.git - Linux kernel source tree », sur git.kernel.org (consulté le ).
  28. ↑ a b c et d (en) « mempo-kernel/kernel-sources/grsecurity/changelog-stable.txt at master · mempo/mempo-kernel », sur GitHub (consulté le ).
  29. ↑ (en-US) exodusintel, « DoS? Then Who Was Phone? », sur Exodus Intelligence, (consulté le ).
  30. ↑ (en) « Grsecurity/Appendix/Grsecurity and PaX Configuration Options - Wikibooks, open books for an open world », sur en.wikibooks.org (consulté le ).
  31. ↑ « grsecurity - An Ancient Kernel Hole is (Not) Closed », sur grsecurity.net (consulté le ).
  32. ↑ « gcc-plugins: Add the randstruct plugin - kernel/git/torvalds/linux.git - Linux kernel source tree », sur git.kernel.org (consulté le ).
  33. ↑ « Introduce struct layout randomization plugin [LWN.net] », sur lwn.net (consulté le ).
  34. ↑ (en-US) Dan Goodin, « Google Chrome exploit fetches "Pinkie Pie" $60,000 hacking prize », sur Ars Technica, (consulté le ).
  35. ↑ « Grsecurity Bypass: Now With More Grsecurity » (consulté le ).
  36. ↑ « Virtually Mapped Kernel Stack Support — The Linux Kernel documentation », sur kernel.org (consulté le ).
  37. ↑ « virtually mapped stacks and thread_info cleanup [LWN.net] », sur lwn.net (consulté le ).
  38. ↑ « arm64: add basic VMAP_STACK support - kernel/git/torvalds/linux.git - Linux kernel source tree », sur git.kernel.org (consulté le ).
  39. ↑ « grsecurity », sur grsecurity.net (consulté le ).
  40. ↑ (en) « Open Source Security Inc. Announces Respectre™: The State of the Art in Spectre Defenses », sur markets.businessinsider.com (consulté le ).
  41. ↑ « grsecurity - How AUTOSLAB Changes the Memory Unsafety Game », sur grsecurity.net (consulté le ).
  42. ↑ (en-US) « Blog - Towards the next generation of XNU memory safety: kalloc_type - Apple Security Research », sur Blog - Towards the next generation of XNU memory safety: kalloc_type - Apple Security Research (consulté le ).
  43. ↑ « PartitionAlloc Design », sur chromium.googlesource.com (consulté le ).
  44. ↑ (en-US) « Survey of security mitigations and architectures, December 2022 », sur memory_safety_blogpost_2022 (consulté le ).
  45. ↑ a et b « grsecurity forums • View topic - The Unseen Benefits of a Security Mindset », sur forums.grsecurity.net (consulté le ).
  46. ↑ « Sanitize 'move_pages()' permission checks - kernel/git/torvalds/linux.git - Linux kernel source tree », sur git.kernel.org (consulté le ).
  47. ↑ « fs/proc, core/debug: Don't expose absolute kernel addresses via wchan - kernel/git/torvalds/linux.git - Linux kernel source tree », sur git.kernel.org (consulté le ).
  48. ↑ (en-US) Dan Goodin, « Skype replaces P2P supernodes with Linux boxes hosted by Microsoft (updated) », sur Ars Technica, (consulté le ).
  49. ↑ « Atomicorp », sur atomicorp.com (consulté le ).
  50. ↑ (en-US) « New server | Blinkenshell Blog » (consulté le ).
  51. ↑ (en-US) « Introducing the DreamShield (formerly Malware Remover) - Website Guides, Tips & Knowledge », sur DreamHost, (consulté le ).
  52. ↑ (en-US) « Important updates to our hosted kernels - Gandi News », sur news.gandi.net, (consulté le ).
  53. ↑ (en) Open Source Security Inc, « Open Source Security Inc's grsecurity Project Gains Sponsorship from OVH », sur prweb.com (consulté le ).
  54. ↑ alpinelinux/linux-stable-grsec, Alpine Linux, (lire en ligne)
  55. ↑ « Features », sur dapperlinux.com (consulté le ).
  56. ↑ (en) Matthew Ruffell, « Maintaining the Unmaintainable: Picking Up the Baton of a Secure Kernel Patchset », LINUX.CONF.AU,‎ (lire en ligne)
  57. ↑ « grsecurity - Debian Wiki », sur wiki.debian.org (consulté le ).
  58. ↑ « Funtoo Security Project — Funtoo », sur funtoo.org (consulté le ).
  59. ↑ « Project:Hardened — Gentoo Wiki », sur wiki.gentoo.org (consulté le ).
  60. ↑ « Hardening », sur subgraph.com (consulté le ).
  61. ↑ « Wind River Documentation », sur docs.windriver.com (consulté le ).

Voir aussi

[modifier | modifier le code]

Articles connexes

[modifier | modifier le code]


Liens externes

[modifier | modifier le code]


Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Grsecurity&oldid=215495971 ».