Premier patch 'NX' pour le noyau Linux

Posté par  . Modéré par Mouns.
Étiquettes :
0
3
juin
2004
Matériel
Ingo Molnar l'a annoncé aujourd'hui sur la LKML (Linux Kernel Mailing List) : le premier patch 'NX' pour notre bien aimé noyau est disponible. Si la technologie NX est disponible sur le processeur, le noyau ainsi modifié interdit l'exécution des buffers et de la pile. À ma connaissance Linux est le premier OS à implémenter cette technologie (NdM : non). Un noyau patché est déjà disponible pour la Fedora Core sous le nom kernel-2.6.6-1.411.
Pour rappel NX signifie No eXecute, cette technologie rend plus difficile l'écriture de code malicieux utilisant des exploits de types dépassement de tampon ou dépassement de pile. En effet les processeurs disposant de la technologie NX ajoutent deux drapeaux aux pages mémoires allouées, à savoir le drapeau 'execute' et le drapeau 'no execute' ; ce dernier interdit l'exécution de la zone mémoire allouée.

Aller plus loin

  • # Desole...

    Posté par  . Évalué à 10.

    Ben non c'est pas le premier, le SP2 de XP contient ca depuis un petit moment deja, et je suis a peu pres sur d'ailleurs que XP n'etait pas le premier non plus, il me semble qu'OpenBSD le faisait deja aussi, mais je n'en suis pas sur
    • [^] # Re: Desole...

      Posté par  . Évalué à 2.

      c'est quoi les proc qui les flags NX ?
      • [^] # Re: Desole...

        Posté par  . Évalué à 8.

        AMD64 & IA64 pour ce qui concerne XP, les cpu Intel 32bits ne l'ont pas, mais d'autres CPUs ont ce type de flags depuis des annees, simplement ils ne sont pas assez connu pour que cela se sache.
        • [^] # Re: Desole...

          Posté par  . Évalué à 7.

          d'après cette news: http://www.hardware.fr/news/imprimer/6626/(...) les prochains cores (E-0) du Prescott permettra aussi la protection des pages mémoires contre l'execution.

          Sinon, d'après ce que je sais (lu dans Understanding the Linux Kernel: http://www.oreilly.com/catalog/linuxkernel/(...) ), presque tous les processeur n'ayant pas de casserolles à traîner pour compatibilité ascendante (donc non-X86) ont la possibilité de protéger leurs pages mémoire. Cette technologie est donc tout sauf nouvelle.
        • [^] # Re: Desole...

          Posté par  . Évalué à 1.

          J'ai pas verifié mais il me semble que les powerpc ont ça, non ?
          • [^] # Re: Desole...

            Posté par  . Évalué à 5.

            Au niveau des pages tu as au moins : AMD64, Sparc64, sparc, powerpc, alpha, sh5, hppa

            Systèmes batards (gestion niveau segmentation plus ou moins réussi) : i386, powerpc

            Qui ne gère rien :arm, m68k, mips, sparc, vax

            (oui sparc et ppc apparaissent plusieurs fois :-)

            http://citeseer.ist.psu.edu/jacob97memory.html(...)
            http://citeseer.ist.psu.edu/34758.html(...)
            • [^] # Re: Desole...

              Posté par  . Évalué à 0.

              Heu, les 68030 et 68040 étaient accompagnés des mmu 68881 et 68882, séparés ou intégrés au processeur selon les version, qui jouaient donc bien le role de pagination.
              • [^] # Re: Desole...

                Posté par  . Évalué à 2.

                On parle de NX hard et mon commentaire ne faisait que montrer que certaines veilles architectures supportaient NX depuis des lustres et d'autres pas et par quel biais (segmentation ou pagination). Après je peux aussi me planter mais je ne pense pas.

                Trouves moi la dedans ou c'est dispo.

                http://e-www.motorola.com/files/32bit/doc/ref_manual/M68040UM.pdf(...)
                http://e-www.motorola.com/files/32bit/doc/ref_manual/MC68040UM.pdf(...)
                • [^] # Re: Desole...

                  Posté par  . Évalué à 2.

                  si je ne me trompe Transmeta l'a annonce recement pour un proco qui va sortir ou qui est sorti.
              • [^] # Re: Desole...

                Posté par  . Évalué à 5.

                « les 68030 et 68040 étaient accompagnés des mmu 68881 et 68882 »

                Le 68881 et 68882 ne sont pas des MMU mais des coprocesseurs arithmetiques (FPU) et les 68030, 68040, etc. ont une MMU integré.

                De plus, avoir une MMU ne veut pas dire qu'elle gère les protections W^X. La pagination est une chose, et le fait de pouvoir déclarer une page comme non executable en est une autre.
    • [^] # Re: Desole...

      Posté par  (site web personnel) . Évalué à 6.

      tiens il est out le SP2 de winXP ?
    • [^] # Re: Desole...

      Posté par  . Évalué à 2.

      Le SP2 l'intègre depuis un certain moment, certes, mais comme on ne l'a pas encore en version finale...
      • [^] # Re: Desole...

        Posté par  . Évalué à 7.

        Ben oui, tout comme ce kernel qui n'est utilise par aucune distrib utilisable en production, mais si tu tiens vraiment a installer le SP2 dans sa version actuelle, tu peux, tout comme installer une Fedora Core avec ce kernel, c'est faisable, juste pas conseille.
        • [^] # Re: Desole...

          Posté par  . Évalué à 5.

          Avec execshield, il y a maintenant peu de programmes qui posent problèmes (wine). Execshield est en production depuis longtemps.
          From: Arjan van de Ven

          On Wed, Jun 02, 2004 at 02:13:13PM -0700, Linus Torvalds wrote:
          > (...)
          > Just out of interest - how many legacy apps are broken by this? I assume
          > it's a non-zero number, but wouldn't mind to be happily surprised.

          based on execshield in FC1.. about zero.


          Le noyau avec nx est dans rawhide. La mise en production sera très rapide.
          • [^] # Re: Desole...

            Posté par  . Évalué à 1.

            > La mise en production sera très rapide.

            De la mailing devel de fedora :
            De: Arjan van de Ven
            On Thu, 2004-06-03 at 17:06, Neal D. Becker wrote:
            > >From the features I'd like to see department:
            >
            > http://kerneltrap.org/node/view/3240(...)

            the plan is to include this in the upcomming FC2 kernel update....
            (think "next few weeks")


            Quelques semaines pour un update officiel FC2 avec cette "feature".
    • [^] # Re: Desole...

      Posté par  (site web personnel) . Évalué à -2.

      Vu que le sp2 n'est pas encore sortit, c'est pas windows
      • [^] # Re: Desole...

        Posté par  (site web personnel) . Évalué à -6.

        09:45 09:46 09:48 Powaaaaah \o/
      • [^] # Re: Desole...

        Posté par  . Évalué à 5.

        Tu peux downloader et installer la RC1 du SP2 ( http://www.microsoft.com/technet/prodtechnol/winxppro/sp2preview.ms(...) ) si ca te chante, tout comme tu peux installer une Fedora Core, les 2 sont du meme type : "bleeding edge", pas conseille en production mais fonctionnels
        • [^] # Re: Desole...

          Posté par  . Évalué à 0.

          la RC1 du SP2, [...] pas conseille en production mais fonctionnels
          Ah ? C'est comme toutes les autres versions de Windows alors ? ;)
          • [^] # Re: Desole...

            Posté par  . Évalué à 0.

            Meuh non! Faut pas être mauvaise langue comme ça!
            comme tout bon correctif de chez kro, il corrige un problème et pète tout ce qui est autour.
            Mais ils ont l'excuse toute trouvé: ils sortent tout en béta test

            "Bah! on vous avait dit que c'était du béta!"

            (un peu comme winXP lorsqu'il aura quitté son stade actuel: alpha)
        • [^] # Re: Desole...

          Posté par  . Évalué à 1.

          erreur, c'est pas considéré comme "bleeding edge" sous linux, et tout le monde peut l'installer en patchant son kernel
          alors que sous windows, il faut installer une sp2 en version beta, la partie pour le nx étant sans doute tout aussi stable que celle de linux, mais si la sp2 est encore en béta, c'est qu'il reste des problèmes avec, pour un usage courant

          enfin c'est vraiment un guèguerre de polichinel ...
          • [^] # Re: Desole...

            Posté par  . Évalué à 1.

            et tout le monde peut l'installer en patchant son kernel

            C'est bien pour ca que je dis que c'est 'bleeding edge' , c'est pas dans le kernel par defaut, car c'est considere trop 'neuf' et pas assez teste.
    • [^] # Re: Desole...

      Posté par  . Évalué à 10.

      Ben non c'est pas le premier, le SP2 de XP contient ca depuis un petit moment deja

      Sauf qsue la c'est de l'emulation au niveau OS vu que les CPUs x86 sont incapables de faire du NX en natif.
      A noter qu'avant XP SP2 windows 2003 serveur possedait déjà cette option mais qu'il fallait l'activer a la compilation. 2003 est d'ailleurs compilé avec le full NX a savoir interdiction d'execution depuis la pile et protection de segments mémoire en non excutable (NX = Not eXecutable). Il est egalement possible de compiler en NX application par application depuis VS .net (options a passer aux compilos) le programme rejettera alors toute demande de jumper un segment de la pile.

      Les *BSD font cela en natif depuis des années (ie si le processeur le supporte) vu que la fonction était implementé dans 4.4 BSD. Un support pour une emulation sur processeur x86 a été ajouté dans OpenBSD 3.4 l'année dernière.

      Encore avant cela Windows NT4 alpha faisait déja du NX full, mais pour des raisons de compatibilité il n'était pas forcé par l'OS et était très peu utilisé.
      Ceci étant le premier a avoir implementé une gestion NX natif forcée au niveau OS (ie toutes les applis protégées par défaut) doit être VMS ou l'OS alpha de digital (TRU64 je crois) aux alentours de 1980...

      Kha
      • [^] # Re: Desole...

        Posté par  . Évalué à 10.

        WS03 n'a pas cette feature NX, il n'y a aucune protection pour les segments de donnees. La protection offerte par VS.Net est plus une magouille destinee a limiter la casse en cas de stack overflow qu'autre chose, sans support CPU c'est impossible d'avoir un truc vraiment efficace et qui ne bouffe pas les perfs.

        Sinon, il me semble que le patch de Molnar ne contient pas d'emulation sur les cpu Intel, il ne fait qu'etendre la pagetable pour supporter le bit NX des CPU qui ont la feature selon l'e-mail sur la ML.
        Si tu lis la page pour patcher, il precise bien qu'il faut avoir un CPU avec la feature d'ailleurs.
        • [^] # Re: Desole...

          Posté par  . Évalué à 6.

          WS03 n'a pas cette feature NX, il n'y a aucune protection pour les segments de donnees

          Ha bon ? Mince je m'etais laissé emberlificoter par l'article dans MISC alors. Il me semblait que WS2003 refusait de jumper la pile. Il va falloir que je me plonge sérieusement la dedans pour voir.
          Même chose pour VS.net...

          sans support CPU c'est impossible d'avoir un truc vraiment efficace et qui ne bouffe pas les perfs.

          La on est d'accord. A mois de virtualiser tous les accès mémoire, sous x86 point de salut.

          Sinon, il me semble que le patch de Molnar ne contient pas d'emulation sur les cpu Intel, il ne fait qu'etendre la pagetable pour supporter le bit NX des CPU qui ont la feature selon l'e-mail sur la ML.
          Si tu lis la page pour patcher, il precise bien qu'il faut avoir un CPU avec la feature d'ailleurs.


          Tout a fait, pour avoir un semblant de protection sous x86 il faut passer par OpenBSD et peut-être (encore que tu as l'air de dire que pas trop) par VS.net.

          Ceci étant est-ce que tu pourrais expliquer ou filer des infos ou des liens sur ce que font les fonctions de protections de segments sous VS.net ?

          Kha
          • [^] # Re: Desole...

            Posté par  . Évalué à 5.

            VS.Net n'a rien pour proteger les segments de donnees, il a une feature offrant un minimum de protection a la stack mais c'est tout.

            cf. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vc(...) pour plus d'infos
          • [^] # Re: Desole...

            Posté par  . Évalué à 4.

            > Tout a fait, pour avoir un semblant de protection sous x86 il faut passer par OpenBSD

            Linux : PaX, ExecShield, OpenWall (et d'autres)
            OpenBSD/NetBSD : R^W
            FreeBSD: rien niveau noyau sniff
            Je pense pas que Solaris x86 fournisse quelque chose

            Autrement au pire patchage gcc.

            Bien sur faire du hardware en software ca a un certain cout :-)
        • [^] # Re: Desole...

          Posté par  . Évalué à 2.

          > Si tu lis la page pour patcher, il precise bien qu'il faut avoir un CPU avec la feature d'ailleurs.

          Oui car les solutions pour x86 existent déjà dont exec shield écrit par le même ingo molnar.
          • [^] # Re: Desole...

            Posté par  . Évalué à 1.

            > exec shield écrit par le même ingo molnar.
            En production depuis redhat 9.
            • [^] # Re: Desole...

              Posté par  . Évalué à 1.

              En même temps du côté blackhat la rumeur dit qu'il y a un ou deux exploit(s) qui trainent depuis la sortie d'exec shield mais bon :-)

              "En production depuis redhat 9. "

              Vous avez quoi a prouvez avec qui était le premier ? Y'avait aussi des solutions bien qu'avant exec shield pointe le bout de son nez enfin je vois pas l'apport au débat hormis le "moi je". C'est du niveau du thread de bugtraq que j'ai posté plus bas...

              Autrement tu m'expliques comment la RH 9 est sortie fin Mars et execshield posté sur lkml debut mai (2003) ? Tu m'aurais dit FC1 ou REL 3 tu aurais été plus crédible à mes yeux.
              • [^] # Re: Desole...

                Posté par  . Évalué à 1.

                > la rumeur

                La rumeur...

                > Vous avez quoi a prouvez avec qui était le premier ?

                C'est quoi qui te gène ? RedHat a fait exec-shield et l'utilise en premier. Ça doit rester une information confidentielle ?

                > enfin je vois pas l'apport au débat hormis le "moi je".

                C'est pas "moi je" mais "eux ils" ici.
                exec-shield fait pratiquement la même chose que NX. Tu vois le rapport ?
                Le rapport est qu'un programme qui tourne sous exec-shield tournera avec NX.
                Des personnes se questionnent sur la mise en production de NX. Le fait qu'exec-shield soit utilisé depuis 1 an est une réponse concrête. J'ai indiqué sur quelle distribution. C'est grave ?

                > Tu m'aurais dit FC1 ou REL 3 tu aurais été plus crédible à mes yeux.

                Huuu.
                Tout juste.
      • [^] # Re: Desole...

        Posté par  . Évalué à 0.

        > Les *BSD font cela en natif depuis des années (ie si le processeur le supporte)

        Comme Linux (ie si le processeur le supporte).
    • [^] # Re: Desole...

      Posté par  . Évalué à -3.

      Ha le SP2 est sortie ?,je savais pas .
  • # Pardon ?

    Posté par  . Évalué à 10.

    "À ma connaissance Linux est le premier OS à implémenter cette technologie."

    Heu pardon c'est serieux la ?

    Bon y'a deux cas si y'a un support hardware ou non.

    S'il y a support hardware cette chose existe depuis la nuit des temps. Sur les systèmes qui utilisent la segmentation ou sur des processeurs non moisis niveau pagination ceci a toujours existé aussi loin que la mémoire virtuelle remonte.

    Pour pas remonter à la nuit des temps je sais que Solaris le supporte au moins depuis 1998. NetBSD le fait aussi sur toutes les architectures potables.
    Autrement pour faire plus mal je dirais que les anneaux Multics basés sur des segments faisaient déjà cela... y'a un peu plus de 20 ans... (rha j'étais même pas né !)

    Le problème est que quelques architectures bien merdiques on fait l'économie d'un ou deux bits par pte et qu'on est bien emmerder maintenant et qu'il faut des ruses de sioux au niveau noyau pour émuler ce que le processeur n'est pas capable de fournir. Au niveau du noyau même linux à en effet été l'un des premiers (c'est plus recent maintenant) notament avec PaX & co. Il existe un autre technique mais qui demande la recompilation des tout sur la machine les solutions noyaux ayant l'avantage d'etre transparente.

    Le seul événement la dedans, même s'il est pas récent, c'est que la famille de proco la plus répendue va enfin être potable niveau VM. L'AMD 64 étant pas mal foutu si on excepte les 8 modes de compatibilités...

    Bref les linuxiens sont en train de trop s'enfermer dans leur monde linux à mon gout :-)
  • # W^X sur OpenBSD

    Posté par  (site web personnel) . Évalué à 10.

    À ma connaissance Linux est le premier OS à implémenter cette technologie.

    Avant de dire des conneries pareilles, tu pourrais te renseigner.

    Sur OpenBSD, cette fonctionnalité s'appelle "W^X" (Write XOR Execute) et est dispo depuis la version 3.4.

    Cela est supporté aisément sur les processeurs disposant de cette fonctionnalité en "natif" et au pris de pas mal de contorsions (d'après les dev) sur i386.
  • # Reflexion, extension

    Posté par  . Évalué à 4.

    > À ma connaissance Linux est le premier OS à implémenter cette technologie (NdM : non)

    Le modérateur n'aurait pas pu simplement supprimer cette phrase plutot que de rajouter une note ?
    • [^] # Re: Reflexion, extension

      Posté par  . Évalué à 1.

      non, un modéro n'a pas a modifier une news, soit il l'accepte (et peut néanmoins rajouter un note, comme ici), soit il la refuse. Mais bon, tout ça montre bien un manque de sérieux de la part de l'auteur de la news ...
      • [^] # Re: Reflexion, extension

        Posté par  . Évalué à 5.

        Les news sont modifiés avant modération, ca serait pas la première fois ....
        J'ai plus l'impression de voir un tacle en bonne et du forme qu'une notification d'erreur sur la news.

        Le modérateur aurait pu modifié la news pour mettre ceci à la place par exemple :
        "Linux est l'un des OS à implémenter cette technologie"
      • [^] # Re: Reflexion, extension

        Posté par  . Évalué à 4.

        un modéro n'a pas a modifier une news

        C'est vrai ça ? Ça me semble un peu absurde, le but du jeu étant d'avoir des niouzes de qualité, justes et lisibles... Si ça doit passez par des modifs ou reformulations, et bien soit, qui ça dérange ?
        • [^] # Re: Reflexion, extension

          Posté par  . Évalué à 0.

          C'est vrai ça ?

          Ce n'est qu'une opinion personelle à moi que j'ai ... mais bon, un modéro modère, il n'a pas à reformuler les propos d'autrui.
      • [^] # Re: Reflexion, extension

        Posté par  . Évalué à 0.

        > Mais bon, tout ça montre bien un manque de sérieux de la part de l'auteur de la news ...

        Et aussi des modérateurs qui sont là pour vérifier les news. Sinon ils ne sont plus utiles.
  • # Et la protection au niveau des segments alors ?

    Posté par  . Évalué à 6.

    Je ne sais pas si c'est inenvisageable d'utiliser ca à cause de la structure des differents OS, mais ca fait TRES TRES TRES longtemps (depuis le i386 et même le 80286 en 16 bits) que les x86 possèdent une distinction segment de code / segment de donnees largement suffisante pour emepecher l'execution de code dans la pile ou le tas. Il aurait peut etre été plus malin d'utiliser ca dès le début plutôt que d'attendre que les fondeurs daignent rajouter un truc redondant au niveau des pages, en faisant par ailleurs le pire gruik illogique en attendant (supperposition on ne peut plus dangereuse (puisque qu'elle rend possible les exploitations des BOF) d'un segment de donnée pour rendre possible l'ecriture, et de code pour rendre possible l'execution).

    Bref tout ca pour dire qu'avant de tripper sur des nouveautés loin d'être nouvelles, d'ailleurs, il faudrait ptet prendre le temps de matter l'existant et d'eviter de faire des choses absurdes au niveau design des OS (oui, la supperposition segment de code et segment de donnée est une chose ABSURDE, voir GRAVE si on prend en compte tous les exploit rendus possibles), et de venir se plaindre par apres du processeur sans même s'appercevoir de l'absurdite de sa plainte.

    C'etait le coup de gueule du jour d'un psycopathe qui a les trois manuels d'Intel comme livre de chevet.
    • [^] # Re: Et la protection au niveau des segments alors ?

      Posté par  . Évalué à 9.

      J'ai peur que ca ne change pas grand chose...

      En dehors de la vision d'horreur que constituerait un retour à la mémoire segmentée, et tres certainement les complications au niveau de l'OS, et de toutes les applications (puisque sous Unix on a une vision lineaire de la RAM) (va-t-il falloir utiliser "far pointer" en plus de "pointer" ? :) ), l'impossibilité d'executer du code dans la pile ou le tas est toute relative.

      Voila comment j'imagine les choses:

      Si je ne m'abuse, pour exploiter un BufferOverflow, il fallait pouvoir:

      1) placer du code quelque part (pile ou tas)
      2) réécrire dans la pile le mot de 32 bits qui contient l'adresse de retour de la fonction, pour qu'elle pointe sur la zone 1)

      La fin de toute fonction est normalement l'instruction RET qui dépile l'addresse EIP de retour et saute à cette adresse (dans le segment de code CS). Effectivement, separer CS de DS ou SS (les segment de donnée ou de pile) empeche de faire cela directement. Mais il existe une autre instruction, RETF (RET Far) qui dépile EIP et CS, et permet donc d'outrepasser la séparation de segments en changeant la valeur de CS.

      Cette instruction, comme RET, est codée sur 1 octet (0xCB). Une analyse du binaire attaqué permet surement de trouver un octet de cette valeur quelque part dans le code, dont on puisse injecter l'adresse. À partir de là, la sequence d'attaque deviendrait:

      1) placer du code quelquepart dans la pile ou le tas
      2) réécrire dans la pile l'adresse de retour de fonction, pour qu'elle pointe vers un octet dans le segment de code, codant pour RETF
      3) réécrire le double mot précédent de la pile, pour qu'il contienne le segment+adresse de la zone 1.

      Le RET standard de la fonction va dépiler 2, et executer le RETF a l'adresse indiquée. Ce RETF va lui-meme dépiler la valeur dans 3, et faire un saut long vers la zone 1, en ayant modifié le segment de code CS.

      C'est bien sur plus difficile comme attaque, mais je pense que ca reste possible.
      • [^] # Re: Et la protection au niveau des segments alors ?

        Posté par  . Évalué à 3.

        Oui mais non, tu n'as pas le droit de creer un nouveau segment en mode protege, c'est une tache reservée au noyeau. Quand a mettre le segment de données dans CS, ce n'est pas très malin car le segment de données n'est pas executable.

        Quand au retour en segmenté qui ferait faire des cauchemards, je ne vois vraiment pas ou est le problème : on est deja en mode segmenté : il y a un segment de code dans CS et un de données en DS, le truc c'est qu'ils ce recouvrent, et que le recouvrement rend donc inoperant une protection naturelle des x86. Moi je parlais de rassembler tout le code dans un coin de l'expace lineaire, toutes les données dans un autres, et que le segment de code n'inclue pas les données et reciproquement. Comme le segment de code est dans CS et est utilisé automatiquement par les jump, call, etc, ta pas besoin de préciser le segment. De meme pour les données : le segment de données est dans DS, et est utilisé automatiquement dans toutes les operations d'acces au données. Vu le modèle mémoire du C, il ne faudrait mieux pas separer le segment de données du segment de pile par contre (par contre en java on pourrait...), mais bon c'est pas essentiel de faire ca.

        Bien evidemment faire ca aujourd'hui, meme si je pense que c'est possible, serait assez lourd : modification surrement toute la chaine de compilation et de chargement dynamique, du noyeau, puis recompilation. C'est pour ca que je disais que ca aurait du etre fait des le début. Reste que desactiver quasi volontairement une protection pour refaire la meme 10 ans apres a un autre niveau en plus compliqué, qui tourne sur peu de procs de la famille majoritaire x86 (alors que linus a developpé initialement sur x86), n'est pas tres (voir du tout) malin.

        PS: evitez de me moinsser pendant 1 semaine, je viens de me recreer un compte et il m'est impossible de poster si j'ai trop peu de karma, encore un systeme de controle débile de merde, vu que j'ai voulu ecrire ca hier soir et que j'ai pas pu et que j'ai faillis refermer mon compte immédiatement sous la colere.
        • [^] # Re: Et la protection au niveau des segments alors ?

          Posté par  . Évalué à 2.

          Update: le noyeau autorise a creer ses propres descripteur de segment dans la LDT et il faut donc desactiver cette possibilité (j'ai vu ca dans le post du dessous qui parle d'ailleur d'un patch qui fait precisement ce que je decris... et qui aparrement pose moins de problème que je l'imaginais)
        • [^] # Re: Et la protection au niveau des segments alors ?

          Posté par  . Évalué à 2.

          > Moi je parlais de rassembler tout le code dans un coin de l'expace lineaire, toutes les données dans un autres, et que le segment de code n'inclue pas les données et reciproquement.

          Problème des bibliothèques partagées mais en gros c'est ce que semble faire W^X. Ils ont changé la ld pour que l'on puisse regrouper dans un coin les données et de l'autre le code.

          http://groups.google.com/groups?q=g:thl3632333067d&dq=&hl=e(...)

          Ca fait en effet pas mal de changements (plus aucun binaire compilé avant ne fonctionne) ce n'est donc plus facilement faisable surtout pour du desktop ou on commence a voir plein de trucs precompilés partout.

          Le jeux est de savoir si *maintenant* c'est la peine de tout casser pour une architecture qui va pas tarder à partir à la poubelle. Tout comme est ce la peine de s'ennerver à supporter les big iron en x86 alors que des archis 64 bits plus adaptées sont maintenant abordables...

          [À propos du malin]
          Je pense surtout que le problème c'est qu'UNIX à toujours préféré la pagination et que malheureusement c'est le mauvais proco qui a gagné des parts de marché :-)
    • [^] # Re: Et la protection au niveau des segments alors ?

      Posté par  . Évalué à 5.

      En recherchant un trhead que je n'ai pas retrouver je suis tomber sur ca :
      http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&thre(...)

      Excellent thread sur bugtraq avec du Jedi/Sector one, du Theo de Raadt, du pageexec, du Solar Designer, du sauron, du Stealth qui parle comme des hommes qui mettent leur teub sur la table pour savoir qui a la plus grosse^W^W^Wfait un NX sur i386 en premier.

      C'est rigolo à lire :-)

      Bon autrement pour ce que tu proposes bien qu'etant pas specialiste de la chose il y a plusieur problème. Le problème est que les UNIX ont l'habitude de bosser avec un espace virtuel plat et a coup de pagination ca simplifie beaucoup les choses (cf les vieux threads sur lkml), la segmentation a totalement disparue de linux depuis le 2.2 il me semble et encore c'etait utilisé pour separer le mode noyau du mode utilisateur donc pas grand chose avoir avec le schmilbick.

      ll y a des patchs qui se basent en effet sur la segmentation notament une des approches de PaX (http://66.102.9.104/search?q=cache:HYWR5K5BAXkJ:pax.grsecurity.net/(...) désole pour le google cache mais comme grsecurity est down ca aide pas pour avoir l'original) le principal problème c'est que tu coupes ton espace d'addressage en 2 à l'avance c'est pas top pour les machines "big iron".

      Mes connaissances sont très limitées de ce coté mais commencer à faire mumuse avec plein de petits segments ca me semble pas etre la joie quand on est limité en nombre.
      • [^] # Re: Et la protection au niveau des segments alors ?

        Posté par  . Évalué à 1.

        Je parle pas de pleins de petits segments, je parle d'exactement le meme nombre qu'aujourdhui : un pour le code un pour les données.
        J'imagine bien que ca pose quelques pb, sinon ca devrait etre fait aujourd'hui... Mais la question est : est-ce que ca pose plus de problème que ca n'en resoud ? Parce que le nombre d'exploit par buffer overflow est tout de meme impressionnant et aurait ete _tres_ reduit avec un tel systeme (je n'ose pas dire nul, j'ai peut etre oublie quelquechose...)
        • [^] # Re: Et la protection au niveau des segments alors ?

          Posté par  . Évalué à 2.

          > J'imagine bien que ca pose quelques pb, sinon ca devrait etre fait aujourd'hui...

          C'est déjà fait aujourd'hui, je pense que tu as vu au moins les deux implémentations que je t'ai montré. Il y a deux problèmes principaux cependant (en dehors des autres niveau sécurité).

          SEGMEXEC casse l'espace d'addressage en 2 par defaut, si tu es en 3:1 il te reste 2 x 1.5 Go , si tu es en 2:2 il te reste 2 x 1 Go ca pose donc problème sur les machines blindées de RAM. La solution encore et toujours allez acheter un AMD64 ou n'importe quoi du style...

          W^X explose tout les binaires existant, si c'est juste pour supporter le x86 je dirais que le jeux n'en vaut pas la chandelle étant donné que tout les concepteurs de proco ont l'air d'avoir compris le problème et avancent le fait que ca sera resolu dans les prochaines evolutions.

          Si tu veux une comparaisons objective entre les deux ca va etre difficile etant donné la rivalité entre OpenBSD et PaX/Grsecurity et qu'ils ne savent que s'insulter. Tu as une comparaison là http://grsecurity.org/papers.php(...) par spender et sur misc@openbsd et bugtraq y'a quelques thread bien saignants.
          • [^] # PaX pour les x86 sans NX, NX pour les autres...

            Posté par  . Évalué à 1.

            PaX n'a donc pas l'air de poser trop de problème si ce n'est la limitation coté espace d'adressage, mais bon on se rapproche de toute facon des limites inhérentes au 32 bits, et à ce niveau là c'est clair qu'il vaut mieux passer au 64 bits que blinder son 32 bits avec 4 Go de RAM, avec du NX qui la ne pose plus aucun problème de retro compatibilite ou autre.
            Pour les pocesseurs de "vielles" machines sans NX, PaX ca à l'air bien, mangez en, on est jamais trop prudent coté sécurité !
            Je vais d'ailleurs tester ce week end tellement j'aime utiliser intelligement mon materiel et ses protections naturelles :p

            Bref tout ce thread pour dire que NX c'est bien beau, mais on savait deja faire avant à peu près pareil, et on pouvait deja techniquement depuis plus de 10 ans... (et me dites pas que j'aurais du m'y mettre et implementer ca moi même, j'etais trop petit ! :)

            Quand à implementer quelque chose qui me semble naturel dès le début, à savoir une séparation code / donnée concrétisé par la segmentation correspondante et une chaine de compilation / chargement qui met tout là ou il faut, sans possibilité de passer outre, ce n'est bien evidemment plus possible puisqu'on est plus au début... Mais si quelqu'un dans l'assistance à envi de coder un OS je lui conseille vivement de le faire : à mon gout la sécurité est une priorité des plus grandes, et je ne pense pas que la sacrifier pour de petites simplifications soit une très bonne idée. D'autant que c'est ce mettre dans une situation ou il faudra peut être dans le futur faire des choses bien plus complexes pour corriger le tir !
  • # 2 drapeaux sinon rien...

    Posté par  . Évalué à 7.

    En effet les processeurs disposant de la technologie NX ajoutent deux drapeaux aux pages mémoires allouées, à savoir le drapeau 'execute' et le drapeau 'no execute' ; ce dernier interdit l'exécution de la zone mémoire allouée.

    C'est curieux mais j'aurai plutôt pensé que l'économie imposerait un drapeau booléen execute/no execute.
    Serait-ce une erreur de formulation de la dépêche, une bêtise d'ingénieur, une réalité électronique que j'ignore, un chipotage de ma part ou ces 4 états (drapeaux levés et baissés) laissent-ils présager d'autres possibilités ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.