Meltdown et Spectre : tout savoir sur les failles historiques des processeurs

Nicolas Furno |

Nous évoquions hier une faille de sécurité dénichée dans tous les processeurs Intel sortis depuis une dizaine d’années. Il s'agissait déjà d'une faille énorme, mais ce n’était en réalité qu’une petite partie du problème. Puisque l’information est sortie dans la nature plus tôt que prévue, les acteurs impliqués ont fini par communiquer, ce qui nous permet de connaître plus précisément l’étendue des dégâts.

Il n’y a pas une faille, mais deux assez similaires. Si la première, surnommée « Meltdown » pour l’occasion, ne concerne bien que les processeurs Intel, la deuxième, nommée « Spectre », touche cette fois tous les processeurs en circulation depuis plusieurs décennies. Tous, y compris les processeurs ARM que l’on retrouve dans les smartphones et tablettes.

Meltdown et Spectre… deux failles pour le prix d’une ! Image de base : Christiaan Colen (CC BY-SA 2.0) Cliquer pour agrandir

Faut-il paniquer pour autant ? À quoi ces failles peuvent-elles conduire ? Quand seront-elles corrigées ? Qui était au courant ?

Pour faire le point sur ce que l’on sait à l’heure où nous écrivons ces lignes, voici une série de questions et de réponses. Nous les mettrons à jour si de nouvelles informations sont disponibles.

Sommaire

Quelles sont les différences entre Meltdown et Spectre ?

C’est la révélation majeure de ces dernières heures : il n’y a pas une faille de sécurité liée aux processeurs, mais deux. Et si la première ne concerne « que » les processeurs Intel et surtout est en passe d’être corrigée rapidement, la seconde est beaucoup plus large et n’a aucun correctif pour le moment.

Sans trop entrer dans les détails techniques, car ils deviennent vite très (très) compliqués, les deux failles sont à la fois similaires et assez différentes. Voici rapidement pourquoi.

Différences entre Meltdown et Spectre : résumé créé par @MaliciaRogue (CC-BY-SA 4.0). Cliquer pour agrandir

Meltdown – C’est la faille de sécurité que nous évoquions hier. Elle ne concerne que les processeurs Intel, mais elle est encore plus large que ce que l’on croyait, puisque des ordinateurs sortis en 1995 sont aussi touchés (voir aussi). C’est la plus dangereuse des deux, puisqu’elle est très facile à exploiter et qu’elle permet d’accéder à des informations normalement inaccessibles, notamment les mots de passe saisis par l’utilisateur.

Meltdown permet de lire la mémoire réservée au noyau, ce qui est théoriquement impossible. Les processeurs gèrent deux types de mémoire différents : d’un côté, celle du kernel qui est directement exploitée par le processeur ; de l’autre, celle du user qui est écrite et lue par le système d’exploitation. La mémoire kernel n’est jamais chiffrée et c’est pour cette raison qu’elle doit être inaccessible à tout le système, à l'exception du processeur lui-même.

La faille offre un accès à l’intégralité de la mémoire kernel en détournant une technique d’optimisation des processeurs nommée out-of-order execution. Son principe de base est simple à comprendre : plutôt que d’exécuter des commandes les unes après les autres, le processeur lance plusieurs commandes en spéculant sur la commande qui sera nécessaire après l’actuelle. L’idée est donc de prédire ce qui sera nécessaire après le travail en cours, pour gagner du temps dans l’ensemble.

Cette technique est nommée prédiction de branche et elle est présente dans tous les processeurs modernes. Ce n’est pas elle qui pose problème en soi pour cette faille, mais Meltdown exploite spécifiquement l’implémentation d’Intel. S’ils vous intéressent, les détails techniques sont disponibles dans ce document, mais contentons-nous ici d’indiquer que le processeur devrait bloquer une requête d’accès à la mémoire kernel et ne le fait pas.

Ces trois lignes de code en langage machine sont au cœur de l’attaque Meltdown (source). Cliquer pour agrandir

C’est ce qui permet, lors d’une attaque, de récupérer l’intégralité de la mémoire cache du processeur, y compris ce qui devrait être inaccessible depuis le système d’exploitation. Au passage, cette faille ne repose pas sur les particularités d’un système plutôt que d’un autre, tous les ordinateurs qui utilisent un processeur touché sont concernés. C’est pourquoi tous les systèmes d’exploitation doivent être mis à jour (voir aussi).

Spectre – Cette faille de sécurité est nettement plus large, puisqu’elle concerne tous les processeurs actuellement sur le marché et tous ceux qui sont disponibles depuis les années 1990. Son vecteur d’attaque est similaire à Meltdown, cette dernière étant une variante spécifique à Intel de la même idée de base. Ainsi, ces failles exploitent les techniques mises en place pour accélérer les processeurs, notamment l’exécution out-of-order, la prédiction de branche et l’exécution spéculative.

