Je ne veux pas écrire sur Spectre, mais je dois le faire: la semaine dernière, c'est de loin la nouvelle la plus importante. Les nouvelles options de vulnérabilité de Spectre, ainsi que les options originales, ont été présentées par des représentants de la communauté universitaire. Un chercheur du Massachusetts Institute of Technology Vladimir Kiryansky et l'expert indépendant Karl Waldspurger ont montré deux nouvelles modifications à Spectre, appelées Spectre 1.1 et Spectre 1.2 (
nouveauté ,
travail scientifique original), sans aucun logo ni logo.
Les différences importantes par rapport à la vulnérabilité Spectre d'origine dans les deux cas sont l'utilisation d'un mécanisme d'enregistrement spéculatif. Dans le cas de Spectre 1.1, une attaque vous permet théoriquement de provoquer un débordement de tampon (également spéculatif) et de lire la section "interdite" de la mémoire. Spectre 1.2 offre la possibilité d'écraser des informations en lecture seule et permet théoriquement à une attaque d'échappement sanbox de contourner les systèmes de protection matérielle. Pour la découverte de la vulnérabilité, les chercheurs ont reçu cent mille dollars dans le cadre du programme bug bugount d'Intel, et c'est aujourd'hui l'un des plus gros paiements. Les vulnérabilités sont affectées par les processeurs Intel, ARM et, probablement, les processeurs AMD.
Selon les auteurs, l'une des principales conclusions de l'étude est précisément le nouveau concept de «débordement de tampon spéculatif». Un débordement provoque une opération d'écriture - effectuée au bon moment et au bon endroit, elle sera inévitablement rejetée comme incorrecte, mais même avant cela, elle ouvre la possibilité de lire une zone mémoire à laquelle le processus d'attaque ne devrait pas avoir accès.
Une illustration clé de l'idée: la vérification des limites n'utilise pas une opération de lecture, comme dans le Spectre d'origine, mais avec une opération d'écriture.La liste des conditions dans lesquelles l'une des nouvelles vulnérabilités peut être implémentée dans la pratique prend presque plus de place qu'une description du mécanisme d'attaque. C'est la complexité des vulnérabilités matérielles de cette classe: trop doit coïncider pour que l'attaque réussisse. Mais lorsqu'une attaque se produit, dans le pire des cas, elle vous permet de voler des informations précieuses, souvent sans même avoir la possibilité, même après le mémoire, de comprendre ce qui s'est exactement passé. Plus important: les conditions Spectre 1.x peuvent être créées même lorsqu'une attaque Spectre 1.0 n'est pas possible.
Les chercheurs soutiennent qu'il n'y a aucun moyen de détecter des vulnérabilités comme Spectre 1.1 via des outils d'analyse de code ou de compilation. De plus, cette vulnérabilité peut être corrigée au niveau du fer. Il est également noté que la responsabilité de réduire les risques d'une attaque Spectre réussie incombe souvent aux développeurs de logiciels. Considérant qu'au cours des 30 années qui se sont écoulées depuis la première démonstration publique d'une attaque avec un débordement de tampon, les vulnérabilités des logiciels sont devenues beaucoup plus petites, les auteurs prédisent des attaques sur le mécanisme d'exécution spéculative de la «décennie» de code de pertinence.
Nonobstant ce qui précède, les auteurs estiment qu'une combinaison de logiciels et de matériel sécurisés avec les avantages de la protection contre les mécanismes d'exécution spéculatifs est théoriquement possible. Il reste à implémenter cela dans la pratique, que dans le cas d'une classe de vulnérabilités affectant le matériel, cela peut prendre des années ou des décennies. Je me demande si l'histoire de Spectre / Meltdown et de ses dérivés ne deviendra pas une étape vers un changement sérieux dans la pratique du développement de logiciels et de matériel?
Avis de non-responsabilité: les opinions exprimées dans ce recueil ne coïncident pas toujours avec la position officielle de Kaspersky Lab. Chers rédacteurs recommandent généralement de traiter toute opinion avec un scepticisme sain.