L'objectif était de montrer que partant d'un shell d'un utilisateur standard, on peut exécuter une commande (mount) que seul l'utilisateur root est habilité à exécuter.
Donc on utilise un namespace dédié qui permet de faire un mount. C'est un peu le but du namespace en fait?
Je comprends toujours pas, mais je dois rater un truc obvious. Dans le namespace les droits sont bien conservés (je peux pas lire /etc/shadow depuis le namespace par exemple). Je peux pas monter le disque /dev/sda pour lire des trucs dessus, je peux pas faire un chmod +s.
Je crois que le truc, c'est que tu peux faire des manips que tu ne devrait pas pouvoir faire, et donc potentiellement, si les autres couches de sécurité autour sont trouées, réaliser un exploit.
Donc en gros, sur x couches de sécurité, il y en a une qui est exploitable, il faut la renforcer, car on ne peut pas présumer que les autres couches seront toujours solides.
ouais, c'est ça. Si j'ai bien compris, il y a des coins du noyau qui sont moins audités. Genre la gestion des règles nf/iptables, c'est pas super audité parceque seul root peut y accéder, donc même s'il y a une vuln, l'attaquant doit être root pour la jouer, donc il gagne rien.
Avec les namespaces, tu peux taper ces interfaces en étant simple utilisateur. Je dis iptables, mais c'est aussi mount.
Bref, pas besoin de courir les bras en l'air, c'est juste qu'une supposée défense est contournable. Patchons tranquillement dans le calme et la sérénité.
L'article de Bleeping Computer sur le sujet est un résumé assez clair (pour qui lit l'anglais), et confirme que c'est juste un élément dans un exploit potentiel qui se ferait en combinant plusieurs trous de sécurité.
# okok
Posté par octane . Évalué à 4 (+2/-0).
Je ne comprends pas trop le poc final (?)
et donc, on a fait un bind mount? je ne vois pas ce qu'il fait avec ça (???)
[^] # Re: okok
Posté par Voltairine . Évalué à 4 (+2/-0).
L'objectif était de montrer que partant d'un shell d'un utilisateur standard, on peut exécuter une commande (mount) que seul l'utilisateur root est habilité à exécuter.
[^] # Re: okok
Posté par octane . Évalué à 2 (+0/-0).
Donc on utilise un namespace dédié qui permet de faire un mount. C'est un peu le but du namespace en fait?
Je comprends toujours pas, mais je dois rater un truc obvious. Dans le namespace les droits sont bien conservés (je peux pas lire /etc/shadow depuis le namespace par exemple). Je peux pas monter le disque /dev/sda pour lire des trucs dessus, je peux pas faire un chmod +s.
Je relis l'adviso, mais je comprends pas.
[^] # Re: okok
Posté par cg . Évalué à 5 (+3/-0).
J'avoue, j'ai relu trois fois.
Je crois que le truc, c'est que tu peux faire des manips que tu ne devrait pas pouvoir faire, et donc potentiellement, si les autres couches de sécurité autour sont trouées, réaliser un exploit.
Donc en gros, sur x couches de sécurité, il y en a une qui est exploitable, il faut la renforcer, car on ne peut pas présumer que les autres couches seront toujours solides.
Un truc de ce genre ?
[^] # Re: okok
Posté par octane . Évalué à 3 (+1/-0).
ouais, c'est ça. Si j'ai bien compris, il y a des coins du noyau qui sont moins audités. Genre la gestion des règles nf/iptables, c'est pas super audité parceque seul root peut y accéder, donc même s'il y a une vuln, l'attaquant doit être root pour la jouer, donc il gagne rien.
Avec les namespaces, tu peux taper ces interfaces en étant simple utilisateur. Je dis iptables, mais c'est aussi mount.
Bref, pas besoin de courir les bras en l'air, c'est juste qu'une supposée défense est contournable. Patchons tranquillement dans le calme et la sérénité.
# Autre article
Posté par cg . Évalué à 2 (+0/-0).
L'article de Bleeping Computer sur le sujet est un résumé assez clair (pour qui lit l'anglais), et confirme que c'est juste un élément dans un exploit potentiel qui se ferait en combinant plusieurs trous de sécurité.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.