Si le compteur ne fuyait pas tu pourrais pas l'overflow car tu te mangerai le Out of Memory Killer bien avant ça.
Tu n'aurais, au contraire, rien du tout :p
Reste plus qu'a déclencher un syscall
Pas n'importe quel syscall: justement un syscall qui va utiliser l'objet keyring associé au process courant. Cet object contient, à une indirection près, un pointeur vers une fonction que ce syscall va appeller.
J'en profite pour poser la question de l'éventualité d'une 4)me méthode de protection:
Remplacer toutes ces pointeurs vers une "struct xxx_ops" par un index sur tableau statique. Dans ce cas, au lieu que le noyau appelle keyring->type->revoke(), il pourrait appeller keyring_methods[keyring->type]->revoke(). On pourrait même borner le keyring->type avec un masque de manière très peu coûteuse... Serait-ce pensable ?
L'explication en (削除) deux (削除ここまで) trois lignes serait: à cause d'un overflow sur un compteur de référence que le noyau oublie de décrémenter, le noyau va être amené à libéré la mémoire représentant le keyring associé au processus attaquant sans pour autant effacer l'association qu'a ce processus à ce keyring. Ensuite le processus, au moyen de sous-système d'ipc, va faire allouer de mémoire noyau qui va être mappée dans son espace utilisateur et, en s'appuyant sur une spécificité de l'allocateur slab, cela va avoir pour résultat que c'est cette même mémoire qui va se retrouver mappée (donc maintenant manipulable par le processus attaquant). Pas de chance, cette mémoire est sensée contenir un pointeur vers une fonction que le noyau va tout naturellement exécuter lors d'un appel système keyring/revoke, sans se douter que ce pointeur pointe maintenant vers du code contrôlé par le processus attaquant...
1) La proposition impossible car complétement anti-performante
Impossible...?? C'est pas un peu le principe de udref ? Et les micro noyaux ?
[^] # Re: Journal bookmark inutile.
Posté par benja . En réponse au journal faille Linux 0 day du 19 janvier 2016. Évalué à 5.
Tu n'aurais, au contraire, rien du tout :p
Pas n'importe quel syscall: justement un syscall qui va utiliser l'objet keyring associé au process courant. Cet object contient, à une indirection près, un pointeur vers une fonction que ce syscall va appeller.
J'en profite pour poser la question de l'éventualité d'une 4)me méthode de protection:
Remplacer toutes ces pointeurs vers une "
struct xxx_ops" par un index sur tableau statique. Dans ce cas, au lieu que le noyau appellekeyring->type->revoke(), il pourrait appellerkeyring_methods[keyring->type]->revoke(). On pourrait même borner le keyring->type avec un masque de manière très peu coûteuse... Serait-ce pensable ?L'explication en
(削除) deux (削除ここまで)trois lignes serait: à cause d'un overflow sur un compteur de référence que le noyau oublie de décrémenter, le noyau va être amené à libéré la mémoire représentant le keyring associé au processus attaquant sans pour autant effacer l'association qu'a ce processus à ce keyring. Ensuite le processus, au moyen de sous-système d'ipc, va faire allouer de mémoire noyau qui va être mappée dans son espace utilisateur et, en s'appuyant sur une spécificité de l'allocateur slab, cela va avoir pour résultat que c'est cette même mémoire qui va se retrouver mappée (donc maintenant manipulable par le processus attaquant). Pas de chance, cette mémoire est sensée contenir un pointeur vers une fonction que le noyau va tout naturellement exécuter lors d'un appel système keyring/revoke, sans se douter que ce pointeur pointe maintenant vers du code contrôlé par le processus attaquant...Impossible...?? C'est pas un peu le principe de udref ? Et les micro noyaux ?