La fonctionnalité la plus connue d'Openwall est certainement l'option qui consiste à rendre la pile noyau non exécutable. Mais il ne fait pas que cela, vous le découvrirez dans cet article.
Ce qui est dommage c'est que ce patch n'est pour l'instant disponible que pour les versions 2.2.x du noyau (même si les travaux pour le 2.4.x sont en cours). Ceux qui utlisent les noyaux 2.4.x se tourneront peut-être plus facilement vers le patch Grsecurity.
NdR : Ceci est une adaptation/traduction du début de l'article...
NdM : Grsecurity r0x0r !
Aller plus loin
- L'article (4 clics)
- Le site d'Openwall (5 clics)
- Le site de Grsecurity (4 clics)
# Quels sont les défauts ?
Posté par Éric (site web personnel) . Évalué à 10.
Par exemple dans la news on parle de pile non exécutable, pourquoi ne la rend pas non exécutable par défaut dans les noyeaux ?
Ca doit gerner des choses je pense mais quoi ...
(si ca ne gène rien je ne comprend pas que ca ne soit pas un défaut partout)
Quelqu'un a des docs FR sur ce genre de trucs ?
[^] # Re: Quels sont les défauts ?
Posté par Kobalt . Évalué à 10.
En gros, certaines modifications qu'ils apportent se retrouvent effectivement dans le kernel au bout d'un moment.
Par contre, les "hardening features" (sait pas trop comment traduire) ne sont pas integrées. Cela peut, selon eux, apporter un faux sentiment de sécurité aux développeurs et les inciter à se "reposer" sur un noyau sûr au lieu de vérifier leur applis.
[^] # Re: Quels sont les défauts ?
Posté par Xavier Poinsard . Évalué à -5.
[^] # Re: Quels sont les défauts ?
Posté par PLuG . Évalué à 9.
Certainement pas les logiciels opensource qui sont compilables a merci sur plein de plateformes ...
Honnetement, je ne voit pas trop ce que cela peut apporter a un programme, ni d'ailleur du point de vue sécurité. C'est d'ailleur pour cela que Linus avait refusé de rendre la pile non-executable par defaut dans Linux.
Rappel:
La plupart des exploit "debordement de buffer" pour x86 utilisent la pile pour stocker le code a executer (lancer un shell root par exemple). C'est pourquoi certains veulent rendre la pile non-executable. Mais rendre la pile non-executable ne change rien au probleme (debordement de buffer) et plusieurs exploits utilisant d'autres endroits que la pile pour stocker leur code ont déjà été diffusés.
Si la pile de linux est non executable, tous les exploits seront fait avec d'autres techniques mais ils existeront toujours.
Cela n'apporte RIEN (ou si peu) puisque cela ne complique meme pas vraiment l'ecriture de nouveaux exploits.
[^] # Re: Quels sont les défauts ?
Posté par ggl . Évalué à 10.
Il y a aussi LIDS comme projet de patches noayu linux:
http://www.lids.org(...)
[^] # Re: Quels sont les défauts ?
Posté par Éric (site web personnel) . Évalué à 10.
Mais est ce une raison pour ne pas boucher là ou on peut ?
Pour moi ca reviendrait à mettre tous les binaires qui sont executables uniquement par root, en SUID root en me disant que de toute facon si quelqu'un y accede c'est qu'il y a une faille ailleurs et qu'il pourra faire autre chose de toute facon :)
Ou de ne mettre aucune gestion d'erreur nulle part en me disant que de toute facon si ca coince le probleme est à un autre niveau.
Meme si ca ne corrige rien ca peut empeche une exploitation (ou simplement la retarder car ca rendrait plsu complexe la chose). Même si ca ne concernait qu'un bug en 10 an qu'il serait trop compliqué à exploiter sans pile exécutable alors peut etre que ca vaut le coup ....
Laisser une porte ouverte en disant que de toute facon :
1. le portail est fermé donc ils n'arriveront pas jusqu'a la porte
2. si ils passent le portail la porte de derriere est de toute facon pas trop compliquer à ouvrir
Me semble une vrai horreur et c'est ce que je comprend de ton message.
J'espere que j'ai mal compris
[^] # Re: Quels sont les défauts ?
Posté par PLuG . Évalué à 6.
a la limite, si toi dans ton coin tu rend la pile linux non executable, tu te protegera des exploits qui stockent leur code en pile, et pas des autres.
si tout le noyau linux a une pile non-executable, tous les exploits seront codés en consequence. et de nouveau tout le monde sera succeptible d'etre infecté par les script-kiddie. Ce probleme de pile-non executable ne protege que des script-kiddies, les autres (ceux qui codent) adapteront l'exploit a ta nouvelle pile de toutes facons.
bref j'ai pas dit que c'etait mal, j'ai juste dit que ca ne change pas vraiment le probleme.
utilisons une comparaison puisque tu as l'air d'apprecier.
la porte de ta maison a un gros trou (buffer overflow), alors tu piege l'allée centrale qui y mène (pile), en esperant que personne ne passera par la pelouse ....
[^] # Re: Quels sont les défauts ?
Posté par Xavier Poinsard . Évalué à 6.
The problem with a non-executable stack is that there are legitimate uses for executing code on the stack - among these are signal handlers in the Linux kernel and the use of "trampolines" to facilitate the use of nested functions (an extension of the C language) by GCC. To deal with this problem, the Openwall patch allows users the option of emulating trampolines (in most cases, this shouldn't cause much extra overhead). The emulation of trampolines is made available as a separate option: if you enable it, the chances of the emulation being tricked by an exploit are greater, if you don't enable it, you run the risk of some your applications breaking (test it!)
[^] # Re: Quels sont les défauts ?
Posté par Thomas Cataldo (site web personnel) . Évalué à 3.
En plus ca ne protège en rien contre les buffers overflow. Le principe étant d'inserer une instruction de saut vers un sous-programme qui lance un shell, linus torvals a rejetté le patch en expliquant qu'au lieu de sauter vers du code à nous, il suffit de sauter vers la fonction exec de la libc.
# NdM de rebelz
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
bon ok -1
[^] # Re: NdM de rebelz
Posté par Amaury . Évalué à -2.
[^] # Re: NdM de rebelz
Posté par Olivier . Évalué à -1.
Alors je la repose :
"ça serait bien que les modérateurs se modèrent, et qu'au lieu d'écrire en gros rebelz certain aille rajouter un mode réseau dans frozen-bubble..."
# un peu dégouté ;()
Posté par Code34 (site web personnel) . Évalué à 6.
Je suis un peu dégouté, car j'ai vu que le patch Rtlinux disponible sur rtlinux.org, l'ai maintenant sur rtlinux.com [..] et qu'il faut payer ;) Les autres patch ne s'adresse qu'a des kernels 2.2.
On dirait bien que le développement à tout simplement cesser en 2000.
Meme chose, je suis allé voir openwall, ça a pas l'air de vraimment bougé... (je suis un peu surpris de le voir en news d'ailleurs)
Quelqu un aurait une url d'un site qui répertorie des patchs récents pour les kernels 2.4 ou 2.5 ?
@ tte
Code34
[^] # Re: un peu dégouté ;()
Posté par wismerhill . Évalué à 1.
http://linux-patches.rock-projects.com/(...)
http://folk.sourceforge.net/(...)
http://kernelnewbies.org/patches/(...)
[^] # [OT] Re: un peu dégouté ;()
Posté par Def . Évalué à 2.
Par curiosité tu fais quoi comme appli ?
# A lire...
Posté par Matafan . Évalué à 10.
C'est un excellent document sur les attaques par débordement de buffer (pile et tas) et les moyens de s'en prémunir au niveau système (comprenez sans modifier les programmes vulnérables) :
- libsafe : interception des appels aux fonctions sensibles de la libc, avec ajout de tests de débordement
- OpenWall : patch kernel rendant la pile non exécutable
- PaX : même chose, avec en plus un tas (heap) non exécutable, un "brouillage" des addresses des fonctions de la libc...
- Prelude : reporting des tentatives de débordement
L'article ne se contente pas de présenter ces dispositifs de manière théorique ; il explique aussi concrètement comment les mettre en place, évalue leur efficacité face aux BOF et HOF, et mesure (rapidement) leur impact en termes de performances.Bref, une lecture particulièrement intéressante.
[^] # Re: A lire...
Posté par vjm . Évalué à 6.
libsafe ça necessite de patcher la libc.
PaX ne fonctionne que sur x86 puisqu'il rend la pile non executable via la gestion du paging sur IA 32.
Prelude - qui est un IDS - rapporte les debordements de buffers au niveau host via libsafe et prochainement via un plugin PaX à prelude-lml (analyse de logs), et au niveau réseau bien sûr via un pattern matching classique (et peut être bientôt du protocol analysis ? :) avec la gestion des NOP polymorphes (comme l'a fait ensuite spp_fnord.c de dragos ruiu pour snort).
http://www.prelude-ids.org(...)
[^] # Re: A lire...
Posté par tfing . Évalué à 2.
il suffit de la foutre en LD_PRELOAD pour qu'elle agisse
son interêt c'est justement de pas avoir besoin de recompiler de sources pour qu'elle soit utile
[^] # Re: A lire...
Posté par Matafan . Évalué à 3.
L'idée de libsafe n'est pas de patcher la libc, mais bien d'intercepter les appels. Il suffit pour celà qu'elle soit chargée avant la libc, via LD_PRELOAD ou /etc/ld.so.preload. Elle agit ensuite comme un wrapper, appelant les fonctions de la libc si les contrôles de taille sont passés.
A noter que ce n'est pas une sécurité absolue, comme l'article le précise. D'abord les softs liés statiquement n'en bénéficient pas, ni ceux compilés avec -fomit-frame-pointer. Ensuite elle ne protège que des BOF "classique", mais n'empêche pas d'écraser des données empilées après l'addresse de retour (un pointeur vers une fonction par exemple).
[^] # Question
Posté par Moby-Dik . Évalué à -4.
Prelude - qui est un IDS - rapporte les debordements de buffers au niveau host via libsafe et prochainement via un plugin PaX à prelude-lml (analyse de logs), et au niveau réseau bien sûr via un pattern matching classique (et peut être bientôt du protocol analysis ? :) avec la gestion des NOP polymorphes (comme l'a fait ensuite spp_fnord.c de dragos ruiu pour snort).
C'est bien joli tout ça mais est-ce que ça va me permettre enfin d'écouter mes CDs de Céline Dion sur ma Lindows Playschool Edition beta 9 ?
Je dis ça parce que j'ai déjà essayé de recompiler mon noyau pour changer la couleur des icônes mais ça marche pas, Java ne veut pas lancer le fichier bzImage même après avoir désactivé le high precision timer pour support SMP :(( Et la personne (gentille et charmante par ailleurs, pas comme ces utilisateurs de Debian) du support Lindows m'a dit que si mon noyau n'était pas certifié Microsoft, eh ben ils ne pouvaient rien faire à part m'offrir un MP3 de Richard Stallman.
# problème
Posté par jkw . Évalué à 1.
ça fait plaisir de voir ce post car j'ai installé openwall en début de semaine :)
jel'ai installé sur un kernel 2.2.20 sur une machine de test RedHat 6.2, tout marche bien (meme X avec chstck) sinon que j'arrive plus à utiliser ma souris...
gpm au démarrage ne va plus et qd je lance X je ne peux plus la bouger. j'ai essayé de choisir une autre souris ds la conf de X mais rien n'y fait, et de plus j'ai pas d'alerte de syslog comme quoi ça aurait un rapport avec la stack non-exec
des gens ont-il deja eu ce pb ou des idées?
paske X sans souris c un peu la m..
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.