Faille Lazy FPU state restore

62
21
juin
2018
Sécurité

Intel est de nouveau confronté à la découverte d’une faille, le Lazy FPU State Restore flaw.
Cette fois, seule la famille des Intel Core serait concernée.

Sommaire

Le FPU

Le FPU, c’est le bordel, par Ingo Molnar

L’unité de calcul en virgule flottante, le FPU, possède une série de registres qui lui permet de « définir » son état courant. Lors du basculement d’une tâche à une autre (context switching), cet état est alors restauré pour retrouver un contexte correspondant au processus en cours. Ces opérations peuvent être coûteuses car les registres du FPU sont plus gros que les autres, c’est pourquoi les FPU fournissent une option pour désactiver toute opération en virgule flottante (CR0:TS). Aussi, dès qu’un calcul en virgule flottante est appelé, une exception est lancée pour « réveiller » le FPU avant de lancer l’opération normalement.
Lorsque cette exception (fpudna, FPU Device Not Available) se produit, un « gestionnaire de contexte FPU » vérifie quel processus a la main sur le FPU à ce moment‐là.
S’il s’agit d’un autre processus, il procède à la sauvegarde puis la restauration des registres, ou s’il s’agit d’un nouveau contexte, la sauvegarde puis le nettoyage des registres ; sinon, il ne fait rien : c’est le mode « paresseux » (lazy). À la sortie du processus, il ne faut pas oublier de « nettoyer » ces tables et de (re)lever tous les drapeaux liés à cette exception.

En mode eager (zélé, volontaire), la sauvegarde et restauration des registres associés au FPU est effectuée quoiqu’il advienne, au moment du changement de tâche et non durant l’exécution de la tâche qui vient de prendre la main.

Le bâton

Au fil des années, les processeurs ont multiplié les registres pour prendre en charge les instructions de type SIMD, soit une instruction capable de procéder au même calcul sur un ensemble de paires de données.

Les registres SSE, AVX et MMX restent associés au FPU et seront donc intégrés au mécanisme de sauvegarde et restauration… et ils peuvent contenir jusqu’à 2 048 bits de données, rien que sur l’AVX.

