En fait il y a deux "proof of concept" (exemple d'exploits).
L'un utilise le mode SMM pour viander toutes les protections du noyaux et pouvoir obtenir les droits niveau noyau.
Pour ceci, l'attaquant a besoin d'obtenir les droits de déclancher une intéruptions SMI pour passer en mode SMM et de pouvoir écrire le code qui va bien, là où il faut pour pouvoir exécuter ce code en mode protégé (le noyau n'y voyant rien du tout).
Concrètement, tu diffuse un module X proprio (genre NVIDIA corrompu), ton root l'installe.
Ton code modifié va ouvrir une ouverture d'accès direct a la mémoire vidéo légèrement modifié pour écrire dans la partie de mémoire que le mode SMM peut exécuter.
Après il se débrouille pour lancer une intéruption SMI et paf il charge un module qui lui donne un full accès niveau noyau.
Le cas concret est un de tes utilisateurs XEN se fait trouer et le pirate veux devenir calife a la place du calife...
Pour cette faille il est possible de se protéger en posant certains flags qui vont bien pour interdire le lancement de cette instruction SMI.
Sinon y avais un second hack, mais j'ai déjà oublié...
Enfin la seule solution pour corriger ça serait d'avoir du code "sûr" en mode noyau (avec une whiteliste des fonctions/registres autorisées) et lasser le code useland en ring3 (tournant sous nobody par exemple).
Mais pour ça il faudrait que les fabricants de cartes graphiques qui payent ces même développeurs se décident a libérer les specs de leurs cartes :'(
[^] # Re: petites corrections par rapport au journal
Posté par Raphaël G. (site web personnel) . En réponse à la dépêche Graves problèmes de sécurité dans x.org. Évalué à 4.
L'un utilise le mode SMM pour viander toutes les protections du noyaux et pouvoir obtenir les droits niveau noyau.
Pour ceci, l'attaquant a besoin d'obtenir les droits de déclancher une intéruptions SMI pour passer en mode SMM et de pouvoir écrire le code qui va bien, là où il faut pour pouvoir exécuter ce code en mode protégé (le noyau n'y voyant rien du tout).
Concrètement, tu diffuse un module X proprio (genre NVIDIA corrompu), ton root l'installe.
Ton code modifié va ouvrir une ouverture d'accès direct a la mémoire vidéo légèrement modifié pour écrire dans la partie de mémoire que le mode SMM peut exécuter.
Après il se débrouille pour lancer une intéruption SMI et paf il charge un module qui lui donne un full accès niveau noyau.
Le cas concret est un de tes utilisateurs XEN se fait trouer et le pirate veux devenir calife a la place du calife...
Pour cette faille il est possible de se protéger en posant certains flags qui vont bien pour interdire le lancement de cette instruction SMI.
Sinon y avais un second hack, mais j'ai déjà oublié...
Enfin la seule solution pour corriger ça serait d'avoir du code "sûr" en mode noyau (avec une whiteliste des fonctions/registres autorisées) et lasser le code useland en ring3 (tournant sous nobody par exemple).
Mais pour ça il faudrait que les fabricants de cartes graphiques qui payent ces même développeurs se décident a libérer les specs de leurs cartes :'(