Pour rappel, ces techniques consistent à lancer plusieurs commandes en même temps plutôt que les unes à la suite des autres, et à deviner ce qui sera nécessaire après une commande en spéculant. L’attaque Spectre consiste à forcer le processeur à exécuter une commande qu’il ne ferait pas en temps normal et à récupérer ensuite des informations qui ne devraient pas être disponibles.

Contrairement à la première faille de sécurité, Spectre ne permet pas d’accéder à l’intégralité de la mémoire kernel, celle-ci reste protégée. En revanche, un logiciel malveillant peut accéder aux données d’un autre logiciel sans autorisation. En guise de démonstration, les chercheurs ont développé un script JavaScript qui peut accéder à toutes les données du navigateur qui l’exécute.

L’autre différence majeure entre les deux variantes, c’est qu’autant Meltdown a une solution relativement simple à mettre en place, autant Spectre n’a pas à ce jour de solution claire. En particulier, la mise à jour proposée pour contrer Meltdown ne bloque absolument pas cette seconde faille. Des garde-fous sont en train d’être développés côté logiciel, mais la véritable solution sera matérielle et pour le moment, on ne sait pas comment faire exactement (voir aussi).

Vous trouverez de plus amples informations techniques dans ce document et dans ce billet de Google.

Suis-je concerné par ces failles ?

Oui. Tout le monde est touché par au moins l’une des deux failles de sécurité dévoilées publiquement en ce début du mois de janvier.

La faille spécifique à Intel, Meltdown, est en passe d’être comblée ou elle le sera très prochainement, par voie logicielle. Si vous utilisez un Mac et la dernière version de High Sierra, vous êtes en fait déjà protégé, tandis que Microsoft a commencé à déployer des correctifs de son côté (voir aussi).

Malheureusement, la faille Spectre est beaucoup plus complexe, elle concerne tous les processeurs en circulation et elle n’a pas encore de solution claire, même si des garde-fous sont en train d’être mis en place (voir aussi).

Quels sont les processeurs touchés ?

Meltdown – À quelques rares exceptions près, tous les ordinateurs équipés d’un processeur Intel sont concernés par la faille. Tous les modèles sortis à partir de 1995 intègrent la prédiction de branches qui est utilisée par la faille de sécurité (voir aussi). Cela concerne les Pentium Pro et les modèles suivants, jusqu’à aujourd’hui.

Le Pentium Pro d’Intel, premier modèle qui semble concerné par la faille. Image Mark Sze (CC BY-NC-ND 2.0). Cliquer pour agrandir

Les chercheurs en sécurité ont testé plusieurs familles de processeurs jusqu’en 2011 et ont réussi à exploiter Meltdown sur tous les modèles, à deux exceptions. Les Intel Itanium et Intel Atom sortis avant 2013 ne sont pas touchés. Autant dire que la grande majorité des processeurs le sont, y compris tous ceux qui sont intégrés aux Mac Intel.

AMD a indiqué officiellement que ses processeurs n’étaient pas touché par la faille Meltdown. Néanmoins, le chercheur en sécurité de Google qui l’a découverte (voir aussi) maintient le contraire.

Spectre – la majorité des processeurs actuels sont touchés par cette faille. Autant ceux d’Intel que ceux d’AMD avec l’architecture x86, que les processeurs basés sur l’architecture ARM utilisés dans les smartphones et tablettes entre autres, que les processeurs spécialisés utilisés dans des contextes professionnels. En particulier, les POWER8, POWER9 et System Z d’IBM sont concernés.

Puisqu’il s’agit d’un défaut matériel présents sur tous les processeurs depuis plusieurs décennies, Spectre peut sévir sur tous les ordinateurs actuellement en circulation et même quelques modèles anciens. Pour l’anecdote, les Mac équipés de PowerPC G4 sont eux aussi touchés par cette faille de sécurité. À l’époque, Steve Jobs mettait en avant les gains de performance obtenus par cette nouveauté, tout en soulignant qu’il ne savait pas exactement ce que le processeur faisait…

Les processeurs Intel utilisés par Apple dans les Mac sont tous touchés par Spectre. Pour les appareils iOS, tvOS et watchOS, c’est plus compliqué. ARM a dévoilé une liste de générations touchées, ce qui permet de savoir au minimum que ces modèles sont concernés :

  • iPhone : 4, 4s, 5 et 5C ;
  • iPad : 1ere, 2e et 3e générations ;
  • Apple TV : 2e et 3e générations ;
  • iPod Touch : 4e et 5e générations.

Qu’en est-il pour les modèles les plus récents ? Ils ne sont pas concernés a priori par la faille Spectre, mais ce n’est pas une garantie absolue. Apple n’a pas encore communiqué officiellement sur le sujet, donc peut-être que l’on aura des surprises.

Mise à jour — Apple a fini par communiquer sur les deux failles. macOS 10.13.2, iOS 11.2 et tvOS 11.2 contiennent déjà des correctifs, quant à l'Apple Watch, elle n'est pas concernée. Pas un mot en revanche concernant d'anciens systèmes.

