Il y a quelques jours, un rapport a été publié détaillant trois nouvelles vulnérabilités Spectre qui existent dans le cache micro-op de tous les processeurs modernes. Peu de temps après avoir écrit à ce sujet, Intel a tendu la main pour dire qu’ils ne pensaient pas que les nouvelles vulnérabilités étaient un gros problème. Leur déclaration officielle se lit comme suit: « Intel a examiné le rapport et a informé les chercheurs que les mesures d’atténuation existantes n’étaient pas contournées et que ce scénario est traité dans nos conseils de codage sécurisé. Les logiciels qui suivent nos conseils disposent déjà de protections contre les canaux accidentels, y compris le canal incident de cache UOP. Non de nouvelles mesures d’atténuation ou d’orientation sont nécessaires. « 

En termes simples, les logiciels mis à jour fonctionnant sur du matériel mis à jour devraient être insensibles aux nouveaux exploits. J’ai demandé au professeur assistant Ashish Venkat, qui dirige l’équipe qui a découvert les vulnérabilités et les exploits, son opinion sur la déclaration d’Intel. Il a admis qu’Intel avait raison sur l’efficacité de certaines contre-mesures existantes.

Intel guidage de codage sécurisé recommande trois principes pour empêcher les attaques par canal secondaire. Ils sont à mettre en œuvre par les programmeurs. S’ils sont tous utilisés correctement, ils protègent le logiciel de toutes les attaques de canal latéral traditionnelles et de la plupart des attaques de canal latéral d’exécution spéculative, y compris les attaques de cache micro-op.

Les principes:

• Assurez-vous que le runtime est indépendant des valeurs secrètes.
• Assurez-vous que les modèles d’accès au code sont indépendants des valeurs secrètes.
• Assurez-vous que les modèles d’accès aux données sont indépendants des valeurs secrètes.

En théorie, ils sont assez simples, mais Intel admet qu’ils peuvent être difficiles à mettre en œuvre dans la pratique. Les compilateurs avec des optimiseurs enfreindront parfois les principes pour rendre le code plus efficace, réintroduisant ainsi les vulnérabilités. Venkat et son équipe n’aiment pas qu’Intel compte sur les programmeurs pour mettre à jour leurs logiciels lorsque les vulnérabilités qu’ils ont découvertes sont en fin de compte un problème matériel.

«La programmation à temps constant est non seulement difficile en termes d’effort réel du programmeur, mais implique également une surcharge de haute performance et des défis de déploiement importants liés à la correction de tous les logiciels sensibles», a déclaré Venkat. « Le pourcentage de code qui est écrit en utilisant les principes du temps constant est en fait assez faible. S’en remettre à cela serait dangereux. C’est pourquoi nous devons encore sécuriser le matériel. »

La réticence des succursales gouvernementales, des banques et des grandes entreprises à mettre à jour leurs logiciels de bas niveau est infâme. Et ce sont ces types d’organisations pour lesquelles ces vulnérabilités présentent le plus de risques, car leurs serveurs exécutent de nombreux logiciels différents en même temps et parce qu’ils traitent un grand volume de secrets.

Quand j’ai parlé à Venkat, j’ai demandé si l’utilisateur moyen devait s’inquiéter, et il a dit qu’il «devrait continuer à se concentrer sur les endroits où il est le plus vulnérable, y compris les virus et les logiciels malveillants sur Internet». Mais pour sécuriser les services numériques que tout le monde utilise, les fournisseurs de matériel doivent mettre de nouveau l’accent sur la sécurité matérielle à l’avenir.

Crédit d’image: Ryan