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 /bootfind /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 NeoX . É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 Florent . Évalué à 1.
C'est le cas non ?
dd if=/dev/sda bs=512 count=4096 | sha512sumOn 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-----luksAvec 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 delio . Évalué à 1.
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.
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 Zylabon . Évalué à 2.
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 Florent . Évalué à 1.
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.
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.