URL: https://linuxfr.org/news/automne-saison-chaude-chez-intel Title: Automne, saison chaude chez Intel Authors: David Marec ZeroHeure, Ysabeau, Nils Ratusznik, M5oul et palm123 Date: 2019-11-25T23:53:17+01:00 License: CC by-sa Tags: intel, sécurité, security et zombieload Score: 8 Mardi 12 novembre, Arte diffuse le concert du Bal des enragés au Helfest 2019. L'attention du public ainsi détournée, Intel en profite pour lancer une vague de correctifs, [77 correctifs](https://www.intel.com/content/www/us/en/security-center/default.html), un grand nombre de CVE (des failles) y est dévoilé. Les failles concernent les processeurs eux-mêmes (et microcontrôleurs) et les micro-logiciels trop nombreux qui tournent dans vos cartes-mères. ---- [Blog Intel](https://blogs.intel.com/technology/2019/11/ipas-november-2019-intel-platform-update-ipu) [Annonce FreeBSD TSX](https://www.freebsd.org/security/advisories/FreeBSD-SA-19:26.mcu.asc) [Annonce FreeBSD MCEPSC](https://www.freebsd.org/security/advisories/FreeBSD-SA-19:25.mcepsc.asc) [Linux, vulnérabilités matérielles](https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/index.html) ---- # Matériel Fin mai 2019, Intel dévoilait [une faille](https://nvd.nist.gov/vuln/detail/CVE-2019-11091) autour de sa technologie [MDS](https://software.intel.com/security-software-guidance/insights/deep-dive-intel-analysis-microarchitectural-data-sampling). 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](https://mdsattacks.com/diagram.html) 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 la `speculative execution side channel`, la faille permet trois attaques: [RIDL, Fallout](https://mdsattacks.com/) et [zombieload](https://zombieloadattack.com). Pour les contrer, les développeurs du noyau Linux ont d’abord introduit le [paramètre de démarrage](https://www.kernel.org/doc/html/v5.2/admin-guide/kernel-parameters.html) `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 CPU. Cette fois, Intel remet le couvert avec la technologie [TSX Asynchronous Abort (TAA)](https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/tsx_async_abort.html), liée aux extensions TSX déjà abordées lors de faille [Lazy-FPU](https://linuxfr.org/news/faille-lazy-fpu-state-restore). 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 micro-code **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 de `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, la directive de boot `tsx_async_abort=off|full` a été ajoutée 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](https://www.intel.com/content/dam/support/us/en/documents/processors/mitigations-jump-conditional-code-erratum.pdf), 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 performances significative. Évidemment, Intel recommande donc de mettre à jour les microcodes de ses CPU via les outils de vos distributions et OS : * [devcpu-data](https://www.freshports.org/sysutils/devcpu-data/) pour FreeBSD ; * [intel-microcode](https://packages.debian.org/sid/intel-microcode), pour Debian ; * [microcode_ctl](https://pagure.io/microcode_ctl), pour la famille Red Hat (RHEL, Fedora, CentOS) ; * [intel-ucode](https://www.archlinux.org/packages/extra/any/intel-ucode/), pour Arch. Sans lien avec MDS, la faille [Machine check error erratum](https://software.intel.com/security-software-guidance/insights/deep-dive-machine-check-error-avoidance-page-size-change) 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](https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00260.html), via notamment le mode d’exécution en ring-2, System Management Mode (SMM), qui permet d’interrompre l’exécution normale de l’OS pour passer la main à un firmware. 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 CPU. Sous FreeBSD, la clef ` hw.mds_disable` active les contre-mesures. # Micro-logiciels (firmwares) Ces failles *matérielles* ont pour effet de bord de se propager aux micro-logiciels 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](https://www.youtube.com/watch?v=KPvnvYxhU3Q) dedans. On trouve beaucoup d’erreur de codage, tel 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 garants de l’OS et des environnements que vous allez faire tourner, basé sur un module TPM, [troué lui aussi](http://tpm.fail/). 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 SOCs 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'[IME](https://en.wikipedia.org/wiki/Intel_Management_Engine). 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](https://github.com/Intel-BMC/openbmc). Pour celui-ci, il y a un risque critique d’élévation de privilèges, dénis 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](https://www.intel.com/content/www/us/en/products/docs/network-io/ethernet/network-adapters/ethernet-700-series-video.html) permettent une évaluation de privilège, dénis de service et fuite de données. # Logiciel Le SDK Intel(R) SGX (Software Guard Extensions) permet une élévation de privilèges. Télécharger la [dernière version](https://01.org/intel-software-guard-extensions/downloads). [NdM : 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 micro-codes 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](https://events19.linuxfoundation.org/events/open-source-summit-europe-2019/) : 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 perte de performance élevée. Notez que si la désactivation de l’[hyperthreading](https://linuxfr.org/users/davidmarec/journaux/rumeurs-sur-l-hyper-threading-tlbleed) 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](https://fr.wikipedia.org/wiki/Address_space_layout_randomization)) n’empêche pas l’exploitation de ces failles.