Les développeurs Linux sont en train de corriger une vulnérabilité de haute gravité qui, dans certains cas, permet l’installation de logiciels malveillants qui s’exécutent au niveau du micrologiciel, donnant aux infections l’accès aux parties les plus profondes d’un appareil où elles sont difficiles à détecter ou à supprimer. .
La vulnérabilité réside dans shim, qui dans le contexte de Linux est un petit composant qui s’exécute dans le micrologiciel au début du processus de démarrage, avant le démarrage du système d’exploitation. Plus précisément, la cale accompagnant pratiquement toutes les distributions Linux joue un rôle crucial dans le démarrage sécurisé, une protection intégrée à la plupart des appareils informatiques modernes pour garantir que chaque lien du processus de démarrage provient d’un fournisseur vérifié et fiable. L’exploitation réussie de la vulnérabilité permet aux attaquants de neutraliser ce mécanisme en exécutant un micrologiciel malveillant dès les premières étapes du processus de démarrage, avant que le micrologiciel de l’Unified Extensible Firmware Interface ne soit chargé et n’ait transféré le contrôle au système d’exploitation.
La vulnérabilité, identifiée comme CVE-2023-40547, est ce qu’on appelle un débordement de tampon, un bug de codage qui permet aux attaquants d’exécuter le code de leur choix. Il réside dans une partie du shim qui traite le démarrage à partir d’un serveur central sur un réseau utilisant le même HTTP que celui sur lequel le Web est basé. Les attaquants peuvent exploiter la vulnérabilité d’exécution de code dans divers scénarios, pratiquement tous à la suite d’une forme de compromission réussie du périphérique ciblé, du serveur ou du réseau à partir duquel le périphérique démarre.
« Un attaquant devrait être capable de contraindre un système à démarrer à partir de HTTP s’il ne le fait pas déjà, et soit en mesure d’exécuter le serveur HTTP en question ou le trafic MITM vers celui-ci », Matthew Garrett, développeur de sécurité et l’un des auteurs originaux du cale, a écrit dans une interview en ligne. « Un attaquant (physiquement présent ou ayant déjà compromis la racine du système) pourrait utiliser cela pour contourner le démarrage sécurisé (ajouter une nouvelle entrée de démarrage à un serveur qu’il contrôle, compromettre shim, exécuter du code arbitraire). »
En d’autres termes, ces scénarios incluent :
- Acquérir la capacité de compromettre un serveur ou d’en usurper l’identité pour cibler un périphérique déjà configuré pour démarrer via HTTP
- Avoir déjà un accès physique à un appareil ou obtenir un contrôle administratif en exploitant une vulnérabilité distincte.
Bien que ces obstacles soient considérables, ils ne sont en aucun cas impossibles, en particulier la possibilité de compromettre ou d’usurper l’identité d’un serveur qui communique avec des appareils via HTTP, qui n’est pas crypté et ne nécessite aucune authentification. Ces scénarios particuliers pourraient s’avérer utiles si un attaquant a déjà obtenu un certain niveau d’accès au sein d’un réseau et cherche à prendre le contrôle des appareils des utilisateurs finaux connectés. Ces scénarios sont cependant largement résolus si les serveurs utilisent HTTPS, la variante de HTTP qui nécessite qu’un serveur s’authentifie. Dans ce cas, l’attaquant devra d’abord falsifier le certificat numérique utilisé par le serveur pour prouver qu’il est autorisé à fournir un micrologiciel de démarrage aux appareils.
La possibilité d’accéder physiquement à un appareil est également difficile et est largement considérée comme un motif permettant de considérer qu’il est déjà compromis. Et bien sûr, il est déjà difficile d’obtenir un contrôle administratif en exploitant une vulnérabilité distincte du système d’exploitation et cela permet aux attaquants d’atteindre toutes sortes d’objectifs malveillants.