La prochaine release d'OpenBSD (la 3.8) contiendra une nouvelle façon de gérer les allocations de mémoire. En gros ce sera plus sécurisé et plus strict qu'avant.
Theo de Raadt a lancé un appel aux tests car cette nouveauté risque de casser les logiciels qui sont mal codés.
Questions pour ceux qui savent :
1) En quoi cette "amélioration de l'allocation mémoire" est elle différente des patchs PaX ou GRSecurity qui existent déja pour Linux (et qui sont je crois inclus dans la Fedora non ?)
2) Quel sera la pénalité au point de vue vitesse ?
3) est-ce prudent/logique/normal/risqué/aberrant de changer ainsi le fonctionnement de routines aussi importantes que malloc ou mmap ?
Vu sur http://kerneltrap.org/node/5584(...)
Journal "Improved Memory Allocation" dans OpenBSD 3.8
24
août
2005
# Choix cornélien
Posté par Lagoon . Évalué à 5.
Concernant le point 3, c'est effectivement un problème crucial et général. Il arrive malheureusement que des programmes dépendent, volontairement ou non, de détails d'implémentation qui sont suceptibles de changer à tout moment (effets de bord, fonctions non documentées, etc.).
Je pense qu'on ne devrait pas se retenir de changer (et améliorer) une implémentation sous prétexte que des programmes bogués en dépendent. Comme le dit Theo, c'est un peu dur au début, le temps de corriger les programmes, mais au final tout le monde y gagne : le système étant moins laxiste, il laisse passer moins de bugs.
Mais c'est parfois plus facile à dire qu'à faire. Microsoft, garant de la sacro-sainte compatibilité, a souvent préféré faire l'inverse. Le blog « The Old New Thing » de l'un des programmeurs du noyau de Windows regorge d'histoires croustillantes expliquant certains choix techniques pris historiquement par Microsoft (au hasard http://blogs.msdn.com/oldnewthing/archive/2003/12/24/45779.aspx(...) ). Je me rappelle notamment qu'une faille avait dû être insérée dans le noyau de Windows 95 uniquement car Sim City en dépendait, et sortir un nouveau Windows incompatible avec l'un des jeux phares du moment aurait été impensable (invendable).
[^] # Re: Choix cornélien
Posté par patrick_g (site web personnel) . Évalué à 2.
[^] # Re: Choix cornélien
Posté par Alexandre Belloni (site web personnel) . Évalué à 1.
[^] # Re: Choix cornélien
Posté par Krunch (site web personnel) . Évalué à 5.
À plus ou moins long terme ça ne peut être qu'une bonne chose: ça va permettre de découvrir et corriger beaucoup de bugs dans beaucoup de programmes (il suffit de voir l'exemple de X qui est cité).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Choix cornélien
Posté par Guillaume Knispel . Évalué à 4.
2) Si la nouvelle implantation met à jour des bugs dans des applis codées avec les pieds c'est en revanche bénéfique (car les bugs des applis seront corrigés, ce qui d'ailleurs profitera à tout le monde utilisant les applis en question).
Un bug qu'on ne voit pas est infiniment plus dangereux qu'un bug qu'on repere et qu'on corrige.
Un bug d'allocation mémoire qui ne se repere pas à cause d'un fonctionnement particulier d'une implantation de malloc/free est on ne peut plus pernitieux (nuit à la compabilité, nuit à la sécurité, nuit à la maintenance, etc...) .
[^] # Re: Choix cornélien
Posté par notbugme . Évalué à -10.
Mon code ne tourne pas sous OpenBSD ? Mince alors, je perds 3 utilisateurs potentiels. De toute façon, s'il est sous GPL, ils ne s'en seraient pas servi de peur d'être contaminés.
[^] # Re: Choix cornélien
Posté par Tony Cheneau (site web personnel) . Évalué à 7.
On voit que certaines personnes ont les c***ll*s pour dire des conneries et les assumer.
En lisant ton post, j'ai hésité entre très mauvais humour ou personne à temps de latence élevé dans la tête.
J'avoue qu'à l'heure actuelle j'hésite toujours.
(et désolé pour ceux qui liront ma "pseudo" réponse, mais voir ce genre de post me...)
# Points 1) et 2)
Posté par un_brice (site web personnel) . Évalué à 2.
La mémoire est allouée en un emplacement aléatoire, ce qui rend plus difficile la création de shellcodes (existe dans Grsec, faible impact sur les perfs je pense).
Mais en plus, on évite d'allouer deux zones adjacentes, histoire d'éviter qu'elle finisse par se recouvrir (ça je crois pas que ça existe sous GNU/Linux, mais c'est possible).
Idée de "guard page", allouée aux extrémités des plages mémoires légitimes et qui risquent d'être un peu comme les canaris du compilateur de windows : des zones qui si elles sont altérées provoqueront l'arrêt brutal du programme. Ça a été implanté dans GCC sous le nom de SSP, justement par les gars d'OpenBSD je crois, donc à priori c'est la même chose que sous Linux. Par compte je crois que ça a des effets sur les perfs, au point que microsoft interdit de diffuser des benchs de windows 2003 (qui y a recours).
Et apparement free() libère de suite la mémoire, je suppose qu'avant la libc5 la gardait sous le code pour limiter les appels système.
Et pour le 3)... à priori les problème de compatiblité ont déjà être du bien balayés par la disponibilité sous Linux depuis un certain temps d'un grand nombre des techniques présentée.
[^] # Re: Points 1) et 2)
Posté par Krunch (site web personnel) . Évalué à 2.
SSP/ProPolice est bien utilisé dans OBSD (et DFBSD d'après Wikipédia) et j'ai cru comprendre que les développeurs OBSD ont passé pas mal de temps à bidouiller dessus mais c'est pas eux qui l'ont crée.
La plupart de ces mesures de sécurité ont effectivement des impacts plus ou moins grands sur les performances mais au final ça ne peut être que bénéfique.
AFAIK, aucune des ces mesures de sécurité (guard page, malloc randomisation, free(3) qui munmap(2) à tous les coups ou presque) n'est implémentée dans le noyau Linux normal.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Points 1) et 2)
Posté par Krunch (site web personnel) . Évalué à 3.
Tout ça pour dire que ça c'est certainement pas dans PaX/grsec et donc que des bugs on va en trouver.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.