Risque réel?

• [^]Re: Risque réel?

  Posté par herodiade () le 13/05/2006 à 14:28. (lien). Évalué à 7.

  En fait, cela permet de contourner toutes les protections noyaux contre les possibles abus de root (l en existe plein: par exemple les securelevels, SELinux, GRsecurity, les protection contre les rootkits, ou par exemple un processus root peut alors sortir d'une cage chroot() ...).
  
  De plus, Duflot fait remarquer que cette faille permet d'écrire dans des zones non volatiles sur certains matériels (comprendre: de véroler la machine, au sens matériel, de façon résistante aux reboots et réisntallations d'OS).
  
  Aussi convient-il de noter qu'x.org s'éxecute en très grande partie avec les droits root (surtout sur les autres plateformes qu'OpenBSD).

  [^]Re: Risque réel?

  Posté par x0ra () le 13/05/2006 à 14:30. (lien). Évalué à 3.

  Et il s'agit bien d'une escalade de privilège mais pas dans le sens ou roger (simple user ayant à peine accès à vi) devient pierre (super user pouvant utiliser emacs, troll inside :p) mais ou root user mode peut exécuter du code kernel (encore faut-il en faire qqch...).

  
  ça peut servir à plein de chose de passer du securelevel 2 au -1, par exemple, charger un module pour cacher ton rootkit, modifier la conf du firewall, monter/démonter des partitions, et de permettre tout ce qui est interdit ou limité par la valeur du securelevel ..

  • [^]Re: Risque réel?

    Posté par tene (page perso, ) le 13/05/2006 à 23:17. (lien). Évalué à 3.

    oui mais non, cela sous-entend une faille dans x.org permettant d'injecter du code... et ce code tourne avec des droits root, donc on est dans la m... peu importe que X permette ou non après d'exécuter en ring 0. L'auteur pars du postulat qu'il y'a des failles! (cela pourrait être vulgarisé en: ne pas laisser trainer d'allumette chez vous, si un pyromane rentre, il pourrait bruler la maison...)
    
    side note: L'une des premières assomptions d'une analyse sécuritaire est que l'admin n'est PAS hostil, si c'est le cas, en général c'est inutile de chercher plus loin (mauvais admin, changer d'admin).
    
    Je ne suis pas en train de dire que c'est idiot/faux/stupide, au contraire, je trouve cela plutôt intéressant, mais ptêt le risque n'est pas aussi important que l'article semble le présenter...
    
    Pour ma part, j'ai tendance à croire qu'il faut choisir: un système au design pur, évitant tout risque, quitte à devoir faire des compromis par rapport au feature et à la rapiditié (qui à dit Hurd? :p) ou accepter certain compromis qui pourrait mener à des risques de sécurité. Je sais que je vais faire bondir certains puristes de la sécurité, et je les comprends, on ne devrait pas avoir à choisir, mais pourtant c'est la réalité, surtout quand on est relativement en concurence avec des OS qui ont fait des choix du genre (je pense à windows: le fait d'avoir une appli graphique fonctionnant avec des droits root sur une machine, peut permettre d'obtenir un shell root, it's "by design").
    
    Ptêt aussi que c'est parce que je pense que X n'a rien à foutre sur un serveur et que s'il est installé sur un desktop, je préfère qu'il soit rapide, joli, efficace, ergonomique que théoriquement secure... (je dis théoriquement parce que pratiquement il ne le sera pas, et le risque à mon sens est avant tout de perdre mes documents, pas de compromettre mon hardware...). Je peux donc comprendre que les développement aille vers du "eye candi" plus que du "parfaitement secure" (qui a dit Xgl?)

    • [^]Re: Risque réel?

      Posté par patrick_g (page perso, ) le 14/05/2006 à 06:32. (lien). Évalué à 7.

      >> ce code tourne avec des droits root, donc on est dans la m... peu importe que X permette ou non après d'exécuter en ring 0
      
      Le but des projets de type SELinux c'est justement de limiter la toute puissance de root. Ils veulent gérer les droits de façon plus fine et plus efficace en évitant le modèle du root tout puissant. Hors ce "problème" évoqué par Loïc Duflot casse complètement le modèle de sécurité de SELinux !
      Idem pour Xen : c'est une sorte de virtualisateur utilisé notamment pour la consolidation des serveurs. On a une seule machine et dessus on fait tourner plusieurs instances de Linux qui sont virtualisés à l'aide de Xen. Dans chacun de ces Linux on peut avoir un root différent et celui-ci, en dépit de son statut de root, ne peut pas aller foutre le bordel dans les autres instance de Linux du fait de la virtualisation.
      La encore la faille détecté explose ce modèle de sécurité et permet à un des root de pénétrer au sein même du hardware (donc en dessous de la couche Xen).
      
      En résumé c'est quand même un grosse faille et ce sera très difficile de s'en sortir sans passer par un refactoring de Xorg...Donc cela va être long et pénible...donc en attendant il faut éviter d'installer Xorg sur des serveurs x86.
      Peut être est-ce l'occasion d'aller voir d'autres architecture CPU ?

      • [^]Re: Risque réel?

        Posté par Nicolas Bernard (page perso, ) le 14/05/2006 à 08:22. (lien). Évalué à 10.

        
        en attendant il faut éviter d'installer Xorg sur des serveurs x86.
        

        
        
        Hum... sur la plupart des systèmes, si X n'est pas installé, un attaquant qui devient root peut quand même utiliser cet accès au matériel pour contourner la protection de l'OS. Pour éviter cela, il faudrait en plus qu'il y ait un sysctl comme c'est le cas dans OpenBSD, de manière à ce que l'accès au hardware soit bloqué si on utilise pas X.

        [+] [^]Re: Risque réel?

        Posté par gc (page perso, ) le 15/05/2006 à 11:20. (lien). Évalué à -1.

        Donc ca impacte uniquement les utilisateurs de SELinux et compagnie. C'est a dire finalement pas grand monde meme du coté des serveurs.

        • [^]Re: Risque réel?

          Posté par Didier Raboud (Jabber id, page perso, ) le 15/05/2006 à 15:24. (lien). Évalué à 3.

          Si j'ai bien compris, c'est pas que ça impacte uniquement SELinux, c'est plutôt que ça impacte même SELinux, qui est censé tout dé-rooter, non ?

          • [^]Re: Risque réel?

            Posté par Matthieu Moy (page perso, ) le 15/05/2006 à 17:19. (lien). Évalué à 2.

            La faille n'est exploitable que si tu es déjà root. Et si tu es root sur une machine sans SELinux/chroot/équivalent, tu as déjà les pleins pouvoirs, alors un faille qui te permet d'augmenter tes privilèges, tu t'en fous un peu ...

            • [^]Re: Risque réel?

              Posté par Nicolas Bernard (page perso, ) le 16/05/2006 à 07:16. (lien). Évalué à 2.

              Pas sûr: sur OpenBSD le serveur X tourne en tant que "_x11", donc quelqu'un qui le compromet pourrait peut-être utiliser cette méthode pour devenir root.
              
              Sinon, même sur les autres systèmes, root ne peut en théorie pas tout faire. Par exemple cela pourrait servir pour insérer un rootkit noyau de manière discrète (même s'il faut reconnaître que la plupart du temps, il y a des méthodes plus simples). Mais c'est vrai que c'est surtout pour ceux qui se fient à des méthodes de confinement que cela pose problème.

      [^]Re: Risque réel?

      Posté par herodiade () le 14/05/2006 à 12:17. (lien). Évalué à 0.

      En réalité, et contrairement à ce qu'on pourrai croire, root de devrait pas avoir *tout les droits* sur les Unix modernes. En particulier, il n'est pas censé pouvoir lire/modifier arbitrairement toutes les structures de données du noyau.
      
      Voilà quelques exemples simples qui montrent que root (ou disons, un root illégitime, autre que la personne qui a choisi les options au boot) ne devrait pas pouvoir faire, sans quoi le problème excède largement le fait d'avoir une machine compromise:
      
      - Accéder à la clef, au mot de passe de la clef ou au message déchiffré d'un utilisateur qui utilise GPG sur le système.
      
      - Idem pour les transaction SSL en cours (root ne devrait pas avoir accès à mon numéro de carte bleu lorsque je consulte le site de ma banque).
      
      - S'évader d'une cage chroot() dans lequel ce processus root est confiné (eg. daemon chrooté qui s'est fait pwned) ou autre protection de ce type (systrace, jail, ...).
      
      - Accéder au hardware, lui injecter cochonneries et le griller (ou accéder aux fonctionnalités de mise à jour du bios depuis l'OS etc).
      
      - Avoir la possibilité de modifier la visibilité de certains infos sur l'état de la machine (eg. cas d'une rootkit qui masque certains processus sur une machine compromise). Si on est pwned, pouvoir s'en apercevoir (ou pas), ça fait une grosse différence.
      
      - S'évader d'une pseudo "machine virtuelle" (penser à l'hébergement mutualisé virtuel) telle que jail sous FreeBSD ou uml sous Linux ou qemu/vmware ...
      
      etc.
      
      
      Étant donné la sophistication des Unix modernes, pour pouvoir s'assurer de ça, on a besoin de polices qui empêchent certaines actions (comme le chargement de modules noyau, sous linux). Donc ça rajoute une série de protections contre ce type de droits roots -eg.empêcher le chargement de modules du noyau si telle option a été passée au boot- (SELinux, securelevel, Capabilities etc.), qui elles mêmes ne doivent pas être modifiables/désactivables par root.

      • [^]Euh ...

        Posté par L (page perso, ) le 14/05/2006 à 12:49. (lien). Évalué à 1.

        Il y a tout de même quelque chose d'incohérent dans ce que tu écris ! Admettons que ce ne soit pas le super-utilisateur root qui ait inconditionnellement les grands pouvoirs : il faut bien qu'un compte puisse régler la politique de droit dont tu parles (éventuellement sous certaines conditions) . Donc ça ne fait que déplacer le problème qui reste le même, car la cible ne serait donc plus le super-utilisateur root, mais le nouveau compte ou système de droits.
        
        Rappelons tout de même que le problème de X.Org évoqué dans ce journal n'est pas lié directement au super-utilisateur root, mais à une architecture mal conçue qui permet d'exploiter les droits de celui-ci. Remettre en cause le super-utilisateur root dans ces conditions-là, c'est un peu comme l'histoire du couteau de cuisine : il a été conçu pour couper les aliments mais une minorité l'utilise pour commettre des meurtres, ce qui n'est pas une raison suffisante pour remettre en cause la légitimité de son existence.

        • [^]Re: Euh ...

          Posté par herodiade () le 14/05/2006 à 13:45. (lien). Évalué à 4.

          En fait l'objectif des protections comme les securelevels n'est pas de déporter les droits sur un super-super utilisateur.
          
          L'idée est plutôt de restreindre l'éxecution de certains privilèges à chaud (au runtime, ou plus précisément, lorsque le kernel tourne en mode multiutilisateur ).
          Autrement dit, on considère qu'on a confiance dans le gars qui est derrière la console physique. Celui qui, par exemple, passe les paramètres activant les sécurisations en question au noyau lors du boot.
          
          Exemple concret: l'admin boote son OpenBSD en init 1 (donc non multiuser, non réseau), active le niveau fort de restrictions (en écrivant "securelevel=2" dans le fichier /etc/rc.securelevel). Il met aussi un machdep.allowaperture=0 dans /etc/sysctl.conf vu que TdR vient de le lui recommander ;). Puis il pose le flag "immutable" sur certains fichiers cruciaux (au hasard: /etc/rc.securelevel, le kernel /bsd, /sbin/init, et le firewall /etc/pf.conf et /sbin/pfctl). Ensuite il passe le système en mode multiutilisateur. Et bien dès ce moment, root ne peut plus désactiver les protections du securelevel, ni rien modifier qui permette que ça soit désactiver au prochain reboot, etc. Sauf s'il a accès physique à la console, ou si on peut bypasser le noyau comme dans le cas qui nous intéresse.
          
          Ce n'est donc pas une "remise en cause" de root. En une phrase: le noyau/arch idéal ne devrait pas permettre à un root "distant", lorsque le système est en mode mutlisateur/en prod, de se tirer une balle dans la tête, de griller son hardware, ou de voler des données les plus confidentielles de ses utilisateurs.

          [^]Re: Euh ...

          Posté par Clément Stenac (page perso, ) le 14/05/2006 à 13:49. (lien). Évalué à 2.

          C'est à voir. Il est parfois par exemple possible de régler ces paramètres à la configuration du noyau, ou bien au boot.
          
          Dans le deuxième cas, une fois la configuration faite, on met un flag "configuration terminée". Une fois que ce flag est mis, la configuration n'est plus modifiable avant le prochain reboot, même par root.
          
          Bien évidemment, tout ceci ne protège contre des attaques que d'un root distant, un utilisateur local aura toujours moyen d'overrider ce genre de protections.

        [^]Re: Risque réel?

        Posté par Khanh-Dang (page perso, ) le 14/05/2006 à 13:26. (lien). Évalué à 10.

        Étant donné la sophistication des Unix modernes, pour pouvoir s'assurer de ça, on a besoin de polices qui empêchent certaines actions
        
        J'ai dû relire la phrase plusieurs fois pour y comprendre le sens du mot « police ». Et apparemment, il s'agit d'une traduction malheureuse du mot anglais « policy », qui devrait se traduire par « politique ».

      [^]Admin ou pas admin...

      Posté par Zenitram (page perso, ) le 14/05/2006 à 16:50. (lien). Évalué à 1.

      side note: L'une des premières assomptions d'une analyse sécuritaire est que l'admin n'est PAS hostil, si c'est le cas, en général c'est inutile de chercher plus loin (mauvais admin, changer d'admin).

      
      Euh... On n'a pas du tout le meme point de vue sur un admin : pour moi, un admin est un login comme un autre, avec plus ou moins de droits.
      Il n'a pas, par exemple, à avoir le droit d'accéder aux fichiers d'un utilisateur.
      Donc : il faut aussi gérer, dans l'aspect sécuritaire, les non-droits de l'admin, ca fait partie de la sécurité...
      (en plus de gérer differents admin : admin de backup, admin applicatif, admin systeme...)

      • [^]Re: Admin ou pas admin...

        Posté par tene (page perso, ) le 14/05/2006 à 21:09. (lien). Évalué à 6.

        Pour moi (et dans mes propos précédant) un admin est un être humain, parfois pas tout à fait comme les autres, parfois complètement pas comme les autres, mais parfois il a une vie sociale :p
        
        Sérieusement, je parle de la personne pas de l'utilisateur. Si cette personne est hostile et que cette personne a suffisemment de droit, elle pourra foutre la merde, il est pratiquement impossible de définir une politique de sécurité considérant des administrateurs hostiles.
        
        Ce que tu présentes c'est le cas d'une personne n'étant pas forcément de confiance à qui tu veux donner des droits intermédiaire entre "simple user" et "root". On est d'accord ça peut être utile (et c'est souvent possible), mais sur tous les systèmes (well presque tous), il y'a toujours au sommet qq qui a au moins la possibiltié de donner des droits à tous le monde (et donc de tous faire), que ce soit via 345 comptes différents ou via un seul.
        
        Perso j'ai toujours considéré qu'un root (officiel, ou via une faille, ou via social engineering, etc...) était... root, et que c'tait une illusion de croire que son pouvoir est limité... tout comme une personne ayant un accès physique à la machine peut potentiellement tout faire...