Vulnérabilité de security GRUB2: reculer 28 fois: quels sont mes risques? Que devrais-je faire?
Il y a eu des rapports hier sur une nouvelle vulnérabilité de security:
- Lucian Constantin (2015-12-16). Une vulnérabilité dans le chargeur de démarrage populaire met en danger les ordinateurs Linux verrouillés . CSO en ligne.
- Pasortingck Allan (2015-12-16). Vous pouvez vous casser dans un système Linux en appuyant sur 28 fois. Voici comment le réparer . Hacker de vie.
- Swati Khandelwal (2015-12-16). Vous pouvez pirater dans un ordinateur Linux en appuyant simplement sur 'Backspace' 28 fois. . Les nouvelles de Hacker.
Les rapports disent tous que la vulnérabilité peut «permettre à un pirate d'installer des logiciels malveillants sur un système Linux verrouillé», «contourner toute la security d'une machine Linux verrouillée» et «contourner la protection par mot de passe sur votre ordinateur» . La vulnérabilité proprement dite est CVE-2015-8370 et a été écrite par un de ses découvreurs:
- Hector Marco et Ismael Ripoll (2015-12-14). Retour à 28: Authentification Grub2 0-Day . CVE-2015-8370.
Alors que les reportages sont hyperboliques et parlent de vulnérabilités sous Linux, le rapport de Marco et Ripoll est très technique pour que le non-programmeur absorbe, descendant dans le code source coloré ou GRUB2 et des strings de caractères de 40 caractères première page.
Je suis juste un "gars de security" ordinaire. Je garde mes applications et mes systèmes d'exploitation à jour avec les correctifs de security. Donc, sans l'hyperbole des reportages, et sans me déconcerter avec le code source et les hexddumps:
- Y a-t-il des mesures immédiates que je devrais prendre? Y a-t-il des mesures immédiates que je peux prendre?
- Quel est le risque pour mes systèmes personnels à la maison?
- Quel est le risque pour mes servers au travail? Si quelqu'un avait un access IPKVM ou OIT, par exemple, cela pourrait-il être exploité?
Ce genre de problème est inévitable. Ou, du less, c'est doublement probable . Quand les gens parlent de grub comme une nécessité, ils évoquent presque toujours des choses comme garder l'image du kernel sur un disque chiffré, ou des keys SecureBoot. Ils disent généralement que vous ne pourriez pas gérer ces choses autrement, que vous avez besoin d'un chargeur intermédiaire dans votre process de démarrage pour l'interface entre votre firmware et votre kernel.
Bien qu'il soit vrai que grub peut lire de nombreux types de filesystems différents, dispose d'un support réseau embedded et prend en charge les shims EFI SecureBoot, je pense que c'est un peu étrange que d'autres considèrent que ce sont de bonnes choses. Je les considère comme redondantes, trop compliquées et une seconde surface d'attaque.
Il était une fois nécessaire – même si cela a toujours été stupide – il était une fois nécessaire que le firmware appelle un binary de chargeur intermédiaire qui pourrait alors appeler le kernel. Il était nécessaire parce que le BIOS était trop vieux et stupide pour comprendre n'importe quel kernel système pratiquement utilisable que vous pourriez autrement le charger. L'idée d'un bootloader était juste une solution de contournement pour le firmware stupide en premier lieu.
Pour les machines typiques fabriquées à tout moment au cours des cinq dernières années environ, ce n'est plus le cas, bien que pratiquement toutes les dissortingbutions Linux le fassent par défaut. Le BIOS est mort – le standard (U) EFI l'a pratiquement remplacé complètement, et un firmware de cette variété n'a aucun problème invoquant directement le kernel de votre système – aucun bootloader nécessaire. En fait, si vous deviez comstackr dans votre initramfs, vous pourriez simplement nommer votre image kernel /boot/EFI/BOOT/BOOTX64.efi et votre ordinateur l' /boot/EFI/BOOT/BOOTX64.efi automatiquement .
Et tout ce qui concerne grub étant nécessaire pour gérer les filesystems cryptés et etc, c'est de la foutaise, simple et clair. À mon avis, less il y a de programmes capables de déverrouiller un disque verrouillé, plus ce locking est sécurisé. Donc, si vous avez gardé votre kernel sur un système de files simple – tel que le FAT très basique requirejs pour votre partition système EFI – alors l'EFI (U) pourrait le charger et le kernel déverrouillerait votre disque, bien sûr.
Vous pouvez également auto-signer le kernel de votre système et installer ces keys sur la NVRAM du micrologiciel afin que le micrologiciel valide directement le certificate de votre image du kernel à chaque démarrage.
Vous pouvez le faire sans grub – vous pouvez le faire plus facilement sans grub .
Donc, si vous voulez vous soucier de la complexité supplémentaire et de la surface d'attaque supplémentaire d'un second kernel OS, vous devez mettre à jour votre grub chainloader immédiatement. Si vous ne le faites pas, vous devriez le désinstaller.
Les réponses sur le site de security de l'information semblent minimiser la vulnérabilité liée à ce problème. Ils disent que ce n'est pas un problème parce que vous avez besoin d'un access physique à la machine pour l'exploiter et que si vous l'avez, la machine est à vous.
Je ne suis pas d'accord. Si quelqu'un peut marcher jusqu'à votre ordinateur, allumez-le, contournez votre mot de passe de menu de démarrage en appuyant 28 fois sur l'espace de return, puis accédez à vos disques via la command line de grub et à votre réseau via votre MAC, alors c'est un problème.
Comment démarrer Linux sans un bootloader . Non testé par moi personnellement, mais pourrait être un bon sharepoint départ.