Re: ASLR pour le noyau 2.6

• [^]Re: ASLR pour le noyau 2.6

  Posté par pasPierre pasTramo () le 30/10/2003 à 02:49. (lien). Évalué à 2.

  La question que je me suis toujours posé a propose de SELINUX c'est: quel confiance peut accorder a un os maintenu par une institution (la NSA) dont le but est d'espionner la terre entiére?

  • [^]Re: ASLR pour le noyau 2.6

    Posté par Julien () le 30/10/2003 à 13:31. (lien). Évalué à 2.

    Je pense qu'ils sont au courrant de ces craintes, car ils ont publié non seulement le code source, mais aussi tout le design rationale de FLASK et de leur système de type enforcement.
    De ce fait, leur produit me semble parfaitement auditable, tout comme le sont par exemple les systèmes de crypto du monde entier proposés pour AES.

Re: ASLR pour le noyau 2.6

• [^]Re: ASLR pour le noyau 2.6

  Posté par Bernard Hugueney () le 29/10/2003 à 09:32. (lien). Évalué à 4.

  Ca peut demander de les relancer sans cesse jusqu'à tomber dans le mille, mais ça n'est en aucun cas une solution miracle.
  
  Peut-être que tout est dans le "sans cesse" ?
  Si la solution marche das tous les cas sauf un "miracle", c'est pas loin d'une solution miracle, non ?

• [^]Re: ASLR pour le noyau 2.6

  Posté par Vanhu () le 29/10/2003 à 09:58. (lien). Évalué à 5.

  En fait, les développeurs disent eux meme (et c'est très bien détaillé sur le site d'Adamantix) que la seule bonne méthode pour se protéger des buffers overflow et autres, c'est de programmer proprement et sans failles.
  
  Maintenant, dans le grand état d'esprit "ceinture ET bretelles", ce genre de méchanisme rend nettement plus difficile l'exploitation d'éventuels failles existantes, ce qui est déjà intéressant en soi !

