Aller au contenu

« Grsecurity » : différence entre les versions

Un article de Wikipédia, l'encyclopédie libre.
Navigation interactive dans l’historique
← Modification précédente
Contenu supprimé Contenu ajouté
VisuelWikicode
Jvoisin (discuter | contributions)
100 modifications
m →Fonctionnalités : Ajout de GRKERNSEC_RAND_THREADSTACK
Dhatier (discuter | contributions)
218 423 modifications
m →Fonctionnalités : orthographe
 
(22 versions intermédiaires par 8 utilisateurs non affichées)
Ligne 1 : Ligne 1 :
{{Minuscule}}
{{Minuscule}}
{{ébauche|sécurité informatique}}
{{Infobox Logiciel
{{Infobox Logiciel
| nom = grsecurity
| nom = grsecurity
Ligne 16 : Ligne 15 :


== Histoire ==
== Histoire ==
⚫
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 [[Access Control List|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<ref name=":0">{{Lien web |langue=en |auteur=Bradley Spengler |titre=The case for grsecurity |url=https://grsecurity.net/the_case_for_grsecurity.pdf |format=pdf}}.</ref>.
{{...}}


⚫
À la suite de la perte de son principal sponsor, [[Brad Spengler]] annonce, le {{date|27|décembre|2008|en informatique}}, que le développement du projet pourrait être arrêté<ref>Brad Spengler, [http://article.gmane.org/gmane.linux.kernel.grsecurity/1030 New (final?) grsecurity release and important announcement], 27 décembre 2008</ref>{{,}}<ref>{{lien web|url=http://linuxfr.org//2009/01/06/24850.html|titre=La fin de Grsecurity ?|éditeur=[[Linuxfr]]|date=6 janvier 2009}}.</ref>. 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 {{date-|mars 2009}}.
⚫
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 a inclure [[PaX]], puis se dote d'un système [[Access Control List|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<ref name=":0">{{Lien web |langue=en |auteur=Bradley Spengler |titre=The case for grsecurity |url=https://grsecurity.net/the_case_for_grsecurity.pdf |format=pdf}}</ref>.


Depuis {{date-|aout 2015}}, à 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 [[Informatique embarquée|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 [[Wind River (entreprise)|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<ref>{{lien web |langue=en |auteur=Silviu Stahie |titre=Grsecurity Forced by Multi-Billion Dollar Company to Release Patches Only to Sponsors |url=http://news.softpedia.com/news/grsecurity-forced-by-multi-billion-dollar-company-to-release-patches-only-to-sponsors-490330.shtml |site=softpedia.com |date=2015-08-28 |consulté le=2016-06-21}}.</ref>{{,}}<ref>{{Lien web |titre=Grsecurity stable patches to be limited to sponsors [LWN.net] |url=https://lwn.net/Articles/655721/ |site=lwn.net |consulté le=2023-12-26}}.</ref>{{,}}<ref>{{Lien web |titre=grsecurity |url=https://grsecurity.net/announce |site=grsecurity.net |consulté le=2023-12-26}}.</ref>{{,}}<ref>{{Lien web |titre=Gentoo Forums :: Voir le sujet - Intel Subsidiary's Violations Made Grsec withdraw Stable? |url=https://forums.gentoo.org/viewtopic-t-1031476.html |site=forums.gentoo.org |consulté le=2023-12-26}}.</ref>. Les versions de tests des correctifs de grsecurity et les correctifs sur des fonctionnalités des espaces utilisateurs, restent accessibles au public<ref>{{lien web|langue=en
⚫
À la suite de la perte de son principal sponsor, [[Brad Spengler]] annonce, le {{date|27|décembre|2008|en informatique}}, que le développement du projet pourrait être arrêté<ref>Brad Spengler, [http://article.gmane.org/gmane.linux.kernel.grsecurity/1030 New (final?) grsecurity release and important announcement], 27 décembre 2008</ref>{{,}}<ref>{{lien web|url=http://linuxfr.org//2009/01/06/24850.html|titre=La fin de Grsecurity ?|éditeur=[[Linuxfr]]|date=6 janvier 2009}}</ref>. 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 {{date-|mars 2009}}.

Depuis le {{date-|9 septembre 2015}}, la disponibilité des modifications en stables est devenue limitée aux clients commerciaux de la société. Les versions de tests des correctifs de grsecurity et les correctifs sur des fonctionnalités des espaces utilisateurs, restent accessibles au public<ref>{{lien web|langue=en
| url = http://news.softpedia.com/news/grsecurity-forced-by-multi-billion-dollar-company-to-release-patches-only-to-sponsors-490330.shtml
| titre = Grsecurity Forced by Multi-Billion Dollar Company to Release Patches Only to Sponsors
| date = 2015-08-28 | consulté le = 2016-06-21
| auteur = Silviu Stahie | website = softpedia.com
}}</ref>{{,}}<ref>{{lien web|langue=en
| url = https://grsecurity.net/announce.php
| url = https://grsecurity.net/announce.php
| titre = Important Notice Regarding Public Availability of Stable Patches
| titre = Important Notice Regarding Public Availability of Stable Patches
| date = 2015-08-26 | consulté le = 2016-06-21
| date = 2015-08-26 | consulté le = 2016-06-21
| auteur1 = Brad Spengler | auteur2 = The PaX Team
| auteur1 = Brad Spengler | auteur2 = The PaX Team
| website = grsecurity.net
| site = grsecurity.net
}}</ref>{{,}}<ref>{{lien web|langue=en
}}.</ref>{{,}}<ref>{{lien web|langue=en
| url = https://grsecurity.net/download.php
| url = https://grsecurity.net/download.php
| titre = grsecurity downloads page
| titre = grsecurity downloads page
| consulté le = 2016-06-21
| consulté le = 2016-06-21
| website = grsecurity.net
| site = grsecurity.net
}}</ref>.
}}.</ref>.


Depuis le {{date-|26 avril 2017}}, tous les correctifs sont distribués uniquement aux clients de la société. Toute utilisation des marques grsecurity dans des produits tiers, des dérivés ou des modifications du produit sont également interdites. La licence du produit reste inchangée. (GPLv2) <ref>{{lien web|langue=en
Depuis le {{date-|26 avril 2017}}, tous les correctifs sont distribués uniquement aux clients de la société. La licence du patch, GPLv2, reste inchangée<ref name=":3">{{lien web|langue=en
| url = https://grsecurity.net/passing_the_baton.php
| url = https://grsecurity.net/passing_the_baton.php
| titre = Grsecurity Passing the Baton
| titre = Grsecurity Passing the Baton
| date = 2017-04-26 | consulté le = 2017-04-28
| date = 2017-04-26 | consulté le = 2017-04-28
| auteur = Brad Spengler & The PaX Team | website = grsecurity.com
| auteur = Brad Spengler & The PaX Team | site = grsecurity.com
}}</ref>
}}.</ref>.


== Fonctionnalités ==
== Fonctionnalités ==
Grsecurity inclut [[PaX]], une modification du noyau Linux renforçant significativement sa sécurité. PaX n'est plus disponible hors de grsecurity depuis 2017<ref name=":3" />.
⚫
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, addresses mémoires,<ref name=":0" />...


⚫
grsecurity offre différents moyens d'améliorer l'[[Audit informatique|audit]] du noyau Linux. Il est ainsi possible d'auditer certains utilisateurs ou groupes, les opérations de [[Point de montage|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), …
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<ref name=":1">{{Lien web |langue=en |titre=Grsecurity/Appendix/Grsecurity and PaX Configuration Options - Wikibooks, open books for an open world |url=https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options |site=en.wikibooks.org |consulté le=2023-12-20}}</ref>.


L'option GRKERNSEC_CHROOT permet de durcir significativement la securité des [[Chroot|chroots]], qui n'ont pas été conçus comme un mécanisme de sécurité. Il existe aujourd'hui des solutions de [[Sandbox (sécurité informatique)|sandboxing]] bien plus sûres, comme [[AppArmor]] par exemple.
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<ref name=":1" />.


L'option GRKERNSEC_TPE permet de définir un [[Groupe (Unix)|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 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'[[Address space layout randomization|ASLR]]: quand un processus fils d'un [[Daemon (informatique)|daemon]] est interrompu de maniere suspecte, le processus père ne pourra recréer de fils pendant une certaine durée<ref name=":1" />{{,}}<ref>{{Lien web |langue=en |titre=GRKERNSEC_BRUTE Exploit Bruteforcing Protection |url=https://xorl.wordpress.com/2010/11/09/grkernsec_brute-exploit-bruteforcing-protection/ |site=xorl %eax, %eax |date=2010-11-09 |consulté le=2023-12-20}}</ref>.


En 2002, GRKERNSEC_KMEM est implémenté<ref>{{Lien web |langue=en |titre=oss-sec: Silently (or obliviously) partially-fixed CONFIG_STRICT_DEVMEM bypass |url=https://seclists.org/oss-sec/2017/q2/76 |site=seclists.org |consulté le=2023-12-26}}.</ref>, 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<ref>{{Lien web |langue=en |titre=lockdown: Restrict /dev/{mem,kmem,port} when the kernel is locked down · torvalds/linux@9b9d8dd |url=https://github.com/torvalds/linux/commit/9b9d8dda1ed72e9bd560ab0ca93d322a9440510e |site=GitHub |consulté le=2023-12-26}}.</ref>.
⚫
Une variante de GRKERNSEC_BRUTE est implémentée quelques mois plus tard<ref name=":0" />: 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<ref>{{Lien web |langue=en |titre=GRKERNSEC_KERN_LOCKOUT Active Kernel Exploit Response |url=https://xorl.wordpress.com/2011/04/27/grkernsec_kern_lockout-active-kernel-exploit-response/ |site=xorl %eax, %eax |date=2011-04-27 |consulté le=2023-12-20}}</ref>.


⚫
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,<ref name=":0" />... Cette fonctionnalité fut partiellement implémentée en 2010 dans le noyau linux via l'option kptr_restrict<ref>{{Lien web |titre=kptr_restrict for hiding kernel pointers [LWN.net] |url=https://lwn.net/Articles/420403/ |site=lwn.net |consulté le=2023-12-26}}.</ref>.
⚫
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 [[Smederevo|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<ref>{{Lien web |nom=Keegan |titre=Attacking hardened Linux systems with kernel JIT spraying |url=http://mainisusuallyafunction.blogspot.com/2012/11/attacking-hardened-linux-systems-with.html |site=main is usually a function |date=2012-11-17 |consulté le=2023-12-23}}</ref>{{,}}<ref name="grsecurity forums • View topic - Linux Kernel BPF JIT Spraying">{{Lien web |titre=grsecurity forums • View topic - Linux Kernel BPF JIT Spraying |url=https://forums.grsecurity.net/viewtopic.php?f=7&t=4463 |site=forums.grsecurity.net |consulté le=2023-12-23}}</ref>. En 2016, l'approche choisit par grsecurity fut finalement adoptée par le noyaux Linux<ref>{{Lien web |titre=bpf: add generic constant blinding for use in jits - kernel/git/torvalds/linux.git - Linux kernel source tree |url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4f3446bb809f20ad56cadf712e6006815ae7a8f9 |site=git.kernel.org |consulté le=2023-12-23}}</ref>.


En 2013, suite à un article publié par Exodus Intelligence sur une exécution de code arbitraire sur le logiciel [[Asterisk (logiciel)|Asterisk]]<ref>{{Lien web |langue=en-US |nom=exodusintel |titre=DoS? Then Who Was Phone? |url=https://blog.exodusintel.com/2013/01/07/who-was-phone/ |site=Exodus Intelligence |date=2013-01-07 |consulté le=2023-12-24}}</ref>, GRKERNSEC_RAND_THREADSTACK fut implémentée, ajoutant un décalage aléatoire de 8 bits au tas des threads en espace utilisateur.<ref>{{Lien web |langue=en |titre=Grsecurity/Appendix/Grsecurity and PaX Configuration Options - Wikibooks, open books for an open world |url=https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options |site=en.wikibooks.org |consulté le=2023-12-24}}</ref><ref>{{Lien web |titre=grsecurity - An Ancient Kernel Hole is (Not) Closed |url=https://grsecurity.net/an_ancient_kernel_hole_is_not_closed |site=grsecurity.net |consulté le=2023-12-24}}</ref>
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<ref name=":1">{{Lien web |langue=en |titre=Grsecurity/Appendix/Grsecurity and PaX Configuration Options - Wikibooks, open books for an open world |url=https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options |site=en.wikibooks.org |consulté le=2023-12-20}}.</ref>.


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<ref name=":1" />. 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<ref>{{Lien web |langue=en |auteur=Jon Oberheide |titre=i-can-haz-modharden.c |url=https://jon.oberheide.org/files/i-can-haz-modharden.c |accès url=libre}}.</ref>{{,}}<ref>{{Lien web |titre=LKML: Dan Rosenberg: [PATCH RFC] Restrictions on module loading |url=https://lkml.org/lkml/2010/11/7/212 |site=lkml.org |consulté le=2023-12-24}}.</ref>{{,}}<ref>{{Lien web |titre=NVD - CVE-2010-2959 |url=https://nvd.nist.gov/vuln/detail/CVE-2010-2959 |site=nvd.nist.gov |consulté le=2023-12-24}}.</ref>.
⚫
Le 5 avril 2014, un hacker nommé "comex/PinkiePie"<ref>{{Lien web |langue=en-us |prénom=Dan |nom=Goodin |titre=Google Chrome exploit fetches "Pinkie Pie" $60,000 hacking prize |url=https://arstechnica.com/information-technology/2012/10/google-chrome-exploit-fetches-pinkie-pie-60000-hacking-prize/ |site=Ars Technica |date=2012-10-10 |consulté le=2023-12-23}}</ref> publia une vidéo démontrant une élévation de privilèges sous grsecurity<ref>{{Lien web |langue=fr-FR |titre=Grsecurity Bypass: Now With More Grsecurity |url=https://www.youtube.com/watch?v=SODVDykIemk |consulté le=2023-12-23}}</ref>. 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é<ref name="grsecurity forums • View topic - Linux Kernel BPF JIT Spraying" />:


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<ref>{{Lien web |titre=LKML: Dan Rosenberg: [PATCH] Restrict unprivileged access to kernel syslog |url=https://lkml.org/lkml/2010/11/8/516 |site=lkml.org |consulté le=2023-12-24}}.</ref>.
⚫
* 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<ref>{{Lien web |titre=Virtually Mapped Kernel Stack Support — The Linux Kernel documentation |url=https://www.kernel.org/doc/html/latest/mm/vmalloced-kernel-stacks.html |site=www.kernel.org |consulté le=2023-12-23}}</ref>{{,}}<ref>{{Lien web |titre=virtually mapped stacks and thread_info cleanup [LWN.net] |url=https://lwn.net/Articles/694348/ |site=lwn.net |consulté le=2023-12-23}}</ref>{{,}}<ref>{{Lien web |titre=arm64: add basic VMAP_STACK support - kernel/git/torvalds/linux.git - Linux kernel source tree |url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e3067861ba6650a566a6273738c23c956ad55c02 |site=git.kernel.org |consulté le=2023-12-23}}</ref>.
⚫
* 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 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'[[Address space layout randomization|ASLR]]: quand un processus fils d'un [[Daemon (informatique)|daemon]] est interrompu de maniere suspecte, le processus père ne pourra recréer de fils pendant une certaine durée<ref name=":1" />{{,}}<ref>{{Lien web |langue=en |titre=GRKERNSEC_BRUTE Exploit Bruteforcing Protection |url=https://xorl.wordpress.com/2010/11/09/grkernsec_brute-exploit-bruteforcing-protection/ |site=xorl %eax, %eax |date=2010-11-09 |consulté le=2023-12-20}}.</ref>. Cette fonctionnalité fut qualifiée dans [[Phrack]] de hautement efficace contre l'exploitation de certains types de bogues<ref>{{Lien web |titre=.:: Phrack Magazine ::. |url=http://phrack.org/issues/67/13.html |site=phrack.org |consulté le=2023-12-26}}.</ref>.
⚫
Divers bogues de sécurités sont également corrigés longtemps á l'avance, comme par exemple:


⚫
Une variante de GRKERNSEC_BRUTE est implémentée quelques mois plus tard<ref name=":0" />: 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<ref>{{Lien web |langue=en |titre=GRKERNSEC_KERN_LOCKOUT Active Kernel Exploit Response |url=https://xorl.wordpress.com/2011/04/27/grkernsec_kern_lockout-active-kernel-exploit-response/ |site=xorl %eax, %eax |date=2011-04-27 |consulté le=2023-12-20}}.</ref>.
⚫
* 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<ref name=":2">{{Lien web |titre=grsecurity forums • View topic - The Unseen Benefits of a Security Mindset |url=https://forums.grsecurity.net/viewtopic.php?f=7&t=2574&sid=d590460d08fc15ea41b74d57ad76c23b |site=forums.grsecurity.net |consulté le=2023-12-21}}</ref>{{,}}<ref>{{Lien web |titre=Sanitize 'move_pages()' permission checks - kernel/git/torvalds/linux.git - Linux kernel source tree |url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=197e7e521384a23b9e585178f3f11c9fa08274b9 |site=git.kernel.org |consulté le=2023-12-21}}</ref>.
⚫
* L'abus de wchan pour lire la mémoire du noyau, corrigé en 2004 dans grsecurity, mais seulement en 2015 dans le noyau Linux<ref>{{Lien web |titre=fs/proc, core/debug: Don't expose absolute kernel addresses via wchan - kernel/git/torvalds/linux.git - Linux kernel source tree |url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b2f73922d119686323f14fbbe46587f863852328 |site=git.kernel.org |consulté le=2023-12-21}}</ref>{{,}}<ref name=":2" />.


En avril 2011, Dan Rosenberg et Jon Oberheide publient "Stackjacking: your way grsec/pax to bypass" aux conférence Hackito Ergo Sum et Infiltrate<ref>{{Lien web |titre=Stackjacking Your Way to grsec/PaX Bypass {{!}} Jon Oberheide |url=https://jon.oberheide.org/blog/2011/04/20/stackjacking-your-way-to-grsec-pax-bypass/ |site=jon.oberheide.org |consulté le=2023-12-24}}.</ref>, 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<ref>{{Ouvrage|prénom1=Jon|nom1=Oberheide|titre=jonoberheide/stackjacking|date=2023-09-28|lire en ligne=https://github.com/jonoberheide/stackjacking|consulté le=2023-12-24}}</ref>:
⚫
=== Contrôle d'accès à base de rôles ===


* ''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.
⚫
Il s'agit d'un système de [[contrôle d'accès obligatoire]] (de l'anglais, ''{{Lang|en|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).
* ''Rosengrope,'' abusant le membre ''addr_limit'' de la [[Structure de données|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<ref>{{Lien web |titre=grsecurity forums • View topic - Much Ado About Nothing: A Response in Text and Code |url=https://forums.grsecurity.net/viewtopic.php?f=7&t=2596 |site=forums.grsecurity.net |consulté le=2023-12-24}}.</ref>:
⚫
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.


* thread_info fut déplacée dans sa propre zone mémoire isolée, en dehors de la pile.
=== PaX ===
* 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 [[Smederevo|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<ref>{{Lien web |nom=Keegan |titre=Attacking hardened Linux systems with kernel JIT spraying |url=http://mainisusuallyafunction.blogspot.com/2012/11/attacking-hardened-linux-systems-with.html |site=main is usually a function |date=2012-11-17 |consulté le=2023-12-23}}.</ref>{{,}}<ref name="grsecurity forums • View topic - Linux Kernel BPF JIT Spraying">{{Lien web |titre=grsecurity forums • View topic - Linux Kernel BPF JIT Spraying |url=https://forums.grsecurity.net/viewtopic.php?f=7&t=4463 |site=forums.grsecurity.net |consulté le=2023-12-23}}.</ref>. En 2016, l'approche choisit par grsecurity fut finalement adoptée par le noyaux Linux<ref>{{Lien web |titre=bpf: add generic constant blinding for use in jits - kernel/git/torvalds/linux.git - Linux kernel source tree |url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4f3446bb809f20ad56cadf712e6006815ae7a8f9 |site=git.kernel.org |consulté le=2023-12-23}}.</ref>.
De plus, grsecurity inclut [[PaX]], un correctif permettant de renforcer la sécurité du système en activant les pages non exécutables et en rendant l'espace d'adressage mémoire aléatoire.


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<ref name=":0" />{{,}}<ref name=":4" />.
=== Autres modifications ===


En 2013, à la suite d'un article publié par Exodus Intelligence sur une exécution de code arbitraire sur le logiciel [[Asterisk (logiciel)|Asterisk]]<ref>{{Lien web |langue=en-US |nom=exodusintel |titre=DoS? Then Who Was Phone? |url=https://blog.exodusintel.com/2013/01/07/who-was-phone/ |site=Exodus Intelligence |date=2013-01-07 |consulté le=2023-12-24}}.</ref>, GRKERNSEC_RAND_THREADSTACK fut implémentée, ajoutant un décalage aléatoire de 8 bits a la pile des threads en espace utilisateur<ref>{{Lien web |langue=en |titre=Grsecurity/Appendix/Grsecurity and PaX Configuration Options - Wikibooks, open books for an open world |url=https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options |site=en.wikibooks.org |consulté le=2023-12-24}}.</ref>{{,}}<ref>{{Lien web |titre=grsecurity - An Ancient Kernel Hole is (Not) Closed |url=https://grsecurity.net/an_ancient_kernel_hole_is_not_closed |site=grsecurity.net |consulté le=2023-12-24}}.</ref>.
⚫
grsecurity offre différents moyens d'améliorer l'[[Audit informatique|audit]] du noyau Linux. Il est ainsi possible d'auditer certains utilisateurs ou groupes, les opérations de [[Point de montage|montage]], etc.


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<ref name=":4" />.
Ce correctif rend aussi possible de renforcer la sécurité lors de l'utilisation de [[chroot]], permettant de rendre plus difficile de s'échapper de ce type de cage.

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<ref name=":4">{{Lien web |langue=en |titre=mempo-kernel/kernel-sources/grsecurity/changelog-stable.txt at master · mempo/mempo-kernel |url=https://github.com/mempo/mempo-kernel/blob/master/kernel-sources/grsecurity/changelog-stable.txt |site=GitHub |consulté le=2023-12-26}}.</ref>. Cette fonctionnalité fut partiellement intégrée au noyau Linux en juin 2017 par Kees Cook<ref>{{Lien web |titre=gcc-plugins: Add the randstruct plugin - kernel/git/torvalds/linux.git - Linux kernel source tree |url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=313dd1b629219db50cad532dba6a3b3b22ffe622 |site=git.kernel.org |consulté le=2023-12-26}}.</ref>{{,}}<ref>{{Lien web |titre=Introduce struct layout randomization plugin [LWN.net] |url=https://lwn.net/Articles/719732/ |site=lwn.net |consulté le=2023-12-26}}.</ref>.

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<ref name=":4" />.

⚫
Le 5 avril 2014, un hacker nommé "comex/PinkiePie"<ref>{{Lien web |langue=en-us |prénom=Dan |nom=Goodin |titre=Google Chrome exploit fetches "Pinkie Pie" $60,000 hacking prize |url=https://arstechnica.com/information-technology/2012/10/google-chrome-exploit-fetches-pinkie-pie-60000-hacking-prize/ |site=Ars Technica |date=2012-10-10 |consulté le=2023-12-23}}.</ref> publia une vidéo démontrant une élévation de privilèges sous grsecurity<ref>{{Lien web |langue=fr-FR |titre=Grsecurity Bypass: Now With More Grsecurity |url=https://www.youtube.com/watch?v=SODVDykIemk |consulté le=2023-12-23}}.</ref>. 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é<ref name="grsecurity forums • View topic - Linux Kernel BPF JIT Spraying" />:

⚫
* 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<ref>{{Lien web |titre=Virtually Mapped Kernel Stack Support — The Linux Kernel documentation |url=https://www.kernel.org/doc/html/latest/mm/vmalloced-kernel-stacks.html |site=kernel.org |consulté le=2023-12-23}}.</ref>{{,}}<ref>{{Lien web |titre=virtually mapped stacks and thread_info cleanup [LWN.net] |url=https://lwn.net/Articles/694348/ |site=lwn.net |consulté le=2023-12-23}}.</ref>{{,}}<ref>{{Lien web |titre=arm64: add basic VMAP_STACK support - kernel/git/torvalds/linux.git - Linux kernel source tree |url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e3067861ba6650a566a6273738c23c956ad55c02 |site=git.kernel.org |consulté le=2023-12-23}}.</ref>.
⚫
* 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 (vulnérabilité)|Spectre]] et ses dérivés<ref>{{Lien web |titre=grsecurity |url=https://grsecurity.net/respectre_announce |site=grsecurity.net |consulté le=2023-12-26}}.</ref>{{,}}<ref>{{Lien web |langue=en |titre=Open Source Security Inc. Announces Respectre™: The State of the Art in Spectre Defenses |url=https://markets.businessinsider.com/news/stocks/open-source-security-inc-announces-respectre-the-state-of-the-art-in-spectre-defenses-1027594190 |site=markets.businessinsider.com |consulté le=2023-12-26}}.</ref>.

En 2021, AUTOSLAB est implémenté via un plugin [[GNU Compiler Collection|gcc]], isolant automatiquement les objets alloués sur le tas en [[espace noyau]] par types<ref>{{Lien web |titre=grsecurity - How AUTOSLAB Changes the Memory Unsafety Game |url=https://grsecurity.net/how_autoslab_changes_the_memory_unsafety_game |site=grsecurity.net |consulté le=2023-12-24}}.</ref>. Cette approche est similaire à celle utilisé par Apple en 2022 via kmalloc_type<ref>{{Lien web |langue=en-US |titre=Blog - Towards the next generation of XNU memory safety: kalloc_type - Apple Security Research |url=https://security.apple.com/blog/towards-the-next-generation-of-xnu-memory-safety/ |site=Blog - Towards the next generation of XNU memory safety: kalloc_type - Apple Security Research |consulté le=2023-12-24}}.</ref>, ou encore PartitionaAlloc dans [[Google Chrome|Chrome]], qui sont elles manuelles<ref>{{Lien web |titre=PartitionAlloc Design |url=https://chromium.googlesource.com/chromium/src/+/master/base/allocator/partition_allocator/PartitionAlloc.md |site=chromium.googlesource.com |consulté le=2023-12-24}}.</ref>. Cette isolation complexifie significativement l'exploitation de [[Dangling pointer|use-after-free]] et de confusion de types<ref>{{Lien web |langue=en-US |titre=Survey of security mitigations and architectures, December 2022 |url=https://saaramar.github.io/memory_safety_blogpost_2022/ |site=memory_safety_blogpost_2022 |consulté le=2023-12-24}}.</ref>.

⚫
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<ref name=":2">{{Lien web |titre=grsecurity forums • View topic - The Unseen Benefits of a Security Mindset |url=https://forums.grsecurity.net/viewtopic.php?f=7&t=2574&sid=d590460d08fc15ea41b74d57ad76c23b |site=forums.grsecurity.net |consulté le=2023-12-21}}.</ref>{{,}}<ref>{{Lien web |titre=Sanitize 'move_pages()' permission checks - kernel/git/torvalds/linux.git - Linux kernel source tree |url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=197e7e521384a23b9e585178f3f11c9fa08274b9 |site=git.kernel.org |consulté le=2023-12-21}}.</ref>.
⚫
* L'abus de wchan pour lire la mémoire du noyau, corrigé en 2004 dans grsecurity, mais seulement en 2015 dans le noyau Linux<ref>{{Lien web |titre=fs/proc, core/debug: Don't expose absolute kernel addresses via wchan - kernel/git/torvalds/linux.git - Linux kernel source tree |url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b2f73922d119686323f14fbbe46587f863852328 |site=git.kernel.org |consulté le=2023-12-21}}.</ref>{{,}}<ref name=":2" />.

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

⚫
Il s'agit d'un système de [[contrôle d'accès obligatoire]] (de l'anglais, ''{{Lang|en|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.


== Usages historiques notables ==
== Utilisateurs historiques notables ==
Suite à l'indisponibilité publique de grsecurity, le usagers cités citées ci-dessous n'en font plus usage, sans mention explicite.
À la suite de l'indisponibilité publique de grsecurity, les utilisateurs cités ci-dessous n'en font plus usage, sans mention explicite.


* [[Skype]]<ref>{{Lien web |langue=en-us |prénom=Dan |nom=Goodin |titre=Skype replaces P2P supernodes with Linux boxes hosted by Microsoft (updated) |url=https://arstechnica.com/information-technology/2012/05/skype-replaces-p2p-supernodes-with-linux-boxes-hosted-by-microsoft/ |site=Ars Technica |date=2012-05-01 |consulté le=2023-12-20}}</ref>
* [[Skype]]<ref>{{Lien web |langue=en-us |prénom=Dan |nom=Goodin |titre=Skype replaces P2P supernodes with Linux boxes hosted by Microsoft (updated) |url=https://arstechnica.com/information-technology/2012/05/skype-replaces-p2p-supernodes-with-linux-boxes-hosted-by-microsoft/ |site=Ars Technica |date=2012-05-01 |consulté le=2023-12-20}}.</ref>


=== Hebergeurs ===
=== Hebergeurs ===


* AtomiCorp<ref>{{Lien web |titre=Atomicorp |url=https://www.atomicorp.com/kernel/3.2/grsecurity/ |site=www.atomicorp.com |consulté le=2023-12-20}}</ref>
* AtomiCorp<ref>{{Lien web |titre=Atomicorp |url=https://www.atomicorp.com/kernel/3.2/grsecurity/ |site=atomicorp.com |consulté le=2023-12-20}}.</ref>
* DreamHost<ref>{{Lien web |langue=en-US |titre=Introducing the DreamShield (formerly Malware Remover) - Website Guides, Tips & Knowledge |url=https://www.dreamhost.com/news/announcements/introducing-dreamshield-website-malware-remover/ |site=DreamHost |date=2016-09-27 |consulté le=2023-12-20}}</ref>
* Blinkenshell<ref>{{Lien web |langue=en-US |titre=New server {{!}} Blinkenshell Blog |url=https://independence.blinkenshell.org/blog/2010/08/08/new-server/ |consulté le=2023-12-26}}.</ref>
* DreamHost<ref>{{Lien web |langue=en-US |titre=Introducing the DreamShield (formerly Malware Remover) - Website Guides, Tips & Knowledge |url=https://www.dreamhost.com/news/announcements/introducing-dreamshield-website-malware-remover/ |site=DreamHost |date=2016-09-27 |consulté le=2023-12-20}}.</ref>
* [[Gandi (entreprise)|Gandi]]<ref>{{Lien web |langue=en-US |titre=Important updates to our hosted kernels - Gandi News |url=https://news.gandi.net/en/2016/02/Important-updates-to-our-hosted-kernels/ |site=https://news.gandi.net/ |date=2016-02-04 |consulté le=2023-12-20}}</ref>
* [[Gandi (entreprise)|Gandi]]<ref>{{Lien web |langue=en-US |titre=Important updates to our hosted kernels - Gandi News |url=https://news.gandi.net/en/2016/02/Important-updates-to-our-hosted-kernels/ |site=news.gandi.net |date=2016-02-04 |consulté le=2023-12-20}}.</ref>
* [[OVHcloud|OVH]]<ref>{{Lien web |langue=en |prénom=Open Source Security |nom=Inc |titre=Open Source Security Inc's grsecurity Project Gains Sponsorship from OVH |url=https://www.prweb.com/releases/open_source_security_inc_s_grsecurity_project_gains_sponsorship_from_ovh/prweb13479733.htm |site=www.prweb.com |consulté le=2023-12-20}}</ref>
* [[OVHcloud|OVH]]<ref>{{Lien web |langue=en |prénom=Open Source Security |nom=Inc |titre=Open Source Security Inc's grsecurity Project Gains Sponsorship from OVH |url=https://www.prweb.com/releases/open_source_security_inc_s_grsecurity_project_gains_sponsorship_from_ovh/prweb13479733.htm |site=prweb.com |consulté le=2023-12-20}}.</ref>


=== Distributions Linux ===
=== Distributions Linux ===
Ligne 105 : Ligne 124 :
* [[Alpine Linux]]<ref>{{Ouvrage|titre=alpinelinux/linux-stable-grsec|éditeur=Alpine Linux|date=2021-09-27|lire en ligne=https://github.com/alpinelinux/linux-stable-grsec|consulté le=2023-12-20}}</ref>
* [[Alpine Linux]]<ref>{{Ouvrage|titre=alpinelinux/linux-stable-grsec|éditeur=Alpine Linux|date=2021-09-27|lire en ligne=https://github.com/alpinelinux/linux-stable-grsec|consulté le=2023-12-20}}</ref>
* [[Arch Linux]], via le paquet linux-grsec
* [[Arch Linux]], via le paquet linux-grsec
* DapperLinux<ref>{{Lien web |titre=Features |url=https://dapperlinux.com/features.html |site=dapperlinux.com |consulté le=2023-12-26}}.</ref>{{,}}<ref>{{Article|langue=en|auteur1=Matthew Ruffell|titre=Maintaining the Unmaintainable: Picking Up the Baton of a Secure Kernel Patchset|périodique=LINUX.CONF.AU|date=January 2019|lire en ligne=https://ruffell.nz/assets/documents/2019_LCA_Maintaining_the_Unmaintainable.pdf}}</ref>
⚫
* [[Debian]], via le paquet linux-image-grsec<ref>{{Lien web |titre=grsecurity - Debian Wiki |url=https://wiki.debian.org/grsecurity |site=wiki.debian.org |consulté le=2023-12-20}}</ref>
* [[Gentoo Linux|Gentoo]], dans sa variante "hardened"<ref>{{Lien web |titre=Project:Hardened — Gentoo Wiki |url=https://wiki.gentoo.org/wiki/Project:Hardened |site=wiki.gentoo.org |consulté le=2023-12-20}}</ref>
* [[Debian]], via le paquet linux-image-grsec<ref>{{Lien web |titre=grsecurity - Debian Wiki |url=https://wiki.debian.org/grsecurity |site=wiki.debian.org |consulté le=2023-12-20}}.</ref>
* Subgraph OS<ref>{{Lien web |titre=Hardening |url=https://subgraph.com/sgos/hardening/index.en.html |site=subgraph.com |consulté le=2023-12-20}}</ref>
* [[Funtoo]]<ref>{{Lien web |titre=Funtoo Security Project — Funtoo |url=https://www.funtoo.org/Funtoo:Security |site=funtoo.org |consulté le=2023-12-26}}.</ref>
* [[Wind River (entreprise)|Wind River]] Linux<ref>{{Lien web |titre=Wind River Documentation |url=https://docs.windriver.com/bundle/Wind_River_Linux_Security_Profile_Users_Guide_6.0_1/page/1566349.html |site=docs.windriver.com |consulté le=2023-12-20}}</ref>
* [[Gentoo Linux|Gentoo]], dans sa variante "hardened"<ref>{{Lien web |titre=Project:Hardened — Gentoo Wiki |url=https://wiki.gentoo.org/wiki/Project:Hardened |site=wiki.gentoo.org |consulté le=2023-12-20}}.</ref>
⚫
* Subgraph OS<ref>{{Lien web |titre=Hardening |url=https://subgraph.com/sgos/hardening/index.en.html |site=subgraph.com |consulté le=2023-12-20}}.</ref>
* [[Wind River (entreprise)|Wind River]] Linux<ref>{{Lien web |titre=Wind River Documentation |url=https://docs.windriver.com/bundle/Wind_River_Linux_Security_Profile_Users_Guide_6.0_1/page/1566349.html |site=docs.windriver.com |consulté le=2023-12-20}}.</ref>


== Notes et références ==
== Notes et références ==

Dernière version du 29 mai 2024 à 21:08

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 ».