« UEFIcanhazbufferoverflow », c’est le nom tordu de la faille qui vient d’être découverte dans les processeurs Intel. Cette vulnérabilité, qui touche le micrologiciel UEFI, pourrait permettre à des pirates d’exécuter du code malveillant sur les appareils concernés. Sa correction s’annonce complexe pour les fabricants.
Quand on en est a pouvoir modifier des variables dans l’uefi d’un pc je pense que l’on peut dire que le pc est compromis effectivement, le seul avantage au final c’est un camouflage hors vision antivirus.
Ici la meilleur parade semble d’être de ne pas laisser trainer son pc sans surveillance, et en entreprise de limiter les capacité de boot, l’acces au stockage usb et évidement l’acces au bios (vu que cela parle de " local attacker" dans la source)
« cela concerne des puces sorties entre 2016 et 2023. »
Donc mon bon vieux I7 6700 Skylake du Q3 2015 passe entre les gouttes ?
C’est dans les vieux pots qu’on fait les meilleures…patati… patata
Non, ton vieux PC est vulnérable à une faille matériel bien plus facile à mettre en place. Donc contrairement à ce que tu sembles penser, il est bel et bien vulnérable.
Il s’agit de la récupération des clés de chiffrement en branchant un oscilloscope sur le TPM présent sur la CM.
Des milliards de dollars, des milliers d’ingénieurs, tout bien compartimenté ; des heures et des gigas de vhdl, de framework confidentiels pour bien cacher une faille, dur d’être innocent avec autant de moyens
Pour sécuriser le PC et empêcher l’exploitation de cette faille, il faut mettre en place un code PIN au démarrage du PC.
Bon et alors !!! Pas de quoi en faire tout un pâté. Inutile d’alarmer inutilement les consommateurs avec des suppositions. Avec des « pourrait » et des « si » on peut refaire le Monde. Si ma tante en avait je ne serai peut-être pas là.
Merci Melina pour cet article. C’est agréable de voir de plus en plus de cybersecurity dans clubic.
Quelques précisions :
- la faille est coté phœnix, pas coté Intel. Le lien entre les deux est que le code touche est pour les bios Intel
- la correction n’est pas très compliqué. Les failles uefi sont relativement communes. Il est bien plus facile de patcher du microcode que de contrer une erreur de conception comme spectre
- pour les commentaires, il n’est pas nécessaire d’avoir un accès local. Pourvoir modifier les variables uefi suffit. C’est une élévation de privilèges de la session utilisateur (avec droits sur les variables) vers le hardware. Ça permet de bypasser les boundaries inter sessions et inter machines virtuelles. Ou de faire de la persistance.
Dire que le secure boot devait soi-disant tout sécuriser ! En fait, c’était surtout une vacherie à la sauce Microsoft pour essayer d’empêcher l’installation d’un autre OS.
Rien à voir, s’il y a une faille dans l’UEFI donc justement dans celui qui contrôle le Secure Boot, ben forcément le Secure Boot n’y peut rien…
Et non, ça ne servait pas à compliquer l’installation d’autres OS : non seulement on peut mettre d’autres OS avec le Secure Boot activé, mais en plus dans les préconisations de Microsoft aux constructeurs concernant le Secure Boot il était mentionné qu’il doit être désactivable via les options de l’UEFI…