Comment ces failles peuvent-elles être exploitées ?

Meltdown — Son exploitation est très spectaculaire. Un logiciel ou un script malveillant peut accéder à des informations qui devraient être inaccessibles depuis le système d’exploitation et qui ne sont pas chiffrées. Un script en JavaScript exécuté par un navigateur peut suffire à exploiter cette faille et accéder aux données, ce qui la rend d’autant plus dangereuse.

En guise d’exemple, voici ce que les chercheurs en sécurité autrichiens montrent sur leur site. Ce script exploite la faille de sécurité pour lire les données kernel et les affiche en code machine, puis les traduit en lettres et chiffres.

Comme on peut le constater, on trouve de tout dans ce qui est lisible sur la droite. Autant du texte sans grande importance, que des noms d’utilisateur et des mots de passe, en clair. Tout y est.

Il faut bien comprendre que ces informations ne devraient jamais être accessibles par le système d’exploitation et donc l’utilisateur. La faille ne concerne pas la lecture des données, mais bien leur accès.

Outre un accès brut à toutes les données du noyau, la faille Meltdown pourrait servir à récupérer seulement une information, à condition de connaître son emplacement. Cette démonstration réalisée sur Ubuntu prouve qu’un logiciel malveillant pourrait récupérer un mot de passe pendant sa saisie.

Spectre — Cette faille est plus complexe à exploiter puisqu’elle n'est pas générique et doit donc être adaptée à chaque appareil. Néanmoins, cela ne veut pas dire qu’elle ne peut pas être exploitée et elle peut faire des dommages importants, notamment dans deux domaines.

Les spécialistes qui ont trouvé la faille ont réalisé deux démonstrations. La première est un script en JavaScript exécuté par un navigateur qui offre un accès à toutes les informations collectées par le navigateur. En théorie, un script n’a accès qu’à un onglet pour des raisons évidentes de sécurité. La faille permet de lire le reste des données, par exemple votre historique complet.

Le deuxième exemple est plus grave encore, puisqu’il concerne cette fois les machines virtuelles, très utilisées dans les serveurs. Cette fois, un code exécuté depuis un serveur virtuel (VPS) par exemple, peut accéder aux données de l’hôte, c’est-à-dire du serveur physique sur lequel il est exécuté. Et ainsi, il peut accéder aux données des autres serveurs virtuels.

Ce cas de figure est extrêmement courant, c’est même la base du fonctionnement des services de « cloud », comme AWS d’Amazon, Azure de Microsoft ou encore un hébergeur comme DigitalOcean. Une attaque pourrait cibler un serveur physique et accéder ensuite à tous les serveurs virtuels qu’il gère, ce qui serait un énorme problème de sécurité.

Ces failles ont-elles été exploitées ?

A priori non, mais on ne peut pas s’en assurer.

Depuis la première découverte des deux failles au printemps dernier (voir aussi), l’information a été tenue secrète de manière très efficace. Seuls les chercheurs en sécurité à l’origine des découvertes, les constructeurs de processeurs et les acteurs qui écrivent les noyaux des systèmes d’exploitation étaient au courant avant la publication du début du mois de janvier.

Le mot important ici, c’est a priori. Étant donné que ces failles concernent tous les processeurs et qu’elles peuvent être exploitées depuis plusieurs années, il est tout à fait possible qu’un acteur malveillant les ait exploitées avant leur découverte en 2017. On ne peut pas l’affirmer, mais on ne peut pas non plus prouver que ce n’est pas le cas. Intel a indiqué lors d’une conférence consacrée au sujet que les failles n’ont pas été exploitées, mais ce n’est pas une garantie absolue.

Pour ne rien arranger, ces deux failles de sécurité ne laissent aucune trace visible. En exploitant une faiblesse matérielle des processeurs, elles sont invisibles au système d’exploitation qui n’essaiera pas de les bloquer et qui ne les considérera même pas comme problématiques. Résultat, il n’est pas possible de savoir après les faits qu’une exploitation a eu lieu.

Quand et comment ces failles seront-elles corrigées ?

Meltdown – Cette faille est en passe d’être déjà comblée par voie logicielle. Tous les systèmes d’exploitation ont profité des derniers mois pour créer les correctifs nécessaires et ils vont tous les déployer, si ce n’est pas déjà le cas.

La correction passe par une isolation plus stricte entre la mémoire user utilisée par le système d’exploitation et la mémoire kernel qui devrait être réservée au processeur et inaccessible par l’utilisateur (voir aussi). Pour faire simple, le principe est de séparer complètement les deux types de mémoire, de sorte que seul le processeur puisse accéder à la mémoire kernel. En contrepartie, cette solution aura un impact variable sur les performances (voir aussi).

