Alors tout ton post parle de recompilation alors que ça n'est pas du tout ce que je promeus ! Au contraire, utiliser des programmes libres utilisant toutes les instructions que tu veux, déjà compilés par ta distro, puisque (dans mon hypothèse) tu n'as pas à te soucier de problèmes de programmes qui ne seraient pas de confiance puisque tu n'utilises que des programmes libres de confiance (ceux de Debian).
Là le soucis n'est pas tant là confiance dans les logiciels installés que la confiance dans l'ensemble de l'environnement. On est dans un cas ou n'importe quel utilisateur qui arrive à faire s’exécuter n'importe quel programme, même dans un environnement ultra protégé (c'est à dire des droits limités, du SELinux, des cgroups et autre posix capabilities) peut aller lire le contenu du processus d'à coté, voire de la vm d'à coté si elle tourne sur le même processeur physique.
Pour Spectre 2 il y avait trois solutions : soit interdire à tes utilisateurs d’exécuter le moindre processus qui n'est pas certifié. (Donc pas de virtulisation, mais aussi pas de developpement Java, Erlang, Javascript, .Net et j'en passe). Pas évident en environnement professionnel.
Deuxièmement désactiver les options processeurs impactées au niveau du bios (quand c'était possible) ou recompiler l'ensemble des process tournants sur le système sans utiliser les optimisations à risque. Mais là forcément les perfs peuvent prendre cher dans certains cas.
Dernière solution : recompiler le noyau et tous les modules et processus privilégiés (anti-virus, firewall, pilote, tout ce qui utilise des DMA etc.) avec retpoline. Impact de perfs limité dans la majorité des cas, mais il faut bootstrapper tout le système coeur... Du fun quoi...
Après, une attaque « via des logiciels établis » est toujours possible
C'est pas une attaque via un logiciel existant dans lequel tu vas réussir à provoquer un comportement à risque, du moins pas dans le sens ou tu utilises PHP ou Bind pour executer du code avec les droits root. Tu peux forcer le CPU à dumper le contenu d'un bloc du L1 dans le L2 et le récupérer depuis un compte lambda.
je préfère me concentrer sur d'autres facteurs (avoir des machines bien à jour, bien configurées) que de psychoter sur un problème avec une probabilité d'arriver minimale.
Si un jour un crétin trouve un autre exploit de la faille et le met en ligne "pour rire", la probabilité que ça arrive deviendra maximale en quelques heures. On est littéralement à un script près d'avoir un utilisateur non privilégié qui peut dumper le cache L1 du processeur dans un fichier. Après on peut considérer que la probabilité qu'un tel script voit le jour est très faible, c'est un choix. Mais dans tout un tas d’environnements, notamment quand on offre des capacités à ses clients pour exécuter du code custom, c'est quand même un vrai gros risque.
[^] # Re: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par Kaane . En réponse au journal Nouvelle vulnérabilité pour les processeurs Intel : l’attaque CacheOut. Évalué à 4.
Là le soucis n'est pas tant là confiance dans les logiciels installés que la confiance dans l'ensemble de l'environnement. On est dans un cas ou n'importe quel utilisateur qui arrive à faire s’exécuter n'importe quel programme, même dans un environnement ultra protégé (c'est à dire des droits limités, du SELinux, des cgroups et autre posix capabilities) peut aller lire le contenu du processus d'à coté, voire de la vm d'à coté si elle tourne sur le même processeur physique.
Pour Spectre 2 il y avait trois solutions : soit interdire à tes utilisateurs d’exécuter le moindre processus qui n'est pas certifié. (Donc pas de virtulisation, mais aussi pas de developpement Java, Erlang, Javascript, .Net et j'en passe). Pas évident en environnement professionnel.
Deuxièmement désactiver les options processeurs impactées au niveau du bios (quand c'était possible) ou recompiler l'ensemble des process tournants sur le système sans utiliser les optimisations à risque. Mais là forcément les perfs peuvent prendre cher dans certains cas.
Dernière solution : recompiler le noyau et tous les modules et processus privilégiés (anti-virus, firewall, pilote, tout ce qui utilise des DMA etc.) avec retpoline. Impact de perfs limité dans la majorité des cas, mais il faut bootstrapper tout le système coeur... Du fun quoi...
C'est pas une attaque via un logiciel existant dans lequel tu vas réussir à provoquer un comportement à risque, du moins pas dans le sens ou tu utilises PHP ou Bind pour executer du code avec les droits root. Tu peux forcer le CPU à dumper le contenu d'un bloc du L1 dans le L2 et le récupérer depuis un compte lambda.
Si un jour un crétin trouve un autre exploit de la faille et le met en ligne "pour rire", la probabilité que ça arrive deviendra maximale en quelques heures. On est littéralement à un script près d'avoir un utilisateur non privilégié qui peut dumper le cache L1 du processeur dans un fichier. Après on peut considérer que la probabilité qu'un tel script voit le jour est très faible, c'est un choix. Mais dans tout un tas d’environnements, notamment quand on offre des capacités à ses clients pour exécuter du code custom, c'est quand même un vrai gros risque.