Primo, c'est un rootkit UEFI. Techniquement, c'est pas du BIOS, mais je vais pas jouer sur les mots. Mais surtout, la présence d'un rootkit possible est assez séparé de la question de la sécurité.
Pour utiliser ce genre de rootkit, tu as 2 choix.
Le premier, c'est un accès physique avec assez de temps pour installer le rootkit. C'est assez spécifique, mais si tu peux reflasher la puce mémoire, alors on peut supposer que tu peux installer le rootkit en question, et c'est indépendant du code du BIOS/UEFI et de sa sensibilité vu qu'il va se faire écraser et/ou augmenter.
eg., ce qui est sensible, c'est pas le BIOS/UEFI mais la carte mère (et le fait d'accepter des BIOS/UEFI non signé, ou signé par des clés qu'on peut trouver facilement, etc)
L'autre choix, c'est de flasher depuis l'OS. La, on peut avoir une discussion sur savoir si c'est plus sur de ne pas pouvoir remplacer un logiciel (car en read-only dans une ROM) sachant que ça implique aussi de ne pas pouvoir le patcher en cas de pépin. Mais pareil, le fait de flasher ou pas n'est pas aussi important que le fait que ça implique d'avoir une faille avant pour exécuter du code ce qui rends à mon sens l'userspace plus sensible.
Si j'ai uniquement une faille userspace, je peux te voler des infos, avec ou sans faille dans le BIOS/UEFI. Si j'ai qu'une faille UEFI/BIOS, bah, je suis quand même bien coincé en tant qu'attaquant.
La, l'exemple parle d'une attaque sur le firmware, mais à part la persistance qui se fait au niveau de l'UEFI, il n'y a rien de spécial qui va montrer que l'UEFI est le plus sensible. Si je fais un implant qui persiste via cron, est ce que crond devient "le plus sensible en terme de sécurité" ?
Même si le code de l'UEFI était blindé à mort avec 5 signatures incassables et 0 failles de sécurité, ç'est un implant qui est transmis par le fabricant. Tu peux pas faire grand chose contre ça, et ça marcherais aussi bien avec un pilote d'imprimante ou n'importe quoi d'autre.
Du coup, je suis pas sur de piger exactement le point que tu cherches à démontrer par ton lacunaire Ahem.
La, par exemple, je pense que le fabricant est plus sensible en terme de sécurité que le BIOS d'une machine, surtout parce que le fabriquant s'est fait poutré et que ce genre d'attaques arrivent, alors que des attaques sur le BIOS (ou l'UEFI), y en a 0.
Et un implant, c'est pas une attaque. Pas plus que mettre un rootkit serait une attaque sur le kernel, sur une distro ou sur le projet GNU.
Mais je suis d'accord sur la 2eme partie de ton commentaire.
En effet, tout le monde peut se tromper, mais je pense tu n'avais pas besoin d'en fait la démonstration par l'exemple avec ton début de commentaire.
[^] # Re: Fauxpensource et libriste en carton ?
Posté par Misc (site web personnel) . En réponse au lien Windows prohibé chez Gitlab !!!. Évalué à 2.
Primo, c'est un rootkit UEFI. Techniquement, c'est pas du BIOS, mais je vais pas jouer sur les mots. Mais surtout, la présence d'un rootkit possible est assez séparé de la question de la sécurité.
Pour utiliser ce genre de rootkit, tu as 2 choix.
Le premier, c'est un accès physique avec assez de temps pour installer le rootkit. C'est assez spécifique, mais si tu peux reflasher la puce mémoire, alors on peut supposer que tu peux installer le rootkit en question, et c'est indépendant du code du BIOS/UEFI et de sa sensibilité vu qu'il va se faire écraser et/ou augmenter.
eg., ce qui est sensible, c'est pas le BIOS/UEFI mais la carte mère (et le fait d'accepter des BIOS/UEFI non signé, ou signé par des clés qu'on peut trouver facilement, etc)
L'autre choix, c'est de flasher depuis l'OS. La, on peut avoir une discussion sur savoir si c'est plus sur de ne pas pouvoir remplacer un logiciel (car en read-only dans une ROM) sachant que ça implique aussi de ne pas pouvoir le patcher en cas de pépin. Mais pareil, le fait de flasher ou pas n'est pas aussi important que le fait que ça implique d'avoir une faille avant pour exécuter du code ce qui rends à mon sens l'userspace plus sensible.
Si j'ai uniquement une faille userspace, je peux te voler des infos, avec ou sans faille dans le BIOS/UEFI. Si j'ai qu'une faille UEFI/BIOS, bah, je suis quand même bien coincé en tant qu'attaquant.
La, l'exemple parle d'une attaque sur le firmware, mais à part la persistance qui se fait au niveau de l'UEFI, il n'y a rien de spécial qui va montrer que l'UEFI est le plus sensible. Si je fais un implant qui persiste via cron, est ce que crond devient "le plus sensible en terme de sécurité" ?
Même si le code de l'UEFI était blindé à mort avec 5 signatures incassables et 0 failles de sécurité, ç'est un implant qui est transmis par le fabricant. Tu peux pas faire grand chose contre ça, et ça marcherais aussi bien avec un pilote d'imprimante ou n'importe quoi d'autre.
Du coup, je suis pas sur de piger exactement le point que tu cherches à démontrer par ton lacunaire Ahem.
La, par exemple, je pense que le fabricant est plus sensible en terme de sécurité que le BIOS d'une machine, surtout parce que le fabriquant s'est fait poutré et que ce genre d'attaques arrivent, alors que des attaques sur le BIOS (ou l'UEFI), y en a 0.
Et un implant, c'est pas une attaque. Pas plus que mettre un rootkit serait une attaque sur le kernel, sur une distro ou sur le projet GNU.
Mais je suis d'accord sur la 2eme partie de ton commentaire.
En effet, tout le monde peut se tromper, mais je pense tu n'avais pas besoin d'en fait la démonstration par l'exemple avec ton début de commentaire.