[    0.000000] Linux version 4.14.48-intel-pk-standard (oe-user@oe-host) (icc version 18.0.2 (gcc version 7.3.0 compatibility)) #2 SMP PREEMPT Wed Jun 20 13:21:48 UTC 2018                                                              
[    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'                               
[    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'                                              
[    0.000000] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'                                       
[    0.000000] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'                                                    
[    0.000000] x86/fpu: xstate_offset[3]:  576, xstate_sizes[3]:   64                                                
[    0.000000] x86/fpu: xstate_offset[4]:  640, xstate_sizes[4]:   64                                                
[    0.000000] x86/fpu: Enabled xstate features 0x1b, context size is 704 bytes, using 'compacted' format.

Pour se faire battre

Par le biais désormais connu de l’exécution spéculative puis de l’analyse de cache, un attaquant pourra lire ces registres depuis un autre processus, voire depuis une machine virtuelle. En effet, en mode lazy la sauvegarde des registres d’une tâche s’effectue au cours de l’exécution d’une autre tâche. La spéculation ignorant le drapeau CR0:TS, tout est alors possible.

Ces registres peuvent contenir des informations sensibles comme des clefs de chiffrement (AES), par le biais des instructions d’accélération matérielle AES-NI.

Delivers Fast, Affordable Data Protection and Security. AHeum.

Colin Percival, ex‐membre de l’équipe sécurité de FreeBSD, a codé un exploit en quelques heures et note, dans un tweet :

« You need to be able to execute code on the same CPU as the target process in order to steal cryptographic keys this way. You also need to perform a specific sequence of operations before the CPU pipeline completes, so there’s a narrow window for execution. »

« Vous devez être en mesure d’exécuter le code de [l’exploit] sur le même processeur que celui de la cible pour voler les clefs de cette manière. Vous devrez en outre appliquer une suite précise d’opérations avant que la chaîne de traitement du processeur ne se termine ; de fait, la fenêtre de tir est très étroite. »

Ce qui semble vouloir dire que, pour l’instant, coder le vol de données depuis un script venu du Web n’est pas simple à réaliser. Le temps nécessaire au vol des données des registres est la clef de l’attaque. Il faut le terminer avant que le séquenceur ne préempte la victime et que les valeurs des registres ne soient modifiées.

Pour y arriver, les chercheurs ont utilisé plusieurs méthodes :

Exception

Il s’agit de coder la fuite de données à l’ombre d’une exception, sciemment provoquée, tel un page fault, par exemple. Mais il s’avère que cette solution est trop lente pour récupérer tout un jeu de registres.

Intel TSX

Cette mécanique n’est disponible que sur les architectures récentes (à partir de Haswell), ce qui limite l’angle d’attaque. Cette technologie comporte un jeu d’instructions appelé RTM (Restricted Transactional Memory) qui permet d’annuler un bloc d’exécution en cas d’interruption ; il suffit d’y encadrer le code malicieux, qui va innocemment faire appel au FPU, pour lever l’exception fpudna… Ce serait presque « étudié pour ».

Retpoline

Il s’agit au départ d’une contre‐mesure pour Spectre. Elle vise à fourvoyer sciemment le processeur sur l’adresse de retour d’un RET en plaçant une « fausse » boucle et donc le forcer à exécuter de manière spéculative un code innocent. Le code malicieux sera donc placé à cet endroit.

Les correctifs

Le mode lazy semble moins pertinent aujourd’hui. Les gains en performance sont faibles avec les architectures récentes et, surtout, selon les usages actuels. Le FPU étant même beaucoup plus utilisé dans nos logiciels, son usage serait contre‐productif.
En effet, les compilateurs choisissent d’appeler les instructions SIMD (i.e. -sse) pour optimiser le code des logiciels. De fait, ceux‐ci auront de toute façon sauvegardé et restauré les registres du FPU à chaque changement de contexte. La gestion de l’exception sera inutile et va juste alourdir le processus. En outre, l’empreinte d’une sauvegarde et restauration serait moindre que celle de la gestion des drapeaux, des registres et de leurs états suite à l’interruption, le transfert de registres FPU en mémoire étant plus rapide car optimisé.

Il est donc préconisé d’éviter le mode lazy au profit du mode eager.

  • Linux propose le mode eager plutôt que le mode lazy depuis la version 3.7 et l’active par défaut depuis la version 4.9 ;
  • ajoutez eagerfpu=on sur la ligne de démarrage pour les versions antérieures à la 4.9 ;
  • FreeBSD a poussé un correctif pour la Release 11.2 ; c’est un FreeBSD 11.1 qui a servi de cobaye ;
  • DragonFly BSD a poussé un correctif dans la version 5.2.2 ;
  • Microsoft poussera un correctif en juillet ;
  • OpenBSD a poussé un correctif le 14 juin pour la version 6.3 ;
  • NetBSD a poussé un correctif le 16 juin sur MAIN ;
  • Illumos a poussé un correctif le 19 juin.

Conclusion

Ils ne sont pas à la fête cette année, chez Intel. Le point positif est que la correction de cette faille devrait conduire à une amélioration des performances, voire de la consommation d’énergie.

Theo de Raadt avait prévenu 11 ans auparavant que l’architecture Intel Core 2 promettait ce genre de faille :

« These processors are buggy as hell, and some of these bugs don’t just cause development/debugging problems, but will ASSUREDLY be exploitable from userland code. »

« Ces processeurs sont bogués comme jamais et nombre de ces bogues ne provoquent pas seulement des soucis de développement et d’analyse, mais ils vont assurément être exploitables depuis l’espace utilisateur. »

Pour la petite histoire, l’embargo s’est terminé le 6 juin. Colin Percival, qui assistait à une conférence de Théo de Raadt lors de la BSDCan 2018, a codé un exploit dans la foulée, qu’il n’a pas encore rendu public. Mais il a convaincu Intel de lever l’embargo au plus vite.
Il est notable qu’aucun des deux n’avait été mis dans la confidence ; OpenBSD signale même qu’ils en ont fait la demande (des rumeurs circulaient autour d’une énième version de Spectre), mais sans obtenir de réponse.

Invitation to Embargo? No.
We asked.
No reply.

Aller plus loin

  • # derniere minutes

    Posté par (page perso) . Évalué à 3.

  • # Wahou, Linux est super à jour!

    Posté par (page perso) . Évalué à 10.

    Quand je lis que la faille est comblée depuis le noyau 4.9, cela fait plaisir car ma distro préférée l'utilise depuis Juillet 2017, soit un an avant le correctif Microsoft ;-)

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

  • # CVE 2018-3665

    Posté par (page perso) . Évalué à 7.

    Le CVE, bien que réservé pour cette faille, n'était pas encore rendu public lors de la publication de la dépêche.

    Il est désormais accessible .

  • # Encore une autre faille chez Intel....

    Posté par . Évalué à 1.

    …par un attaquant ayant abusé de son mode super-user pour pénétrer un système asservi. D'après certains experts, le système d'exploitation serait en cause.

  • # Embargo sur les failles de sécurité et OpenBSD

    Posté par (page perso) . Évalué à 7.

    Pour cette faille, je vois que l'embargo était prévu après le 13 juin 2018, et Theo de Raadt a donné une conférence sur la faille le 9 juin. C'est moi ou bien Theo ne respecte pas les embargos, puis il râle qu'on ne le mette pas dans le secret ?

    Pour les failles Meltdown et Spectre, le projet OpenBSD avait râlé qu'ils n'avaient pas été inclus dans l'embargo.
    https://marc.info/?l=openbsd-tech&m=151521435721902&w=2

    Autre exemple au pif trouvé sur l'Internet : "OpenBSD has a reputation for not respecting embargoes, even as recently as the KRACK wifi thing last year".
    https://news.ycombinator.com/item?id=16440948

    Info à la source : "What happened is that he told me on July 15, and gave a 6 weeks embargo until end of August. We already complained back then that this was way too long and leaving people exposed."
    https://lobste.rs/s/dwzplh/krack_attacks_breaking_wpa2#c_pbhnfz

    Je comprends : "Nous, OpenBSD, décidons de la date de l'embargo."

    Ensuite, faut pas venir pleurer et faire sa victime après…

    Je trouve le comportement d'OpenBSD et de GRsecurity assez similaire. Leur seul argument de vente est la sécurité et ils ont du mal à collaborer.

    Après j'suis pas un grand fan des embargos, et je trouve le projet Zero de Google assez courageux sur le très court délai avant publication des détails d'une vulnérabilité (genre 7 jours pour les failles les plus graves, 90 jours au pire).
    https://en.wikipedia.org/wiki/Project_Zero

    • [^] # Re: Embargo sur les failles de sécurité et OpenBSD

      Posté par (page perso) . Évalué à 10.

      Tu as raté une des dernières phrases de la dépêche : OpenBSD n'était pas au courant de l'embargo (ils ont demandé à en faire partie et cela leur a été refusé). Ils ont juste deviné la faille indépendamment : si eux l'ont deviné, c'est que d'autres moins bien intentionnés ont probablement pu le faire également, car maintenant que les esprits sont tournés vers ce type de faille, il n'est pas surprenant de les voir surgir plus facilement.

      Pour KRACK, c'est bien connu qu'ils ont appliqué leur patch (sans commentaires) avec l'accord de la personne gérant l'embargo, dont ils ont respecté les délais initiaux — cela illustre juste que le secret dans ce genre de choses ne tient qu'à un fil, même si en l'occurrence c'est pas évident que quiconque ai fait un lien entre ce patch sans commentaires et en apparence spécifique et la faille qui a été publiée deux-trois mois plus tard ; en tous cas le web a été silencieux jusqu'à publication, contrairement au cas de Meltdown et Spectre où Linux a clairement révélé les choses avec ses patchs de Décembre — chose que je comprends parfaitement vu la longueur inouï de l'embargo, plus le fait qu'un article de blog plus ou moins décrivait innocemment la faille Meltdown (sans lui donner de nom) plusieurs mois avant : qui sait combien de monde était déjà au courant ?

      • [^] # Re: Embargo sur les failles de sécurité et OpenBSD

        Posté par (page perso) . Évalué à 10. Dernière modification le 04/07/18 à 12:07.

        contrairement au cas de Meltdown et Spectre où Linux a clairement révélé les choses avec ses patchs de Décembre

        Plus précisément, Linux en tant que tel n'est pas informé des embargo dont il font l'objet. Ce sont les entreprises qui y contribuent comme Canonical, Red Hat, Intel et AMD qui ont été mis au parfum pour élaborer un correctif.

        Ils ont essayé de le passer discrètement en décembre durant la phase de merge, pour être sûr qu'au moment de la levée de l'embargo le correctif soit disponible pour la version suivante (et non 2 mois après encore). Mais dommage pour eux, cela a éveillé la curiosité des mainteneurs et observateurs qui y ont vu un truc louche et ont découvert le pot au rose.

        C'est justement parce que les mainteneurs et Linus n'ont pas été au courant que cela s'est passé ainsi en fait. Sinon ils auraient pu essayer d'avoir la certitude que le correctif soit appliqué même en dehors de la période de merge.

        chose que je comprends parfaitement vu la longueur inouï de l'embargo

        La durée fut longue due aux nombres d'acteurs impliqués (cela concerne les fondeurs de puce et les noyaux) et à la difficulté de mettre au point une parade efficace sans trop détruire les performances.

        Mais cela génère de l'expérience pour traiter ces situations, nulle doute qu'une faille proche de ceux-ci dans l'esprit serait corrigée plus vite.

  • # Commentaire supprimé

    Posté par . Évalué à -6. Dernière modification le 24/07/18 à 07:40.

    Ce commentaire a été supprimé par l'équipe de modération.

    • [^] # Spam

      Posté par (page perso) . Évalué à 3.

      Tout un commentaire juste pour placer un lien sur un tout autre sujet ? Y a pas assez de moyen de parler de Drupal normalement ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.