Sommaire
Matériel
Fin mai 2019, Intel dévoilait une faille autour de sa technologie MDS.
MDS est une optimisation qui permet de remplir des petites structures temporaires (micro‐architecturaux) lors des opérations load, fill et store. Lorsque le code d’une branche est rencontré, le mécanisme de prédiction va exécuter le code en avance sans attendre le résultat de la branche et ainsi remplir ces structures. Consultez ce diagramme pour mieux vous le représenter. En cas d’invalidation de la branche, ces structures ne sont pas vidées.
Exploitée par le biais désormais célèbre de l’attaque par canal auxiliaire d’exécution spéculative — speculative execution side channel —, la faille permet trois attaques : RIDL, Fallout et zombieload.
Pour les contrer, les développeurs du noyau Linux ont d’abord introduit le paramètre de démarrage mds. Enfin, parce que, bon, ça commence à bien faire, la version 5.2 amène le paramètre mitigation qui permettra à terme d’activer ou non une bien belle collection de contre‑mesures processeur.
Cette fois, Intel remet le couvert avec la technologie TSX Asynchronous Abort (TAA), liée aux extensions TSX déjà abordées lors de faille Lazy‑FPU. Souvenez‐vous, il est noté à propos de ces extensions que « ce serait presque étudié pour ». L’exploitation de la faille repose aussi sur des registres dits « micro‑architecturaux ». De fait, les correctifs du mois de mai n’ont corrigé qu’une partie du problème…
La contre‑mesure repose sur le détournement d’une instruction obsolète, ou annexe, pour nettoyer les registres concernés par la faille. Ceci implique une mise à jour du microcode et du système, ce dernier devant appeler à point nommé cette instruction. En cas d’annulation de transaction TSX, les écritures effectuées au cours de la transaction sont annulées et les registres restaurés. Mais, lorsqu’une annulation en cours est asynchrone, une opération load peut encore se terminer et lire ces registres micro‐architecturaux pour les faire passer à la branche exécutée de manière spéculative.
Sous Linux, le paramètre d’amorçage tsx_async_abort=off|full a été ajouté pour gérer les contre‑mesures. La directive tsx=off|on|auto autorisera au non les extensions TSX. Vous pouvez combiner ces deux variables.
Ce n’est pas tout, une autre faille Jump Conditional Code Erratum, toujours liée à cette complexité micro‐architecturale, est annoncée. Une série d’instructions appelées micro‑ops, est mise en cache (structure DSB) et décodée en dehors de sa chaîne de traitement. Seulement l’une de ces instructions (JCC) peut provoquer un comportement indéfini lorsqu’elle est mal alignée.
La contre‑mesure consiste à éviter que toute instruction de saut conditionnel soit mise en cache DSB, d’où de nombreux retours sur le traitement standard et une perte de performance significative. Évidemment, Intel recommande donc de mettre à jour les microcodes de ses processeurs via les outils de vos distributions et systèmes d’exploitation :
Sans lien avec MDS, la faille Machine check error erratum permet à un attaquant de redémarrer ou d’arrêter un système. Une instruction fetch dans certaines conditions va lever par erreur l’exception machine check et provoquer un redémarrage ou un arrêt.
Les cartes graphiques ne sont pas épargnées, via notamment le mode d’exécution en ring‑2, System Management Mode (SMM), qui permet d’interrompre l’exécution normale du système d’exploitation pour passer la main à un micrologiciel. On peut se demander si cette faille n’est pas liée au correctif du SDK SGX, qui a un mode d’exécution réservé dans lequel aucun autre mode (ou ring) n’est censé pouvoir accéder.
Sous Linux, vous trouverez dans /sys/devices/system/cpu/vulnerabilities/ une liste des failles. Il suffit de lancer un cat sur chaque fichier de ce répertoire pour obtenir le statut de votre processeur.
Sous FreeBSD, la clef hw.mds_disable active les contre‑mesures.
Micrologiciels (firmwares)
Ces failles matérielles ont pour effet de bord de se propager aux micrologiciels fournis par Intel pour vos machines, qui vont permettre d’exploiter au mieux ces failles. Et ce, d’autant plus que le code, fermé, de ces derniers, ne semble pas d’une qualité très élevée, malgré des noms pompeux, avec trust dedans.
On trouve beaucoup d’erreurs de codage, telles que :
-
insufficient session validation ;
-
insufficient access control ;
-
insufficient input validation ;
-
unhandled exception ;
-
stack overflow ;
-
out of bound read ;
-
memory corruption ;
-
heap corruption.
Intel® Trusted Execution Engine (TXE), Technologie Intel® Platform Trust
Elles sont supposées être les garantes du sytème d’exploitation et des environnements que vous allez faire tourner, basées sur un module TPM, troué lui aussi. Au menu, élévation de privilèges et fuite de données.
Malheureusement, on commence à trouver aussi ce genre de micrologiciels (trusted) sur des architectures non‑Intel, comme des systèmes monopuces (SoC) ARM.
Intel® Active Management Technology (AMT)
Un outil d’assistance et de maintenance à distance, qui permet une élévation de privilèges. À distance.
Il repose principalement sur l’Intel Management Engine (IME). Autrefois planqué dans le hostbridge, aujourd’hui dans le PCH. Pensez à le désactiver, si vous le pouvez.
Un outil qui repose sur plein de petits modules :
-
Intel® Converged Security and Manageability Engine ;
-
Intel® Securing and Management Engine ;
-
Intel® Server Platform Services.
Baseboard Management Controller
C’est un autre outil de maintenance à distance que l’on retrouve sur les serveurs et modules de calcul, dont une version libre existe. Pour celui‑ci, il y a un risque critique d’élévation de privilèges, déni de service et de fuite de données, via le réseau.
UEFI
Une vulnérabilité a été annoncée sur la famille Xeon.
Périphériques
Les microcodes des cartes réseau Intel Ethernet 700 Series permettent une évaluation de privilèges, déni de service et fuite de données.
Logiciel
Le SDK Intel® SGX (Software Guard Extensions) permet une élévation de privilèges.
Télécharger la dernière version.
[N. D. M. : le site 01.org appartient bien à Intel.]
Bilan
Intel affirme que la majorité de ces failles a été trouvée « en interne ». Pourtant, on trouve nombre de chercheurs indépendants remerciés dans les CVE. En fait, une bonne partie des failles découvertes dans les microcodes me semble sortie d’un logiciel d’analyse de code.
Malheureusement, une partie de ces contre‑mesures et mises à jour, surtout celles concernant les micrologiciels, devront être apportées par les constructeurs, les fournisseurs de cartes. Les machines dédiées au marché des particuliers risquent d’attendre longtemps…
Greg Kroah‑Hartman a conclu lors de l’Open Source Summit Europe : vous allez devoir choisir entre la sécurité et la performance. Car, désactiver l’hyperthreading, les extensions TSX, retirer des µops du cache induit une importante perte de performance.
Notez que si la désactivation de l’hyperthreading rend plus difficile la plupart de ces attaques, cela ne suffit généralement pas. De même, la distribution aléatoire de l’espace d’adressage noyau (KASLR) n’empêche pas l’exploitation de ces failles.
