Encore une autre entrée dans la catégorie “pourquoi nous ne pouvons pas avoir de belles choses”, Retbleed a été annoncé cette semaine, comme une autre vulnérabilité d’exécution spéculative. Celui-ci est atténué dans le matériel pour AMD Zen 3 et Intel Generation 9 et versions ultérieures. Pour les appareils plus anciens, les performances d’atténuation sont assez douloureuses. Qu’est-ce qui le différencie exactement des faiblesses précédentes, et pourquoi les atténuations précédentes ne couvraient-elles pas ce problème ?
Spectre V2 abuse de la prédiction de branche indirecte d’un processeur pour déclencher l’exécution spéculative de code qui ne devrait pas être exécuté dans un contexte donné. Même si le processeur finit par rattraper son retard et annuler la fausse exécution, il reste encore des empreintes digitales dans le contenu du cache. L’idée est que la lecture de ces empreintes digitales divulgue des données réelles auxquelles le processus de l’attaquant ne devrait pas du tout avoir accès. La solution dans le noyau Linux est la « retpoline », un mot-valise de « retour » et « trampoline ». Ce gadget remplace un jmp instruction avec une certaine configuration, et enfin un ret appeler à la place. Cela semblait être une solution peu coûteuse au problème.
Ce que Retbleed apporte à la table est une méthode pour empoisonner également l’exécution spéculative de ces instructions de retour. Leur article complet (PDF) décrit la technique, qui se résume à manipuler un processeur pour utiliser le tampon cible de branche (BTB) vulnérable au lieu du tampon de pile de retour (RSB) plus sûr. Sur les systèmes Intel vulnérables, cela signifie remplir le RSB avec suffisamment de données pour faire sortir le retour cible réel du tampon. Lorsque la série de sauts et de retours se déroule, le retour final utilise en fait le BTB car le RSB s’est vidé ou sous-estimé. Les systèmes AMD vulnérables semblent simplement toujours utiliser un BTB pour prédire les retours, ce qui rend l’exploitation beaucoup plus facile là-bas.
Les machines Windows utilisent une politique d’atténuation plus agressive, Indirect Branch Restricted Speculation (IBRS), qui semble atténuer complètement ce problème particulier, bien qu’il puisse y en avoir d’autres dans les prochaines semaines. Sous Linux, l’atténuation de retpoline est finalement remplacée par IBRS par défaut, ce qui entraîne l’impact sur les performances décrit ci-dessus.
Si vous utilisez l’un des processeurs concernés, vous pouvez utiliser certains paramètres du noyau pour contrôler les mesures d’atténuation mises en place. retbleed=off utilise l’atténuation de retpoline existante si nécessaire, mais ne dégrade pas davantage les performances, au détriment de la vulnérabilité à cette attaque. le défaut, retbleed=auto utilisera toutes les mesures d’atténuation pour rendre la machine aussi sûre que possible sans désactiver le multithreading simultané (SMT). et enfin retbleed=auto,nosmt désactivera en fait SMT sur les quelques modèles qui en ont techniquement besoin pour des atténuations complètes. Ce n’est pas défini par défaut, car il est encore plus paralysant pour les performances de la machine.
Le NIST passe au post-quantique
Alors que la crypto-apocalypse quantique n’a pas encore été réalisée, les diverses agences responsables des normes s’efforcent de garder une longueur d’avance en parrainant la recherche, puis en sélectionnant des schémas de cryptographie à utiliser comme normes de nouvelle génération. Dans cette veine, le NIST a publié une mise à jour de son processus de normalisation de la cryptographie post-quantique. La grande nouvelle ici est que quelques algorithmes ont été sélectionnés. Falcon, SPHINCS, CRISTAUX-Kyber et CRISTAUX-Dilithium. Il semble définitivement y avoir des geeks de science-fiction parmi les participants, d’après les noms.
CRYSTALS-Kyber est un mécanisme d’encapsulation de clé (KEM), une méthode pour partager une clé privée en utilisant uniquement des messages envoyés publiquement, à la Diffie-Hellman. CRYSTALS-Dilithium et les autres sont des schémas de signature, utiles pour vérifier les données. Nous attendons avec impatience que ces normes soient déployées dans les différents projets et applications que nous utilisons quotidiennement.
PyPI, 2FA et un développeur grincheux
Afin d’éviter les problèmes de sécurité, le référentiel PyPI a déployé une politique de sécurité qui oblige les mainteneurs de projets critiques à utiliser l’authentification à deux facteurs pour leurs comptes, et envoie même des clés matérielles gratuites. Le critère d’inclusion est d’être dans le top 1% des téléchargements pendant six mois. Il y a une question pertinente dans la FAQ sur la page : “Un projet peut-il se désabonner ou devenir non critique de quelque manière que ce soit ?” La réponse officielle indique: “Non, une fois que le projet a été désigné comme critique, il conserve cette désignation indéfiniment.” Au moins un développeur a découvert une solution de contournement, avec des résultats intéressants.
sympa, je viens de supprimer le paquet atomicwrites, puis j’ai téléchargé une nouvelle version. maintenant ce n’est plus un projet critique
– Markus Unterwaditzer (@untitaker) 8 juillet 2022
Relisez cela. L’un des packages les plus populaires sur PyPI a été supprimé et une nouvelle version a été téléchargée. Chaque projet et chaque dépendance pointant vers une version épinglée de atomicwrites a eu leur processus d’installation cassé. Bien sûr, il n’est plus marqué comme un package critique et l’auteur n’a pas besoin d’utiliser 2FA, mais jusqu’à ce que les administrateurs PyPI interviennent et corrigent le problème, un groupe de développeurs du monde entier étaient dans le pétrin. Le développeur principal, [unitaker] a depuis décidé de laisser le paquet tel quel, mais de le déprécier.
Faites-nous savoir ce que vous pensez, est-ce que PyPI a tort, obligeant les développeurs bénévoles à utiliser 2FA, ou le problème de la chaîne d’approvisionnement est-il suffisamment important pour que cela en vaille la peine ?
Joli garcon
Et si vous voulez savoir pourquoi PyPi s’inquiète pour la sécurité – il y a eu une activité étrange repérée sur NPM, à hauteur de plus d’un millier de paquets malveillants téléchargés en masse sur le service. Tout est sous des utilisateurs nommés au hasard, et cela semble être une variante d’eazyminer, qui est un simple package d’extraction de pièces pour Node.js. Le nom vient de la configuration de ce mineur, qui envoie à un pool nommé “mignon”.
Cela semble avoir été un test d’un outil automatisé pour créer des utilisateurs et télécharger des packages, se préparant peut-être à une exécution plus malveillante. Ou il pourrait s’agir d’un collègue chercheur, qui prévoit de publier un rapport sur la façon d’automatiser la création d’utilisateurs. Quoi qu’il en soit, il existe même un site disponible pour suivre l’activité du bot, nommé de manière appropriée cuteboi.info. (Je sais, cela ressemble à une URL terrifiante. Je vous promets que c’est sans danger pour le travail.)
Bits et octets
Nous suivons l’histoire de la mémoire OpenSSL AVX512 depuis plusieurs semaines maintenant. Il y a enfin une épingle dans ce problème, car OpenSSL 3.0.5 a été publié, contenant le correctif. À notre connaissance, il n’existe pas d’exploit RCE complet pour ce bogue. Ainsi, bien que cela puisse être un problème très grave lorsqu’il est considéré isolément, celui-ci aura presque certainement un impact réel qui arrondira à zéro.
QNAP a publié un avis concernant une nouvelle attaque de ransomware contre ses appareils NAS, et l’action recommandée se résume à “Ne pas exposer SMB à Internet”. L’attaque semble être une attaque par dictionnaire contre les services exposés. Une mise à jour est disponible pour renforcer le service, et QNAP recommande d’utiliser un VPN au lieu d’exposer les services sur le net.
Microsoft essaie enfin de laisser le passé derrière lui et de bloquer les macros par défaut dans les documents bureautiques. Office a un flux logique pour déterminer s’il faut exécuter des macros, en commençant par si le document est explicitement approuvé, si les macros sont signées par un éditeur de confiance, etc. La nouveauté est le comportement par défaut lorsque le flux tombe à la fin du graphique. Dans le passé, il échouait à s’ouvrir, exécutant les macros par défaut. Le nouveau comportement échoue en toute sécurité, refusant de courir. La chose la plus folle à ce sujet est qu’ils ont reçu suffisamment de recul pour que ce changement ait été annulé pour le moment, vous pouvez donc toujours faire passer les virus de macro. Faites la fête comme en 1999, Melissa !
Et si ce n’est pas assez de folie en matière de sécurité, découvrez l’histoire d’Aerojet Recketdyne qui a embauché [Brian Markus] en tant que « directeur principal de la cybersécurité, de la conformité et des contrôles ». Rocketdyne falsifiait des rapports, comme rapportant qu’ils avaient un certain équipement de sécurité, alors qu’il était encore dans la boîte. Tout cela dans le but d’obtenir des contrats gouvernementaux. [Markus] a refusé de signer un document indiquant que l’entreprise s’était conformée aux règles appropriées. Il a refusé de signer et a été licencié en conséquence. Après plusieurs années de querelles juridiques, les parties se sont entendues, avec [Markus] recevant plus de 2,6 millions de dollars de la société, et le gouvernement américain en recevant le double. Parfois, apparemment, il vaut la peine de faire ce qu’il faut. (Via Heise.de).