• [^]Re: ASLR pour le noyau 2.6

  Posté par Julien () le 29/10/2003 à 11:28. (lien). Évalué à 1.

  La randomization peut atteindre 24 bits (par exemple sur la pile) et est souvent de 16 (RANDMMAP).
  
  Cependant, tu as raison, cette solution doit être déployée avec un mécanisme tel que SEGVGARD afin de détecter d'éventuelles attaques "brute force".

  • [^]Re: ASLR pour le noyau 2.6

    Posté par pappy (page perso, ) le 29/10/2003 à 16:23. (lien). Évalué à 4.

    juste pour rappel : la randomisation ne sert presque à rien pour les bugs qui permettent de dévoiler l'espace d'adressage des processus (typiquement les format bugs) ... vu que dans ce cas le processus devient un joli debogueur et qu'on peut lire tout ce qu'on veut où o veut avant d'aller écrire au(x) bon(s) endroit(s).
    
    Mais comme le dit Vahnu (faut que je revienne à Lille moi ;-) : dans certains cas, les bretelles et la ceinture, c'est pas mal ;-]

    • [^]Re: ASLR pour le noyau 2.6

      Posté par Vanhu () le 29/10/2003 à 16:49. (lien). Évalué à 2.

      (faut que je revienne à Lille moi ;-)
      
      Pour encore raler qu'il fait froid par chez nous ???? :-)
      
      Mais fallait venir cet été !!!!!!!
      
      A +
      
      VANHU.

    • [^]Re: ASLR pour le noyau 2.6

      Posté par Julien () le 29/10/2003 à 17:21. (lien). Évalué à 1.

      Il est tout à fait juste que l'information leaking rend l'ASLR caduque (j'ai d'ailleurs mentionné ce problème dans ma réponse au post de free2 ci dessous), l'information leaking peut même être réalisé facilement sans aucun bug du programme lui même si l'attaquant a un compte local via /proc/pid/maps ou stats (d'ou le PaX obscurity patch qui sera inclu dans aslr26 cette semaine).
      
      Cependant je pense qu'il est un peu exagéré de dire qu'elle ne sert presque à rien dans le cas des format strings. En effet il est clairement possible de dumper la pile dans le cadre de format strings, mais il n'est pas toujours possible d'obtenir par ce moyen toutes les adresses que l'on veut. On peut toutefois généralement assez facilement dumper la pile assez loin pour obtenir l'adresse de retour dans __libc_start_main et en déduire ainsi la position de la libc, mais il ne sera par contre pas toujours facile d'obtenir l'adresse absolue d'une adresse de retour ou d'un pointeur de fonction à modifier à l'aide de la format string. On peut également tenter d'afficher "au hasard" des adresses et voir ce qu'on n'y trouve, mais ce n'est pas toujours facile, et si on plante le processus, tout est à refaire (l'espace d'adressage sera différent au relancement).
      De plus, si on doit fonctionner en deux temps (afficher l'adress space, puis l'exploiter), cela réduit les cibles potentielles, en effet, seul les démons réalisant un fork() pourront être des cibles, car les autres programmes, une fois relancés auront leur espace d'adressage à nouveau randomizé.
      
      La principale limitation de cette protection est à mon avis que la majorité des utilisateurs ne relinkera pas forcément ses exécutables sensibles en ET_DYN, rendant ainsi la protection beaucoup moins effective et vulnérabe à un return-to-PLT suivi d'un dl-resolve() par exemple.
      
      Il est de toute façon clair qu'il s'agit là d'un patch simple qui ne peut que "améliorer les choses" en attendant que le reste de PaX soit porté. (Je m'attelerai peut être à PAGEEXEC -sur les archis suporant le bit d'exécution- et MPROTECT dans une semaine ou deux, SEGMEXEC sur noyau 2.6 ne verra certainement pas le jour avant plusieurs mois)

autre patch sans controle d'accès pour le noyau 2.6

• [^]Re: autre patch sans controle d'accès pour le noyau 2.6

  Posté par Julien () le 29/10/2003 à 11:39. (lien). Évalué à 5.

  Exec-shield est cependant moins puissant que PaX:
  
  Il ne peut réaliser qu'une version "opportuniste" des pages non exécutables sur architecture i386. Si une zone exécutable doit être située dans l'espace d'adressage linéaire apres une zone non exécutable, alors cette zone non exécutable sera exécutable.
  Pour réduire les défauts de cette implémentation, exec-shield essaie de mapper les zones exécutables le plus bas possible en mémoire, (et même dans l'ascii armor a fin d'éviter des return to libc). Cependant, cela n'est pas toujours possible, par exemple dans le cas d'exécutable ET_EXEC (cas de tous les ELFs dans toutes les distributions sauf Adamantix et Trusted Gentoo).
  L'autre problème est que l'ascii armor ne stopera pas forcément les return to libc, en effet, à cause du manque d'information de relocation, exec-shield ne peut pas remapper le GOT/PLT d'un fichier ET_EXEC, ces parties ne seront donc pas dans l'armure ascii, il existe des techniques permettant d'attendre l'armure ascii depuis le GOT/PLT à l'aide d'enchainement de return-to-libc (cf. article de Nergal dans phrack).
  
  Comparons ce qui est comparable, PaX n'est pas disponible sur noyau 2.6, seule une partie (l'address space layout randomization l'est). Même dans ce cas, l'ASLR constitue un modèle viable et "autonome" si utilisé avec des exécutables ET_DYN (il est très facile de relinker des exécutables vers ET_DYN) et une solution comme SEGVGUARD alors que exec-shield est toujours assez facilement contournable. Cependant l'ASLR a le defaut de l'information leaking que n'a pas exec-shield: il peut exiter des bugs qui semblent bénins et qui permettent de récupérer les adresses des structures du programme.
  
  Pour résumer: si vous avez un système ET_DYN, ASLR26 sera certainement mieux que exec-shield26, dans les autres cas, les deux permetteront d'empcher certains exploits publiques de marcher. Si vous avez un noyau 2.4, PaX est par contre clairement la meilleure solution.

  • [^]Re: autre patch sans controle d'accès pour le noyau 2.6

    Posté par gary () le 29/10/2003 à 22:16. (lien). Évalué à 3.

    Bonjour,
    Il faut certes noter les limites du patch exec-shield mais il était de très bon ton d'en rappeler l'existence pour le noyau 2.6 me semble t il...
    D'autant que je trouve Julien un peu injuste avec cette solution. Il est certes avéré que PaX, dans sa forme complète, c'est à dire celle qui n'est disponible que pour le noyau 2.4 (ou 2.2, il me semble qu'il a été "backporté" pour i386) fournit une protection plus complète que Exec shield.
    Cependant ne sombrons pas dans une approche trop partiale : exec shield est un patch très léger qui rend de facto des services louables au prix d'un overhead infime.
    Il empêche bien entendu toute exécution de la pile et même s'il peut être pris à défaut pour les raisons déjà fort bien évoquées par Julien lorsque l'attaquant met en oeuvre des techniques de "return in lib(c)" plus ou moins évoluées, il n'en reste pas moins d'un déploiement simple, avec une possibilité de commander son niveau d'activation au boot ou encore dynamiquement via /proc/sys/kernel/exec-shield... Même sans prendre de mesures particulières (pas de nouvelle édition de lien etc...), il fournit donc un premier niveau de protection louable d'autant que la grande majorité des attaques sont menées par des script kiddies qui seront arrétés par une telle protection aussi imparfaite soit elle ... (Attention je ne veux pas dire qu'il faut pour autant considérer que l'on est à l'abri... Je remarque simplement que exec shield pourra déjouer les premières attaques triviales suite à la divulgation d'une vulnérabilité...)
    Enfin, Pourquoi serait il "très facile de relinker des exécutables vers ET_DYN" lorsque l'on évoque PaX mais que le flag ET_EXEC empêchant la "relocation" de l'executable dans l'ASCII ARMOR pour exec shield est présenté comme une faiblesse insurmontable ? Pourquoi citer l'excellent article de nergal dans phrack (numero 58, article 4) pour dénigrer seulement exec-shield alors que le titre de l'article est tout de même : "The advanced return-into-lib(c) exploits: PaX case study " et que cet article expose comment mettre à défaut PaX (même s'il est indiscutable que les techniques sont utilisables pour exec-shield ...) ?
    Voila, je ne cherche définitivement pas à troller ni à sombrer dans de stériles débats sur les meilleurs patchs de sécurité... De toutes facons, la meilleure protection comme le notait vanhu, c'est de programmer proprement. Je souhaitais simplement jouer quelques instants l'avocat d'exec-shied qui est lui aussi, comme la partie ASLR de PaX, "un patch simple qui ne peut que améliorer les choses" ...

    • [^]Re: autre patch sans controle d'accès pour le noyau 2.6

      Posté par Julien () le 30/10/2003 à 13:27. (lien). Évalué à 1.

      Il était très bon de parler de l'existance d'exec-shield pour le noyau 2.6, en fait je n'étais pas au courrant.
      Tu ne sombres pas du tout dans le troll et tu as raison: en ce qui concerne le noyau 2.6 uniquement, exec-shield n'est pas surpassé par ASLR26 comme c'est le cas pour le noyau 2.4 entre exec-shield et PaX, qui lui offre beaucoup plus qu'exec-shield et beaucoup mieux fait (notamment garantie de l'impossibilité d'introduction d'un nouveau code exécutable dans l'espace d'adressage du processus, ce qui inclue une protection contre un mprotect() -sauf par mmap PROT_EXEC d'un fichier exécutable appartenant à l'attaquant, ce qui doit être restreint par un AC-)
      
      En ce qui concerne un système ET_DYN, Redhat a poussé l'effort jusqu'à inclure dans la nouvelle version de ld un switch -pie permettant de générer de l'ET_DYN exécutable, effort fort louable mais qui n'a malheureusement pas été suivi ensuite par la distribution. Mais même dans le cas d'ET_DYN le patch ne pourra pas rendre non exécutable toutes les données à cause des limitations que j'ai déjà citées, et il n'est également pas vraiment prévu pour traiter séparément les exécutables ET_DYN: par chance, ceux-ci finiront quand même dans l'armure ASCII car les linkers mettent toujours leur base adresse à 0, cependant cela risque de poser des problèmes de "place", notamment a cause de la section .bss.
      
      Quant à l'article de Nergal, il étudie en fait la faiblesse de tous les systèmes relogeant le code exécutable dans le cas des ET_EXEC, en expliquant qu'il n'est pas possible de reloger le GOT/PLT d'un ET_EXEC et que cela peut ête utilisé pour retourner où l'on veut (y compris localiser des fonctions dont l'adresse a été rendue aléatoire). Il s'applique donc tant à PaX qu'à exec-shield. La différence pour PaX est qu'il dispose déjà de plusieurs distributions entièrement ET_DYN qui lui sont dédiées, alors que Redhat semble avoir fait beaucoup de pub pour exec-shield dans leur distribution serveur mais n'a pas adapté sa distribution à son produit., espérons que cela changera!
      
      Exec-shield est toutefois un "bon petit patch", il offre une meilleure protection de l'espace d'adressage qu'OpenWall qui est pourtant très utilisé car il a été prouvé qu'il repoussait beaucoup de script kiddies, il sera donc lui aussi efficace sur ce tableau.

      • [^]Re: autre patch sans controle d'accès pour le noyau 2.6

        Posté par gary () le 30/10/2003 à 20:48. (lien). Évalué à 1.

        Voici donc les torts réparés ! ;))
        Plus sérieusement, exec shield méritait tout de même une image un peu plus reluisante. D'autant qu'ingo Molnar ne cache absolument pas les limites de son patch. Par contre, contrairement à toi julien, je trouve ce patch très bien fait : le ratio (protection apportée) / (volume de code et overhead) me semble très bon... Mais oui, je le redis, dans le cas très improbable où cela aurait échappé aux lecteurs, PaX, dans sa forme complète, protège beaucoup mieux.. (Aborder l'aspect qualitatif de comment cela est réalisé est totalement distinct n'est ce pas ? )
        Tu as raison de remarquer que la politique de Redhat ne permet pas encore de tirer le meilleur d'exec shield mais il ne faut pas non plus forcement associer exec shield à une distrib redhat : Le patch s'applique à un kernel vanilla sans aucun pb...
        Enfin, pour l'article de Nergal, j'en avais bien compris la teneur et avais bien souligné que les techniques s'appliquaient aux deux patchs... Je reprochais simplement de le présenter seulement à charge d'exec shield alors qu'il s'agit de faiblesses communes...
        J'espère tout au moins que ces discussions auront donné envie à quelques lecteurs d'appliquer l'un de ces patchs... ;-)