Voici la situation à l’heure actuelle pour les systèmes d’exploitation :

  • macOS :
    • la dernière version de High Sierra, macOS 10.13.2, corrige la majorité du problème ;
    • la dernière version de Sierra est encore touchée par la faille a priori ;
    • Apple devrait compléter sa correction avec la prochaine mise à jour, macOS 10.13.3 ;
    • en revanche, on ne sait pas encore ce qu’il en est pour les anciennes versions de macOS, Sierra, El Capitan et antérieures ;
  • Windows :
    • Windows 10 a été mis à jour automatiquement ou se mettra à jour automatiquement dans les prochains jours (mais certains anti-virus peuvent alors cesser de fonctionner) ;
    • Microsoft a mis à jour Windows 7 et 8 et ces versions seront disponibles dans les prochains jours ;
    • un programme existe pour vérifier qu’un ordinateur est bien protégé : SpecuCheck ;
  • Linux :
    • le noyau 4.15, la version la plus récente actuellement en train d’être finalisée, corrige la faille de sécurité ;
    • il existe des patchs pour les anciennes versions du noyau, toujours très utilisées.

À terme, Intel devra mettre à jour ses processeurs pour combler complètement l’origine de cette faille, qui est matérielle avant tout. Quand est-ce que l’on peut compter sur une mise à jour ? La prochaine génération de processeurs sera-t-elle corrigée ?

La communication d’Intel en la matière laisse à désirer pour le moment et on ne sait rien à ce stade. À tel point que Linus Torvald, créateur du noyau Linux, s’impatiente publiquement et glisse que l’on devrait peut-être s’intéresser de plus près aux processeurs ARM64 pour remplacer Intel…

[MàJ 5/01/2018 08h03] : Intel a annoncé une mise à jour pour 90 % des processeurs sortis depuis cinq ans. On ne sait pas encore comment elle sera déployée, toutefois.

Spectre – Cette faille est beaucoup plus difficile à combler et il n’y a pour le moment aucune solution claire. Les processeurs devront être mis à jour physiquement, mais même dans ce cas, il n’y a pas à ce jour de solution simple. Et comme cela concerne tous les processeurs commercialisés depuis plusieurs années, on risque d’entendre parler longtemps de cette faille (d’où son nom, d’ailleurs).

Néanmoins, en attendant les corrections matérielles, des solutions temporaires sont en train d’être mises en place pour limiter l’impact de la faille dans les logiciels. C’est le cas notamment pour les navigateurs internet, qui vont renforcer leur sécurité pour éviter un accès à toutes leurs données depuis un script.

Google, Mozilla et Microsoft ont annoncé des mesures similaires pour leurs navigateurs. Pour le moment, elles consistent surtout à désactiver certaines fonctions et réduire les performances d’autres fonctions, pour limiter ou bloquer totalement l’attaque. Ce ne sont pas des solutions de long terme toutefois et tous les acteurs vont améliorer leurs corrections au fil des prochains mois.

