Forum Linux.général Checksum de la partition /boot

Posté par  . Licence CC By‑SA.
Étiquettes :
2
1
jan.
2014

Bonjour à tous,

J'ai actuellement Fedora et Archlinux installés en dual boot, les deux avec un chiffrement intégral ( tout sauf /boot ).
Or si un système est compromis, il pourrait alors modifier la partition /boot de l'autre système, en remplaçant par exemple le noyau ou l'initramfs par des équivalents vérolés (Evil Maid Attack), afin d'intercepter la passphrase du volume luks pour ensuite le déchiffrer et accéder aux données de l'autre système.

Quelle protection contre ça ?
On peut utiliser un checksum des premiers secteurs du disque, ce qui inclut la table de partition GPT et la BIOS Boot partition.
dd if=/dev/sda bs=512 count=4096 | sha512sum
Puis on fait un checksum des fichiers présent dans la partition /boot
find /boot -type f | sort | xargs sha512sum
On compare ensuite les checksums obtenus avec ceux stockés dans la partition chiffrée, et s'il y a une différence, on alerte l'utilisateur. Celui-ci décidera alors si cette différence est légitime, suite à une mise à jour du noyau par exemple, et dans ce cas on génère des nouveaux checksums.

Il semble que cela existe déjà sous Archlinux avec chkboot.

Qu'en pensez-vous ?

  • # que ca pourrait le faire "mais"...

    Posté par  . Évalué à 2.

    mais ton checksum se fait sur les premiers octets du disque et pas uniquement de la partition /boot

    du coup ta partition systeme (luks) est aussi partiellement passée dans le checksum
    or celle-ci change entre chaque demarrage du fait que certains fichiers ont changé dedans (/var/log, /home)

    tu devrais plutot faire ton checksum sur le MBR et sur la partition /boot

    • [^] # Re: que ca pourrait le faire "mais"...

      Posté par  . Évalué à 1.

      C'est le cas non ?

      dd if=/dev/sda bs=512 count=4096 | sha512sum
      On fait un checksum du MBR, de la table de partition GPT, et de la BIOS Boot partition.
      [ MBR-----table_de_partition_GPT-----BIOS_Boot_partition ] -----/boot-----luks
      Avec entre crochets ce qui est lu par dd et vérifié par sha512sum.
      Ces secteurs ne sont pas censés changer, ou alors dans le cas d'un grub-install ?

      Et le deuxième checksum est uniquement au niveau des fichiers.

      "A computer is like air conditioning – it becomes useless when you open Windows", Linus Torvalds

  • # pas suffisant

    Posté par  . Évalué à 1.

    Quelle protection contre ça ?

    Il n'y en a pas, en tout cas pas contre un attaquant déterminé.
    Si le boot est compromis et que donc il peut récuperer la passphrase, alors il peut aller changer le code qui vérifie le checksum.

    Qu'en pensez-vous ?

    J'en pense que ça peut donner une fausse impression de sécurité parce que ça pourra faire obstacle à certaines attaques, mais en théorie il ne faudrait pas compter sur une vérification de l'intégrité d'un système depuis l'intérieur de ce meme systeme.

    La bonne solution c'est le secure boot: le bios vérifie le boot qui lui vérifie le initrd qui vérifie le reste. Mais je ne sais pas si c'est facile à mettre en place.

    • [^] # Re: pas suffisant

      Posté par  . Évalué à 2.

      La bonne solution c'est le secure boot: le bios vérifie le boot qui lui vérifie le initrd qui vérifie le reste. Mais je ne sais pas si c'est facile à mettre en place.

      Les attaques contre le BIOS c'est pas ce qui manque… Je pense qu'un début de solution c'est de ne pas avoir d'x86.

      Mais bon, après ça dépend de quoi l'on souhaite de protéger.

      Please do not feed the trolls

    • [^] # Re: pas suffisant

      Posté par  . Évalué à 1.

      Si le boot est compromis et que donc il peut récuperer la passphrase, alors il peut aller changer le code qui vérifie le checksum.

      Supposons que le système B est compromis, il va alors infecter le boot du système A. Quand je vais démarrer le système A, je vais avoir une alerte que le checksum ne correspond pas. Dans ce cas, si je ne redémarre pas le système B, l'attaquant ne pourra pas récupérer ma passphrase ?
      Alors que si je n'ai pas d'alerte, l'attaquant à juste à attendre que je démarre le système B pour récupérer la passphrase, déchiffrer la partition depuis le système B et récupérer les données.

      La bonne solution c'est le secure boot

      Le secure boot fonctionne avec des CA racine non ? Si une autorité de "confiance" est piratée, ou que le bios accepte le CA de la NSA (au hasard), alors il suffit à l'attaquant de signer son initrd vérolé et le boot passera sans problème.

      "A computer is like air conditioning – it becomes useless when you open Windows", Linus Torvalds

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.