Pour exploiter cette faille afin de contourner AppArmor, SeLinux et
autres, il faut déjà être root ! (dexit l'auteur du papier). Donc il faut déjà exploiter une autre faille. Et on peut supposer que cette autre faille ne contourne pas Selinux etc. Sinon qu'elle est l'intérêt de la faille découverte par Loïc Duflot ?
Il faut exploiter une autre faille ? Et donc ? Les failles deviennent souvent dangereuses en combinaison, c'est assez rare les failles "arg, n'importe qui peut devenir root à distance". Plus souvent, t'exploite déjà une failledistante qui te donne un accès apache genre, et après t'exploite une faille locale qui te permet de devenir root.
Ah oui, et puis "devenir root" n'exige pas forcément une faille. Tu peux souhaiter que l'utilisateur légitime de root n'aie pas accès à certaines choses, et c'est justement l'interêt de ces systèmes de sécurité.
L'idée c'est que pour obtenir un système Unix un peu plus sécurisé de nos jours, on utilise deux systèmes de sécurité: le mécanisme standard des utilisateurs Unix, et un mécanisme en plus (genre AppArmor, SELinux, securelevels, ...), le mécanisme en plus permettant de limiter les possibilités plus finement, et même pour les personnes en haut de l'échelle Unix normale (genre root ou sudoers). Cette faille fout en l'air ça.
Quand je me loggue root sur ma bécane, je ne pense pas qu'exploiter une faille de X11 me donne encore plus accès à ma bécane. Et toi ?
*Ta* bécane, non. Mais une bécane utilisant SELinux pour limiter les possibilités de root, si. Et dans ces cas là, cette faille est vraiment génante.
Sur un système Linux moderne, ça veux pas forcément dire être root
Je développe ce que je voulais dire, parce que visiblement on s'est pas compris.
Quand je disais ça, je voulais dire que y'a des tonnes de mécanismes sur un Linux moderne qui permettent à un logiciel d'avoir une partie seulement des pouvoirs de root, sous la formes des capacités par exemple. Typiquement, t'utilise ça en combinaison avec pam pour permettre à tel ou tel programme de se lancer en mode realtime, ou d'avoir accès à un matos précis, ...
Du coup, il doit sûrement y avoir une combinaison de capacités qui permet de reproduire cette faille sans être root. C'est pas développé dans le papier, parce qu'il s'intéresse pas à Linux en particulier, mais il suffirait de jeter un oeil plus précisément pour trouver. Et qui sait si genre cdrecord, ou je ne sais quel programme utilisant le hardware en mode bas-niveau n'a pas ces capacités là.
Et puis sinon, y'a une autre méthode assez bête: exploiter une faille dans un programme suid root.
Et là, on en revient à ce que je disait, les trucs genre SELinux sont conçus précisément pour éviter qu'une personne exploitant une faille pour devenir root soit le maître de la machine. Avec cette faille c'est foiré. Et j'ai pris SELinux, mais y'a des tonnes de choses de ce genre, genre jail(), les vservers, UML, ... A priori, cette faille peut les foutre par terre.
Il y a foutage de gueule de dire qu'un trou de sécurité potentiel est grave si et seulement si le système est une vraie passoire.
Libre à toi de considérer "y'a une faille qui permet de passer root en local" est l'équivalent de "le système est une vraie passoire". Moi je considère pas que ce soit le cas justement parce que j'utilise des mécanismes pour limiter les possibilités. Cette faille bousille ça, ça m'embête.
La chose est simple: des failles qui permettent de passer root, y'a en tout le temps. Des failles qui permettent de passer les systèmes de sécurité "alternatifs", y'en a très peu souvent, voire même quasiment jamais. Et cette faille, c'est un trou béant. Donc elle a de l'importance.
Encore faut-il être en position exploiter cette faille ce qui n'est pas une mince affaire. Donc, je répète, il faut le faire en deux phases et pour la première phase, on ne sait RIEN.
Ben oui, parce que le type est chercheur en sécurité, alors il va pas expliquer comment exécuter du code en tant que root sur une machine Unix, ce serait assez inintéressant.
Pour cette histoire avec Théo de Raadt, effectivement il bosse pour OpenBSD, c'est même le leader et développeur principal, alors le qualifier de "fan d'OpenBSD" ... Le fond je sais pas, j'ai pas lu le thread.
[^] # Re: Futur antérieur..
Posté par djrom . En réponse à la dépêche Intel libère ses pilotes graphiques. Évalué à 2.
Il faut exploiter une autre faille ? Et donc ? Les failles deviennent souvent dangereuses en combinaison, c'est assez rare les failles "arg, n'importe qui peut devenir root à distance". Plus souvent, t'exploite déjà une failledistante qui te donne un accès apache genre, et après t'exploite une faille locale qui te permet de devenir root.
Ah oui, et puis "devenir root" n'exige pas forcément une faille. Tu peux souhaiter que l'utilisateur légitime de root n'aie pas accès à certaines choses, et c'est justement l'interêt de ces systèmes de sécurité.
L'idée c'est que pour obtenir un système Unix un peu plus sécurisé de nos jours, on utilise deux systèmes de sécurité: le mécanisme standard des utilisateurs Unix, et un mécanisme en plus (genre AppArmor, SELinux, securelevels, ...), le mécanisme en plus permettant de limiter les possibilités plus finement, et même pour les personnes en haut de l'échelle Unix normale (genre root ou sudoers). Cette faille fout en l'air ça.
*Ta* bécane, non. Mais une bécane utilisant SELinux pour limiter les possibilités de root, si. Et dans ces cas là, cette faille est vraiment génante.
Je développe ce que je voulais dire, parce que visiblement on s'est pas compris.
Quand je disais ça, je voulais dire que y'a des tonnes de mécanismes sur un Linux moderne qui permettent à un logiciel d'avoir une partie seulement des pouvoirs de root, sous la formes des capacités par exemple. Typiquement, t'utilise ça en combinaison avec pam pour permettre à tel ou tel programme de se lancer en mode realtime, ou d'avoir accès à un matos précis, ...
Du coup, il doit sûrement y avoir une combinaison de capacités qui permet de reproduire cette faille sans être root. C'est pas développé dans le papier, parce qu'il s'intéresse pas à Linux en particulier, mais il suffirait de jeter un oeil plus précisément pour trouver. Et qui sait si genre cdrecord, ou je ne sais quel programme utilisant le hardware en mode bas-niveau n'a pas ces capacités là.
Et puis sinon, y'a une autre méthode assez bête: exploiter une faille dans un programme suid root.
Et là, on en revient à ce que je disait, les trucs genre SELinux sont conçus précisément pour éviter qu'une personne exploitant une faille pour devenir root soit le maître de la machine. Avec cette faille c'est foiré. Et j'ai pris SELinux, mais y'a des tonnes de choses de ce genre, genre jail(), les vservers, UML, ... A priori, cette faille peut les foutre par terre.
Libre à toi de considérer "y'a une faille qui permet de passer root en local" est l'équivalent de "le système est une vraie passoire". Moi je considère pas que ce soit le cas justement parce que j'utilise des mécanismes pour limiter les possibilités. Cette faille bousille ça, ça m'embête.
La chose est simple: des failles qui permettent de passer root, y'a en tout le temps. Des failles qui permettent de passer les systèmes de sécurité "alternatifs", y'en a très peu souvent, voire même quasiment jamais. Et cette faille, c'est un trou béant. Donc elle a de l'importance.
Ben oui, parce que le type est chercheur en sécurité, alors il va pas expliquer comment exécuter du code en tant que root sur une machine Unix, ce serait assez inintéressant.
Pour cette histoire avec Théo de Raadt, effectivement il bosse pour OpenBSD, c'est même le leader et développeur principal, alors le qualifier de "fan d'OpenBSD" ... Le fond je sais pas, j'ai pas lu le thread.