Voici l’état actuel des navigateurs :

  • Safari : une mise à jour sera proposée prochainement pour combler la faille de sécurité, avec quelques légères baisses de performances à prévoir ;
  • Chrome :
    • Chrome 64, mise à jour prévue pour le 23 janvier, comblera complètement la faille de sécurité ;
    • Chrome 63, la version actuelle, contient une option qui isole complètement chaque site, ce qui bloque Spectre (à activer en saisissant chrome://flags/#enable-site-per-process dans le champ de recherche) ; attention, Google prévient que c’est une option expérimentale ;
Isoler strictement les sites dans Chrome permet d’éviter les attaques Spectre. Cliquer pour agrandir
  • Firefox : une mise à jour va être déployée pour bloquer l’attaque dans Firefox 57, d’abord en limitant artificiellement certaines fonctions, avant de trouver une solution complète ;
  • Microsoft : des mises à jour sont disponibles pour Edge et Internet Explorer 11, là encore avec des solutions temporaires pour bloquer l’attaque.

L’autre cas de figure pour cette faille, ce sont les machines virtuelles, très courantes sur les serveurs (voir aussi). Là aussi, les différents acteurs concernés ont pris les devants pour corriger la faille, mais cela peut avoir un impact sur les performances (voir aussi) et sur la disponibilité des sites. Un redémarrage des serveurs est souvent nécessaire pour appliquer la correction.

Voici l’état actuel de quelques hébergeurs :

  • AWS : les serveurs physiques sont en train d’être corrigés automatiquement, mais chaque instance devra être mise à jour avec la commande yum update kernel ;
  • Azure : les serveurs physiques sont en train d’être mis à jour, les machines virtuelles devront être redémarrées et les clients concernés seront informés par mail ;
  • DigitalOcean : l’hébergeur travaille avec Intel pour déterminer la meilleure solution ;
  • Google Cloud Platform : les serveurs physiques sont déjà protégés, les instances virtuelles devront être mises à jour ;
  • OVH : le correctif est en cours de déploiement, les serveurs dédiés devront être mis à jour par les clients et les services de cloud seront mis à jour d’ici la fin de la semaine ;
  • Scaleway : les serveurs physiques ont été mis à jour, les clients devront installer le nouveau noyau sur leurs machines (explications).

Au passage, Intel semble avoir ralenti le déploiement de correctifs pour plusieurs acteurs, qui se plaignent plus ou moins ouvertement de l’embargo imposé par le fondeur. La situation devrait en tout cas évoluer beaucoup plus rapidement maintenant que les failles sont publiques.

Va-t-on perdre en performances ?

Meltdown — Oui, mais ça ne sera pas visible sur les ordinateurs grand public.

En moyenne, la correction de la faille devrait avoir un impact de l’ordre de 5 % sur les performances. Ce n’est pas une mesure scientifique, mais macOS 10.13.2 contient déjà une partie du correctif et cette version n’est pas notablement moins rapide que la précédente.

Dans certains cas toutefois, la baisse des performances sera beaucoup plus importante. C’est le cas en particulier sur les serveurs, ou encore dans certaines tâches assez pointues. Certains utilisateurs l’ont déjà constaté, surtout du côté des serveurs où le correctif a souvent été déjà déployé, par exemple chez AWS, le service de cloud d’Amazon.

Sur ce petit serveur virtuel Amazon, la différence de performances est très sensible après mise en place du correctif. L’utilisation du processeur passe de 2 % environ à 6 à 8 % après mise à jour. Cliquer pour agrandir

AWS avait commencé à mettre à jour son infrastructure en décembre, alors que la faille n’était pas publique. On note à ce moment-là des plaintes de la part de clients ne comprennant pas pourquoi leur serveur est nettement moins performant, sans raison apparente.

On sait rétrospectivement que Meltdown est la cause de cette baisse. Pour ceux qui ont des besoins exigeants, la perte de performances pourrait ainsi avoir un coût très visible, mais on manque encore de recul sur ce point.

Spectre – Pour le moment, les problèmes de performance sont uniquement liés aux solutions temporaires mises en place pour contrer la faille. C’est notamment le cas pour les navigateurs, qui ont comblé la faille en réduisant leurs capacités (voir aussi).

Cette situation intermédiaire ne devrait toutefois pas durer et une meilleure solution sera trouvée à terme.

Qui était au courant ?

Le premier à avoir découvert ces deux failles est Jann Horn, un employé de Google qui travaille dans le cadre de Project Zero, une équipe de sécurité spécialisée dans la découverte de nouvelles failles. Suite à sa découverte, il a averti Intel, AMD et ARM dès le mois de juin 2017.

En parallèle, deux équipes de chercheurs en sécurité différentes ont découvert la faille surnommée Meltdown, celle qui concerne les processeurs Intel (voir aussi). D’un côté, une équipe de l’université de Graz en Autriche et de l’autre deux chercheurs de l’entreprise allemande Cyberus Technology sont tombés sur cette faille.

En parallèle encore, le chercheur en sécurité indépendant Paul Kocher, aidé par plusieurs universitaires et d’autres spécialistes, a découvert la faille Spectre, celle qui concerne tous les processeurs (voir aussi).

Cliquer pour agrandir

Aussi étonnant que cela puisse paraître, ces recherches ont été menées dans un premier temps indépendamment les unes des autres, mais quasiment en même temps. C’est a priori une simple coïncidence, même s’il semble que les informations ont circulé entre chercheurs de sécurité pour avancer plus rapidement.

Outre les spécialistes qui ont trouvé les failles, Intel, AMD et ARM sont au courant depuis le mois de juin. Et puisque la solution passe par les systèmes d’exploitation (voir aussi), les principaux acteurs dans ce domaine (Microsoft, Apple et les développeurs du noyau Linux) ont aussi été mis au courant.

Naturellement, il ne s’agit là que de la liste connue. La grosse question qui reste en suspens, c’est bien de savoir si des tiers étaient au courant en amont, n’avaient rien communiqué et utilisaient déjà les failles de sécurité pour leur compte. Puisque l’exploitation peut être effectuée sans laisser de traces (voir aussi), il n’y a malheureusement aucun moyen de s’assurer que les failles n’ont jamais servi.

À qui profite le crime ?

Face à cette faille historique d’une telle ampleur, il est facile de penser à une porte dérobée installée volontairement par la NSA, ou un autre acteur. La théorie du complot ne résiste toutefois pas longtemps à l’épreuve des faits.

Tout d’abord, ces deux failles de sécurité ne sont pas des lignes de code intégrées à un moment donné. Ce sont des failles de sécurité physiques, c'est-à-dire qu’il s’agit à la base d’un défaut de conception des processeurs. Cela ne retire rien à l’hypothèse d’une porte dérobée, sauf que la chronologie incite à chercher une autre explication.

Le siège de la NSA (Image Wikimedia) Cliquer pour agrandir

Il faut rappeler en effet que cette faille peut être exploitée sur des processeurs vieux de plus de vingt ans (voir aussi). Peut-on sérieusement imaginer qu’une porte dérobée ait été installée à cette époque sur tous les processeurs, et ensuite maintenue sur toutes les générations suivantes et même sur des gammes entières de processeurs qui n’existaient pas dans les années 1990 ? Cela paraît peu plausible, d’autant que l’on a une autre explication : ce qui apparaît aujourd'hui comme un défaut de conception était en fait un compromis jugé acceptable à l’époque.

Toutes les technologies exploitées par Meltdown et Spectre, que ce soit l’exécution out-of-order, la prédiction de branche ou encore l’exécution spéculative (voir aussi), ont été ajoutées aux processeurs pour améliorer leurs performances. Les gains ont été indéniables lors de leur ajout et les considérations techniques de sécurité n’étaient pas du tout au programme sur le moment.

La véritable critique que l’on peut formuler contre l’industrie dans son ensemble, c’est d’avoir utilisé ces techniques d’optimisation pendant plus de vingt ans sans les avoir remises en cause. Maintenant que ces failles sont connues, les constructeurs de processeur n’auront plus le choix et ils devront optimiser leurs futurs produits avec la sécurité en tête.

avatar CrashMidnick | 

C'est un beau bazar quand même...
Merci Macg pour le récapitulatif !

avatar android3665 | 

Ça ferme le bien le clapet a tous ceux qui pensait que les processeurs ARM etait sans

aucun danger ni defauts

avatar nykk | 

Je suis peut-être parano, mais qui nous dit que ces "failles" n'ont pas été voulues par la NSA ? Est-ce possible que ces lignes de code aient été introduites sur demande ou en douce et que ce ne soit pas des accidents ?

avatar bidibout | 

@nykk

Bon bin voilà je ne suis pas le seul à m’interroger.

avatar Ali Ibn Bachir Le Gros | 

Ces failles n'ont pas besoin d'avoir été voulues par la NSA. La complexité des processeurs est en train de devenir ingérable et ce genre de failles inévitable.

J'ai suivi une conférence donnée par un chercheur à propos des bugs des processeurs Intel et de la manière dont on pouvait les exploiter. Les processeurs sont truffés de bugs, tous ne permettent pas d'en tirer grand-chose, mais ce qui arrive aujourd'hui a été prédit par plusieurs chercheurs.

Par contre, il est tout à fait possible que la NSA ait opportunément exploité ces failles et que nous ne le sachions pas.

avatar C1rc3@0rc | 

@Ali Ibn Bachir ...

Que ces backdoor soient le fruit du hasard et pas d'une volonté des agences d'espionnages qui ont un controle total sur tout le materiel electronique mis sur le marché en AmeriqueS et dans la zone OTAN... mais bien sur.

De plus on a les memes backdoor dans au moins 3 architectures de processeurs radicalement differentes...

L'article explique assez clairement ou se situe le probleme: la gestion de la memoire a travers le systeme de branchement predictif et les pipeline.

On sait depuis le debut de la mise en oeuvre de ce systeme qu'il ouvre la voie a des failles et permet des violations du flux de données (c'est son principe intrinseque!!!). Des le depart il a ete necessaire de securiser l'acces a la memoire impliquée...

