> et après t'exploite une faille locale qui te permet de devenir root.
Sauf qu'ici il faut :
(A)- exploite d'une faille qui permet de devenir root
(B)- exploite de la faille X11
Aujourd'hui (A) n'existe pas. Donc corriger (B) ne sert à rien. Selon les mailings de freedesktop, corrigier (B) est un boulot considérable et qui peut impacter les parformants du système.
Imaginons que (A) existe, ce qui arrivera tout ou tard. Si (A) est utilisé, t'as au moins 5000 façons différentes pour tout péter. Si (B) est colmaté, il n'en reste "que" au moins 4999.
Si pour toi un système donnant 4999 chances sur 5000 de tout péter est sûr, alors t'y comprend rien.
> 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.
Il y a une méprise très grave sur ce qu'est selinux ici. SeLinux ne se substitue pas au modèle traditionnel de sécurité d'Unix. Il le complète seulement (et fort éfficacement).
A celà plusieurs raisons (liste non exhautive):
1- Il n'y au aucun compatibilité entre selinux et le système tradionnel. Si les protections du fichier n'autorise pas l'excécution d'un programme et que selinux l'autorise, le programme n'est pas excécuté.
2- Selinux n'est pas actif dès que le noyau est up contrairement au système traditionnel.
3- Selinux est désactivé lorsqu'on fait un fsck de la partion racine (donc on peut lire et excéuter tous les fichiers permis par le système traditionnel)
4- Il est nécessaire de désactiver selinux pour faire un relabel.
5- Dans un contexte réseau avec des serveurs NFS (voir samba) il faut faire coabiter des machines avec selinux et des machines sans. Les machines sans ne s'appuis que sur le système traditionnel.
6- Tous les systèmes de fichier ne supporte pas selinux
7- Le système doit rester sûr sans selinux (certe moins)
8- Il y a des systèmes sans selinux
9- la sécurité des programmes est conçue sans selinux. Dès que selinux est réveillé, la situation est anormale et il y a probablement un grave problème. La situation ne doit en aucun cas perdurer (que (B) soit exploitable ou non).
Donc il ne faut surtout pas dire :
- "corrigé (B) car selinux sera inopérant si (B) arrivé, et ignoré (A) car selinux s'en charge".
Surtout que le constexte selinux change. Si un programme lancé à distance (par exemple via ssh) peut être inoffensif si selinux est "dur" avec les connections distances, il n'en sera pas forcément de même si root le lance depuis la console par inadvertance.
Selinux n'est pas une solution qui annihile (A) et le rend tolérable !
De plus il y a nombre de chose que Selinux ne peut détecter. Par exemple un exploit sur une base de données qui ensuite demande d'effacer toutes les tables. Dans ce cas là, selinux ne voit RIEN.
Donc atteindre (B) via (A), même avec selinux, ne rend pas pas (A) "gentil".
De plus, colmater (B) alors que (A) peut faire joujou avec le matériel (effacer un disque ?), vider une base de données, innonder le réseau avec des données confidentiels, saturer /tmp, que sais-je encore, est limite accessoire.
Car le contexte de (A), il veint d'où ? Il vient d'un autre programme. Ce programme a à l'évidence une fonction. Pour mener à bien cette fontion, il doit probablement avoir besoin de lire des fichiers, d'en écrire, de faire des connections internets, etc. Selinux est configuré pour permettre à ce programme de bosser et laissera (A) faire des dégâts (certe moins que sans selinux).
> Typiquement, t'utilise ça en combinaison avec pam
Pam c'est pour l'authentification et dans le cas où tu peux diminuer les privilèges *avant* que le programme s'exécute. Le programme faisant peut-être d'autres cap_drop après sont initialisation.
Un fonctionnement typique est :
- pam donne des privilèges (en fait restreint, mais comme il peut ne rien donner, on peut considérer qu'il donne des privilèges).
- le programme en supprime avec cap_drop
> Du coup, il doit sûrement y avoir une combinaison de capacités qui permet de reproduire cette faille sans être root.
Mais il faut aussi un autre gros trou de sécurité. Que la "bonne" combinaison de capacité n'est pas suffisant. Et l'autre gros trou de sécurité il en fera des dégâts avant même qu'il pense à utiliser l'exploit X11.
> 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.
Ben les experts de Xorg on jeté un oeil et n'ont rien trouvé. Je ne crois pas que tu sois plus futé que les experts de Xorg, ni plus futé que les experts de CVE qui n'ont rien trouvé.
> Et qui sait si genre cdrecord
Si genre un cdrecord qui a été piraté et pas un cdrecord normal. Si ton cdrecord a été piraté, je me fairais de gros gros soucis que (B) soit exploité ou non. Car il faut quoi pour pirater cdrecord ? Les droits root.
Au fait, cdrecord peut s'utiliser sans setuid. C'est comme ça depuis au moins 2 ans.
> exploiter une faille dans un programme suid root.
Dans ce cas pourquoi te faire chier avec (B) si t'as déjà (A) (un accès root).
Si t'as (A), tu peux avoir (B) et (C) et (D) et ... (ZZZ).
Pourquoi tu fais cette fixation sur (B) ?
> 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.
Ca atténue le problème, ce n'est pas une solution.
> Avec cette faille c'est foiré.
Avec seulement (A) (qui a des droits root) c'est déjà foiré. Prépares toi à sortir les backups.
> Moi je considère pas que ce soit le cas justement parce que j'utilise des mécanismes pour limiter les possibilités.
Très grave erreur.
> Et cette faille, c'est un trou béant.
Ce n'est pas l'avis d'xorg et du CVE. Il n'est même béant le trou, il n'existe pas.
Puisque tu affirmes qu'il est béant, prend contact avec CVE : http://cve.mitre.org/
> le qualifier de "fan d'OpenBSD"
Je ne pensais pas à lui, mais à celui qui a fait la news et/ou celui/ceux qui l'a/ont validé.
[^] # Re: Futur antérieur..
Posté par clearstream . En réponse à la dépêche Intel libère ses pilotes graphiques. Évalué à -2.
Sauf qu'ici il faut :
(A)- exploite d'une faille qui permet de devenir root
(B)- exploite de la faille X11
Aujourd'hui (A) n'existe pas. Donc corriger (B) ne sert à rien. Selon les mailings de freedesktop, corrigier (B) est un boulot considérable et qui peut impacter les parformants du système.
Imaginons que (A) existe, ce qui arrivera tout ou tard. Si (A) est utilisé, t'as au moins 5000 façons différentes pour tout péter. Si (B) est colmaté, il n'en reste "que" au moins 4999.
Si pour toi un système donnant 4999 chances sur 5000 de tout péter est sûr, alors t'y comprend rien.
> 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.
Il y a une méprise très grave sur ce qu'est selinux ici. SeLinux ne se substitue pas au modèle traditionnel de sécurité d'Unix. Il le complète seulement (et fort éfficacement).
A celà plusieurs raisons (liste non exhautive):
1- Il n'y au aucun compatibilité entre selinux et le système tradionnel. Si les protections du fichier n'autorise pas l'excécution d'un programme et que selinux l'autorise, le programme n'est pas excécuté.
2- Selinux n'est pas actif dès que le noyau est up contrairement au système traditionnel.
3- Selinux est désactivé lorsqu'on fait un fsck de la partion racine (donc on peut lire et excéuter tous les fichiers permis par le système traditionnel)
4- Il est nécessaire de désactiver selinux pour faire un relabel.
5- Dans un contexte réseau avec des serveurs NFS (voir samba) il faut faire coabiter des machines avec selinux et des machines sans. Les machines sans ne s'appuis que sur le système traditionnel.
6- Tous les systèmes de fichier ne supporte pas selinux
7- Le système doit rester sûr sans selinux (certe moins)
8- Il y a des systèmes sans selinux
9- la sécurité des programmes est conçue sans selinux. Dès que selinux est réveillé, la situation est anormale et il y a probablement un grave problème. La situation ne doit en aucun cas perdurer (que (B) soit exploitable ou non).
Donc il ne faut surtout pas dire :
- "corrigé (B) car selinux sera inopérant si (B) arrivé, et ignoré (A) car selinux s'en charge".
Surtout que le constexte selinux change. Si un programme lancé à distance (par exemple via ssh) peut être inoffensif si selinux est "dur" avec les connections distances, il n'en sera pas forcément de même si root le lance depuis la console par inadvertance.
Selinux n'est pas une solution qui annihile (A) et le rend tolérable !
De plus il y a nombre de chose que Selinux ne peut détecter. Par exemple un exploit sur une base de données qui ensuite demande d'effacer toutes les tables. Dans ce cas là, selinux ne voit RIEN.
Donc atteindre (B) via (A), même avec selinux, ne rend pas pas (A) "gentil".
De plus, colmater (B) alors que (A) peut faire joujou avec le matériel (effacer un disque ?), vider une base de données, innonder le réseau avec des données confidentiels, saturer /tmp, que sais-je encore, est limite accessoire.
Car le contexte de (A), il veint d'où ? Il vient d'un autre programme. Ce programme a à l'évidence une fonction. Pour mener à bien cette fontion, il doit probablement avoir besoin de lire des fichiers, d'en écrire, de faire des connections internets, etc. Selinux est configuré pour permettre à ce programme de bosser et laissera (A) faire des dégâts (certe moins que sans selinux).
> Typiquement, t'utilise ça en combinaison avec pam
Pam c'est pour l'authentification et dans le cas où tu peux diminuer les privilèges *avant* que le programme s'exécute. Le programme faisant peut-être d'autres cap_drop après sont initialisation.
Un fonctionnement typique est :
- pam donne des privilèges (en fait restreint, mais comme il peut ne rien donner, on peut considérer qu'il donne des privilèges).
- le programme en supprime avec cap_drop
> Du coup, il doit sûrement y avoir une combinaison de capacités qui permet de reproduire cette faille sans être root.
Mais il faut aussi un autre gros trou de sécurité. Que la "bonne" combinaison de capacité n'est pas suffisant. Et l'autre gros trou de sécurité il en fera des dégâts avant même qu'il pense à utiliser l'exploit X11.
> 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.
Ben les experts de Xorg on jeté un oeil et n'ont rien trouvé. Je ne crois pas que tu sois plus futé que les experts de Xorg, ni plus futé que les experts de CVE qui n'ont rien trouvé.
> Et qui sait si genre cdrecord
Si genre un cdrecord qui a été piraté et pas un cdrecord normal. Si ton cdrecord a été piraté, je me fairais de gros gros soucis que (B) soit exploité ou non. Car il faut quoi pour pirater cdrecord ? Les droits root.
Au fait, cdrecord peut s'utiliser sans setuid. C'est comme ça depuis au moins 2 ans.
> exploiter une faille dans un programme suid root.
Dans ce cas pourquoi te faire chier avec (B) si t'as déjà (A) (un accès root).
Si t'as (A), tu peux avoir (B) et (C) et (D) et ... (ZZZ).
Pourquoi tu fais cette fixation sur (B) ?
> 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.
Ca atténue le problème, ce n'est pas une solution.
> Avec cette faille c'est foiré.
Avec seulement (A) (qui a des droits root) c'est déjà foiré. Prépares toi à sortir les backups.
> Moi je considère pas que ce soit le cas justement parce que j'utilise des mécanismes pour limiter les possibilités.
Très grave erreur.
> Et cette faille, c'est un trou béant.
Ce n'est pas l'avis d'xorg et du CVE. Il n'est même béant le trou, il n'existe pas.
Puisque tu affirmes qu'il est béant, prend contact avec CVE :
http://cve.mitre.org/
> le qualifier de "fan d'OpenBSD"
Je ne pensais pas à lui, mais à celui qui a fait la news et/ou celui/ceux qui l'a/ont validé.