On sait aussi que ce systeme est tres specifique a l'architecture du processeur qui l'utiise. Il a ete massivement necessaire pour maintenir en vie l'architecture CISC (celle d'Intel avec le x86, donc les pentium et les Core) et qu'il est encore plus necessaire pour les versions multicore.

Les raisons d'implementer ce systeme dans un processeur CISC(x86) et un processeur RISC(ARM, Power) sont differentes et les methodes divergent...

Partant de la, quelle est la probabilité que la meme backdoor existe a l'identique dans des architectures aussi differentes, voire opposées, que sont les x86, les ARM ou les POWER.

Si on veut faire le parallèle, il faudrait que sur des moteurs de voiture électriques et le moteur d'un avion de chasse on ait une faille totalement similaire...

De plus l'erreur n'est pas sur la realisation dans le fonctionnement, mais bien une absence, un defaut, de sécurisation effective sur une zone qui est connue pour être très vulnérable!!!

On rajoute a cela que, pour reprendre ton propos, le probleme s'opere a un niveau qui est hors de portée et de contrôle du développeur, que ce soit celui de l'application ou de l'OS.

On le voit surtout avec les x86, mais aujourd'hui un developpeur n'a aucun controle sur la façon dont le processeur va au final executer le programme, pire encore, il ne peut pas savoir sur quel core il va s'executer et ne peut en aucun cas s'assurer de l'exlusivité de la memoire ou des unités de traitements qui vont etre mis en oeuvre.
En fait le programmeur, surtout avec le x86, s'adresse a une machine virtuelle qui masque le processus de realisation reel.

Ça veut dire, in fine, que si le developpeur ne peut pas savoir comment va etre executer son code, il ne peut ni l'optimiser, ni le proteger.
Par contre, celui qui a acces au niveau interne du processeur, lui peut au contraire savoir exactement ce que fait le programme et quelles sont ses donnees... comment imaginer a partir de la que cette autoroute a l'espionnage ne soit pas prioritairement garantie a travers les generations de processeurs par les militaires et les agences d'espionnage...

Pour rappel, encore une fois aucun matériel électronique en occident ne peut être commercialisé sans l'aval des agences d’espionnage US et les militaires...

avatar Bigdidou | 

@C1rc3@0rc

« on a les memes backdoor dans au moins 3 architectures de processeurs radicalement differentes... »
C’est vrai que c’est perturbant.

Perturbant aussi qu’on comprennent pas bien officiellement pourquoi ces faille qui correspondent au fait que le processeur ne fonctionne pas comme prévu est aussi perturbant.

J’ai quand même du croire à une faille volontaire, exploitable, certes par la CIA/NSA & Co, mais aussi par n’importe quelle agence, et maintenant n’importe quel terroriste.

Ceci étant, ce n’est pas la première fois que les agences américaines arment volontairement ou pas inconséquences des ennemis mortels par la suite.

Je ne sais pas.
C’est perturbant, en tout cas.

avatar Bigemul | 

La NSA n'a probablement pas fait ça. Sinon, ils n'auraient pas eu besoin de leurs programmes de surveillance de masse et auraient réglé tous les soucis bien plus rapidement.

avatar Orus | 

La NSA n'est pas la seule agence de renseignement aux USA.

avatar PomBreizh | 

@C1rc3@0rc

"Si on veut faire le parallèle, il faudrait que sur des moteurs de voiture électriques et le moteur d'un avion de chasse on ait une faille totalement similaire..."

Ah, les comparaisons si pratiques... on fait vraiment ce que l’on veut et surtout n’importe quoi.
Pourquoi pas un éclair au chocolat et un financier, tant qu’on y est?

avatar MKln | 

@nykk

Comme expliqué dans l’article ce ne sont pas des lignes de code qui sont en cause mais un problème matériel, « physique »...
Après, qui a exploité ces failles, impossible à savoir..

avatar PomBreizh | 

@MKln @Sangoke

En fait pas si vrai que ça, car le design d’un processeur passe par des lignes de code.

avatar sangoke | 

@nykk

Si t’avais lu l’article en entier tu aurais une réponse et tu saurais que ce ne sont pas des lignes de codes qui ont été ajoutées..

avatar C1rc3@0rc | 

Et que le niveau d'exploitation assure un acces a... n'importe qui. On peut le faire a partir d'un script Javascript...

Si on rajoute a cela l'exploitation des autres "caracteristiques" des x86, nottament les fonctions "d'adminstration" des Xeon, on se retrouve avec un systeme qui peut etre totalement "monitoré" a distance.

Bon c'st quand meme pas du niveau du scriptkiddy, mais ça demande pas non plus des competences de niveau d'ingenierie militaire... mais qui peut le plus peut aussi le moins.

avatar bidibout | 

Si ça se trouve tout ça est voulu afin de nous espionner depuis des lustres sauf que cela aura finit par être découvert ! Bref on ne sait sans doute pas tout de toute façon.

avatar nykk | 

L'une des problématiques des libristes est de pouvoir faire confiance au matériel à 100 %, donc avoir des pilotes libres de bout en bout, y compris pour les CPU, et ça n'a jamais existé, sauf, me semble-t-il, des processeurs Cyrix il y a bien 25 ans — mais ma mémoire n'est plus très sûre — justement pour éviter ce genre de problèmes. J'avais lu des articles sur ce genre de craintes sur certains sites spécialisés il y a des années. D'où mon interrogation…

avatar C1rc3@0rc | 

Le fat d'avoir des pilotes libres ne suffit pas, il faut en plus que l'architecture materielle soit "opensource".

Ici on est sur un defaut de securisation dans le fonctionnement interne. Alors que cette zone est connue pour etre tres sensible et que les demonstrations de son exploitation ont ete plethore, y compris a travers des machines virtuelles...

Il n'est donc pas question de problemes de realisation logiciels, mais bien d'une absence de fonction necessaire au niveau du materiel.
Et ça sans audit, meme avec du code libre et du materiel opensource, c'est pas possible de la savoir...

Ce qu'il se passe aujourd'hui c'est que grace au courage de Snowden et Julian Assange, on sait qu'il faut aller chercher a tous les niveaux parce que les gens qui sont derrieres l'espionnage d'etat a grande echelle et systematiques sont des scelerats sans foi ni loi qui ne reculent devant rien et que leur ennemi nº 1 c'est le citoyen et la democratie.

avatar Lightman | 

@C1rc3@0rc

"Ce qu'il se passe aujourd'hui c'est que grace au courage de Snowden et Julian Assange, on sait qu'il faut aller chercher a tous les niveaux parce que les gens qui sont derrieres l'espionnage d'etat a grande echelle et systematiques sont des scelerats sans foi ni loi qui ne reculent devant rien et que leur ennemi nº 1 c'est le citoyen et la democratie."

C'est bien des gens comme toi qui ont suffisamment de recul pour s'apercevoir des multiples menaces qui entourent notre vie privée. Je suis complètement d'accord. Nous sommes dans un monde hostile.
Cependant, je ne partage pas l'avis des gens (dont le tien) qui pensent à une orchestration humaine de cela, dans ce cas présent en tout cas. Mon explication est un peu différente et bien trop longue pour être expliquée ici.
Quoi qu'il en soit, les techniques de branchement prédictif m'ont toujours dérangé depuis qu'elles ont été mises en place, à cause du trop grand flou qui entoure les résultats, de la confiance qu'on fait au processeur pour s'auto gérer, sans très bien maîtriser les implications.

Il est fort possible que les organismes à trois lettres aient découvert ses failles et les aient exploité avec beaucoup de joie. À défaut d'info il faut considérer cette possibilité.

avatar occam | 

Excellent travail. Bravo Nicolas et la rédaction.
J'aurais pu engranger quelques heures de sommeil cette nuit et attendre tranquillement votre récapitulatif.

avatar Madalvée | 

Merci pour ces explications. De toute façon la seule informatique vraiment sûre c'est l'informatique hors-ligne, et ce n'est pas nouveau.

avatar C1rc3@0rc | 

Meme pas.
L'informatique sure ce serait plutot dans cette definition hors alimentation.
Apres il reste le probleme des données stockées a "froid" qui sont accessibles par divers moyens, meme chiffrées...

Par contre, si on le veut, on peut tout a fait creer des systemes informatiques repondant a un niveau de securité suffisant. Si on a du materiel opensource audité, des OS qui respectent les principes de base et un chiffrement systematique des donnees au niveau de l'application, alors il ne reste que des cas extremes ou les risques persistent...
Mais bon, le travail des agences de renseignement US c'est d'abord et avant tout l'espionnage academique, industriel, commercial avant meme de fliquer le cityoen...

Quand on a compris que Boeing (et quelques autres gros du secteurs petro-chimique, pharma et agro-alimentaires) est le client le principal client de la CIA, on arrete de se poser des questions...

avatar ziggyspider | 

"Suis-je concerné par ces failles ?
Oui. Tout le monde est touché par au moins l’une des deux failles de sécurité dévoilées publiquement en ce début du mois de janvier."

L'iMac Pro a deux entrées pour les deux failles. Pas de bol, la puce ARM, là pour gérer la sécurité, ajoute la deuxième !

avatar dandu | 

Sur les processeurs, la liste est un peu fausse.

Chez Intel, le Pentium Pro date de 1995, mais en gros, c'est plutôt vers 1997 (Pentium II) que c'est vraiment courant.

Dans les PowerPC, c'est dès le 604, donc les G3 et G4 aussi

Dans les puces de l'iPhone, les seuls a priori pas touchés, c'est ceux avec un ARM11, donc les premières générations : iPhone/iPhone 3G/iPod touch 1/2

La liste d'ARM, elle implique les iPhone 3GS, 4 et 4S, les iPad 1/2/3 et les iPod Touch 3/4/5 mais pas les iPhone 5 et plus.

Après, y a de fortes chances que tous les design Apple depuis l'A6 (CPU maison) soient Out of Order et donc touchés.

En vrai, en informatique grand public moderne, il doit y avoir que les Raspberry Pi et une partie des smartphones Android bas de gammes qui pose pas de soucis.

avatar C1rc3@0rc | 

@dandu

«Après, y a de fortes chances que tous les design Apple depuis l'A6 (CPU maison) soient Out of Order et donc touchés.»

C'est pas le principe out-of-order qui est mis en cause (enfin si, mais c'est un autre probleme), mais sa realisation et ne fait de pas securiser la memoire. Cela depend donc de la realisation pas de la compatibilité avec le jeu d'instructions. Un processeur compatible avec le jeu d'instruction ARM peut tout a fait reposer sur une micro-architecture qui ne presente pas ces backdoor. Pour le x86 c'est plus problematique, Intel imposant bien plus de contraintes et etant en monopole quasi exclusif (AMD n'a de loin pas les meme libertés et independance qu'Apple par rapport a ARM)

Apres, il est clair que plus l'architecture est inefficace et multiplie les hauteur de pipeline et le nombre de core, plus il est tentant de gratter l'optimisation partout ou c'est possible et donc faire l'impasse sur la securisation de la memoire est plus probable...

Ce qui veut dire en clair que les risques de backdoor sont massifs dans un Xeon 10 Core que dans un Core i 2 core, et qu'un ARM 8 Core a un risque potentiel plus grand qu'un ARM 4 core...

avatar magic.ludovic | 

Il serait vraiment minable de la part d'Apple de ne pas corriger la faille pour Sierra, El Capitan et au moins jusqu'a Mavericks ...

Pages

CONNEXION UTILISATEUR