Linus Torvalds a toujours été vent debout contre les firmwares des PC. Car ce sont des bouts de code critiques et qu'il est impossible de mettre à jour (BIOS,…).
Posté par flagos .
Évalué à 3 (+1/-0).
Dernière modification le 12 août 2024 à 14:44.
Linus Torvalds a toujours été vent debout contre les firmwares des PC. Car ce sont des bouts de code critiques et qu'il est impossible de mettre à jour (BIOS,…).
Je comprends pas bien, faire ces fonctionalites en hardware n'aiderait pas beaucoup a les mettre a jour il me semble.
Pour moi le problème que tu énonces ressemble plus a un problème de distribution des mises a jour qu'a un problème de conception. Je ne vois pas en quoi raler sur les gens qui ont correctement concu le produit va regler le probleme initial.
Tu veux dire que l'OS peut envoyer les binaires des autres processeurs de la plateforme ?
Si c'est ca, ca veut dire que l'OS peut les mettre a jour, notamment si une faille a ete reportee au/par le vendeur. Donc si j'ai bien suivi, on dit la meme chose: il faut gerer les mises a jour proprement plutot que de casser du sucre sur les vendeurs qui mettent un processeur dans leur plateforme.
Si le tout est sous contrôle d'un OS, il est impossible d'installer un truc "avant" du moment que le processus de boot est suffisamment rigide et stupide (genre je lis les 256 octets du disque de boot et j’exécute le tout).
Si il n'y a pas de "avant" et qu'il n'y a pas de "ring" ou de niveau de sécurité plus élevé que l'OS, c'est impossible de planquer du code. Je rappelle que ces niveau "-1" ont été créé pour faire des DRM à la base.
Question probablement bête : à supposer que les mécanismes types firmware, TPM, etc, n’existent pas, peux-t-on être assurés que toute faille de sécurité matériel des puces puisse être réglée via l’OS ?
Un BIOS peut se mettre à jour. Le problème ici concerne apparemment des couches encore plus basses. Il y aura bien un correctif pour éviter la vulnérabilité mais ça ne corrigera pas les machines déjà atteintes. Il faudrait des moyens dépassant le coût de remplacement de la machine. Par ailleurs, je ne sais si on peut vérifier si la machine a été atteinte par ce problème.
Tous les PC récent intègrent un ARM de gestion système dont le code est planqué. C'est évidement un nid à bugs et cela peut compromettre la machine. Les fabricants préfèrent exposer 3 API logiciels, plutôt que de documenter le hardware.
“It's going to be nearly undetectable and nearly unpatchable.” Only opening a computer's case, physically connecting directly to a certain portion of its memory chips with a hardware-based programming tool known as SPI Flash programmer and meticulously scouring the memory would allow the malware to be removed, Okupski says.
C'est difficile à détecter, d'accord, mais est-ce qu'il ne suffit pas de reflasher la SPI complètement ne suffirait pas à s'en débarrasser ?
Bien sûr, il faut déjà pouvoir flasher la SPI, ce qui n'est malheureusement pas viable dans beaucoup de situations (ça demande souvent des outils spécifiques, souvent d'ouvrir l'ordinateur, etc - et le faire depuis l'OS, si c'est possible, ne serait pas fiable puisqu'un bootkit suffisamment élaboré pourrait faire mentir le processus de flashing si je comprends bien - et si on n'est pas spécialiste qui a les bons outils, il faut déjà avoir entendu parler de la faille et en avoir assez quelque chose à faire pour aller trouver et payer quelqu'un pour le faire - si tant est qu'on a le bon binaire à flasher à disposition).
Tout ça laisse penser que tous ces mécanismes qui permettent de flasher des choses dans le matériel sont des portes ouvertes à ce genre de vulnérabilité - y compris des mécanismes comme Secure Boot, qui par construction demandent de pouvoir enregistrer des données, et qui donc sont susceptibles d'apporter des vulnérabilités alors qu'ils sont là pour le contraire…
For systems with certain faulty configurations in how a computer maker implemented AMD's security feature known as Platform Secure Boot—which the researchers warn encompasses the large majority of the systems they tested—a malware infection installed via Sinkclose could be harder yet to detect or remediate, they say, surviving even a reinstallation of the operating system
C'est quand même con, une fonctionnalité là pour la sécurité qui réduit la sécurité. Je comprends bien que le problème se situe lors de l'intégration de cette fonctionnalité, mais quand-même.
En cas de mise à jour de mon PC, mon choix s'était déjà porté sur du AMD. pour contribuer à maintenir une concurrence forte à Intel mais aussi à cause des nombreux problèmes sur les procs Intel ces dernières années. Mais du coup, là, je suis un peu perdu. J'en suis à prier que mon vieux i3-530 et sa carte-mère durent encore quelques années.
Il y aua toujours des bugs matériel et/ou logiciel non corrigés chez les particuliers et même dans le secteur public/privé qui n'est pas à fond orienté sécu. Heureusement qu'on ne met pas tout le matériel concerné à la benne sinon la crise écologique serait bien pire… (et il n'y aurait aucun ordinosaure, aucun musée d'informatique, les budgets info seraient monstrueux, l'IA serait un gouffre financier et technique, etc., etc.). Il y a probablement des moments où aucune solution sans faille connue n'existe (au moment de l'apparition d'une classe de faille sur la prédiction spéculative par exemple), et il faut des mois/années pour que le nouveau matériel arrive… Bref on évalue ses risques et on fait avec, on trouve des contournements, on rajoute des couches de protection autour (airgap, nombre d'utilisateurs restreints, parefeu/filtre, etc.).
(La question est différente si on est fournisseur de cloud avec CPU partagés accessibles à des clients externes multiples par exemple… lui il veut très vite un correctif logiciel, une contremesure ou racheter du matos si ça existe)
Posté par Psychofox (Mastodon) .
Évalué à 4 (+1/-0).
Dernière modification le 15 août 2024 à 13:08.
il faut garder en tête que ton i3 est aussi tout troué et a obligé toute ta pile software à activer des mécanisme de mitigations.
Il faut aussi garder en tête que cette faille AMD n'est exploitable que par un programme ayant accès au ring0, c'est à dire que ton pc et tes données sont déjà compromises à ce stade. Là seule différence que ça fait c'est que si un programme malicieux a pu s'installer et sait exploiter cettw faille pour s'héberger dans le microcode de ton CPU, reformater ton disque dur ne sera pas suffisant pour repartir de zéro.
Maintenant questionne-toi le nombre de fois où tu as formaté un disque dur parce que tu suspectais avoir un trojan ou virus installé sur ton PC ces 20 dernières années?
C'est plus une épine dans le pied pour les entreprises qui ont des centaines ou milliers de machines et qui ne voudraient pas avoir à tout remplacer ou reflasher avec un outil hardware si une intrusion était détectée.
Il faut aussi garder en tête que cette faille AMD n'est exploitable que par un programme ayant accès au ring0.
J'ai lu qu'il "suffisait" d'être root. Or des exploits permettant de passer root ne sont pas si rarissimes que ça, même sur Linux. C'est très différent des failles qui nécessitent un accès local à la machine, ce qui dans mon cas d'utilisateur à la maison ne me préoccupe pas trop.
Posté par mahikeulbody .
Évalué à 3 (+1/-0).
Dernière modification le 15 août 2024 à 19:54.
Oui mais un malware n'a même pas besoin d'arriver root pour obtenir accès à ce qui est le plus important pour toi: tes données utilisateurs.
J'ai des sauvegardes hors ligne et je pense que je suis assez prévenu contre les malwares "classiques" pour que le risque soit faible même s'il ne sera jamais zéro.
Si un malware est root sur ton système c'est déjà game over pour toi avant même que quiconque essaie d'accéder au microcode de ton CPU.
Je ne peux évidemment rien contre une faille 0-day donnant un accès root. Je n'ai que les sauvegardes pour minimiser/réparer les dégâts. Seulement avec Sinkclose, cela peut aussi signifier que toute ma config est compromise de façon irréversible et dans ce cas la seule solution sera de tout changer (carte mère, processeur, mémoire).
D'ailleurs, est-ce qu'il y a moyen de savoir si la config a déjà été compromise ? Si la réponse est non, c'est quand un sacré risque de garder sa config même si on est un particulier, non ?
En tant que particulier tu savais détecter avant cette faille si ton microcode CPU ou disque ou réseau, ton secteur d'amorçage, ton contrôleur RAID ou stockage distant, ton noyau courant ou tous tes programmes actifs ou sur disque sont vérolés ? Si non, alors ça change relativement peu de chose. Si oui, alors ça change probablement relativement peu de chose.
# Linus avait prévenu...
Posté par Nicolas Boulay (site web personnel) . Évalué à 10 (+8/-0). Dernière modification le 12 août 2024 à 11:21.
Linus Torvalds a toujours été vent debout contre les firmwares des PC. Car ce sont des bouts de code critiques et qu'il est impossible de mettre à jour (BIOS,…).
Cela démontre qu'il a encore une fois raison.
"La première sécurité est la liberté"
[^] # Re: Linus avait prévenu...
Posté par Benoît Sibaud (site web personnel) . Évalué à 4 (+1/-0).
Double correction sur le nom de Linus
[^] # Re: Linus avait prévenu...
Posté par devnewton 🍺 (site web personnel) . Évalué à 7 (+4/-0).
Question technique : pourquoi ne pas utiliser un firmware amovible? Une cartouche quoi :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Linus avait prévenu...
Posté par flagos . Évalué à 3 (+1/-0). Dernière modification le 12 août 2024 à 14:44.
Je comprends pas bien, faire ces fonctionalites en hardware n'aiderait pas beaucoup a les mettre a jour il me semble.
Pour moi le problème que tu énonces ressemble plus a un problème de distribution des mises a jour qu'a un problème de conception. Je ne vois pas en quoi raler sur les gens qui ont correctement concu le produit va regler le probleme initial.
[^] # Re: Linus avait prévenu...
Posté par Nicolas Boulay (site web personnel) . Évalué à 5 (+2/-0).
C'est le role d'un OS de gérer le bas niveau.
"La première sécurité est la liberté"
[^] # Re: Linus avait prévenu...
Posté par mahikeulbody . Évalué à 4 (+2/-0).
Au point de se passer complètement de firmware ?
[^] # Re: Linus avait prévenu...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3 (+0/-0).
Oui, le code kernel en mode system joue ce role, si tu as un arm système tu peux gérer aussi son binaire.
"La première sécurité est la liberté"
[^] # Re: Linus avait prévenu...
Posté par flagos . Évalué à 2 (+0/-0).
Tu veux dire que l'OS peut envoyer les binaires des autres processeurs de la plateforme ?
Si c'est ca, ca veut dire que l'OS peut les mettre a jour, notamment si une faille a ete reportee au/par le vendeur. Donc si j'ai bien suivi, on dit la meme chose: il faut gerer les mises a jour proprement plutot que de casser du sucre sur les vendeurs qui mettent un processeur dans leur plateforme.
[^] # Re: Linus avait prévenu...
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2 (+0/-0).
Non, mais est-ce que ça n'empêcherait pas d'installer un bootkit qui survit systématiquement à une réinstallation complète du système ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Linus avait prévenu...
Posté par flagos . Évalué à 2 (+0/-0).
Il me semble que la signature des firmwares a justement ce but.
[^] # Re: Linus avait prévenu...
Posté par Nicolas Boulay (site web personnel) . Évalué à 6 (+3/-0).
Si le tout est sous contrôle d'un OS, il est impossible d'installer un truc "avant" du moment que le processus de boot est suffisamment rigide et stupide (genre je lis les 256 octets du disque de boot et j’exécute le tout).
Si il n'y a pas de "avant" et qu'il n'y a pas de "ring" ou de niveau de sécurité plus élevé que l'OS, c'est impossible de planquer du code. Je rappelle que ces niveau "-1" ont été créé pour faire des DRM à la base.
"La première sécurité est la liberté"
[^] # Re: Linus avait prévenu...
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2 (+0/-0).
Question probablement bête : à supposer que les mécanismes types firmware, TPM, etc, n’existent pas, peux-t-on être assurés que toute faille de sécurité matériel des puces puisse être réglée via l’OS ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Linus avait prévenu...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3 (+0/-0).
Ils peuvent exister du moment que l'utilisateur a la clef et le moyen de patcher.
Il restera toujours les failles type spectre et meltdown qui peuvent "mitiger" par logiciel.
"La première sécurité est la liberté"
[^] # Re: Linus avait prévenu...
Posté par mahikeulbody . Évalué à 5 (+3/-0).
Un BIOS peut se mettre à jour. Le problème ici concerne apparemment des couches encore plus basses. Il y aura bien un correctif pour éviter la vulnérabilité mais ça ne corrigera pas les machines déjà atteintes. Il faudrait des moyens dépassant le coût de remplacement de la machine. Par ailleurs, je ne sais si on peut vérifier si la machine a été atteinte par ce problème.
[^] # Re: Linus avait prévenu...
Posté par Nicolas Boulay (site web personnel) . Évalué à 6 (+3/-0).
Tous les PC récent intègrent un ARM de gestion système dont le code est planqué. C'est évidement un nid à bugs et cela peut compromettre la machine. Les fabricants préfèrent exposer 3 API logiciels, plutôt que de documenter le hardware.
"La première sécurité est la liberté"
# Flash aveugle pour retirer le bootkit ?
Posté par raphj . Évalué à 5 (+3/-0).
C'est difficile à détecter, d'accord, mais est-ce qu'il ne suffit pas de reflasher la SPI complètement ne suffirait pas à s'en débarrasser ?
Bien sûr, il faut déjà pouvoir flasher la SPI, ce qui n'est malheureusement pas viable dans beaucoup de situations (ça demande souvent des outils spécifiques, souvent d'ouvrir l'ordinateur, etc - et le faire depuis l'OS, si c'est possible, ne serait pas fiable puisqu'un bootkit suffisamment élaboré pourrait faire mentir le processus de flashing si je comprends bien - et si on n'est pas spécialiste qui a les bons outils, il faut déjà avoir entendu parler de la faille et en avoir assez quelque chose à faire pour aller trouver et payer quelqu'un pour le faire - si tant est qu'on a le bon binaire à flasher à disposition).
Tout ça laisse penser que tous ces mécanismes qui permettent de flasher des choses dans le matériel sont des portes ouvertes à ce genre de vulnérabilité - y compris des mécanismes comme Secure Boot, qui par construction demandent de pouvoir enregistrer des données, et qui donc sont susceptibles d'apporter des vulnérabilités alors qu'ils sont là pour le contraire…
C'est quand même con, une fonctionnalité là pour la sécurité qui réduit la sécurité. Je comprends bien que le problème se situe lors de l'intégration de cette fonctionnalité, mais quand-même.
# au final, quoi choisir ?
Posté par mahikeulbody . Évalué à 3 (+1/-0).
En cas de mise à jour de mon PC, mon choix s'était déjà porté sur du AMD. pour contribuer à maintenir une concurrence forte à Intel mais aussi à cause des nombreux problèmes sur les procs Intel ces dernières années. Mais du coup, là, je suis un peu perdu. J'en suis à prier que mon vieux i3-530 et sa carte-mère durent encore quelques années.
[^] # Re: au final, quoi choisir ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 4 (+1/-0). Dernière modification le 15 août 2024 à 11:16.
Il y aua toujours des bugs matériel et/ou logiciel non corrigés chez les particuliers et même dans le secteur public/privé qui n'est pas à fond orienté sécu. Heureusement qu'on ne met pas tout le matériel concerné à la benne sinon la crise écologique serait bien pire… (et il n'y aurait aucun ordinosaure, aucun musée d'informatique, les budgets info seraient monstrueux, l'IA serait un gouffre financier et technique, etc., etc.). Il y a probablement des moments où aucune solution sans faille connue n'existe (au moment de l'apparition d'une classe de faille sur la prédiction spéculative par exemple), et il faut des mois/années pour que le nouveau matériel arrive… Bref on évalue ses risques et on fait avec, on trouve des contournements, on rajoute des couches de protection autour (airgap, nombre d'utilisateurs restreints, parefeu/filtre, etc.).
(La question est différente si on est fournisseur de cloud avec CPU partagés accessibles à des clients externes multiples par exemple… lui il veut très vite un correctif logiciel, une contremesure ou racheter du matos si ça existe)
[^] # Re: au final, quoi choisir ?
Posté par Psychofox (Mastodon) . Évalué à 4 (+1/-0). Dernière modification le 15 août 2024 à 13:08.
il faut garder en tête que ton i3 est aussi tout troué et a obligé toute ta pile software à activer des mécanisme de mitigations.
Il faut aussi garder en tête que cette faille AMD n'est exploitable que par un programme ayant accès au ring0, c'est à dire que ton pc et tes données sont déjà compromises à ce stade. Là seule différence que ça fait c'est que si un programme malicieux a pu s'installer et sait exploiter cettw faille pour s'héberger dans le microcode de ton CPU, reformater ton disque dur ne sera pas suffisant pour repartir de zéro.
Maintenant questionne-toi le nombre de fois où tu as formaté un disque dur parce que tu suspectais avoir un trojan ou virus installé sur ton PC ces 20 dernières années?
C'est plus une épine dans le pied pour les entreprises qui ont des centaines ou milliers de machines et qui ne voudraient pas avoir à tout remplacer ou reflasher avec un outil hardware si une intrusion était détectée.
[^] # Re: au final, quoi choisir ?
Posté par mahikeulbody . Évalué à 3 (+1/-0).
J'ai lu qu'il "suffisait" d'être root. Or des exploits permettant de passer root ne sont pas si rarissimes que ça, même sur Linux. C'est très différent des failles qui nécessitent un accès local à la machine, ce qui dans mon cas d'utilisateur à la maison ne me préoccupe pas trop.
[^] # Re: au final, quoi choisir ?
Posté par Psychofox (Mastodon) . Évalué à 4 (+1/-0). Dernière modification le 15 août 2024 à 15:51.
Oui mais un malware n'a même pas besoin d'arriver root pour obtenir accès à ce qui est le plus important pour toi: tes données utilisateurs.
Si un malware est root sur ton système c'est déjà game over pour toi avant même que quiconque essaie d'accéder au microcode de ton CPU.
[^] # Re: au final, quoi choisir ?
Posté par mahikeulbody . Évalué à 3 (+1/-0). Dernière modification le 15 août 2024 à 19:54.
J'ai des sauvegardes hors ligne et je pense que je suis assez prévenu contre les malwares "classiques" pour que le risque soit faible même s'il ne sera jamais zéro.
Je ne peux évidemment rien contre une faille 0-day donnant un accès root. Je n'ai que les sauvegardes pour minimiser/réparer les dégâts. Seulement avec Sinkclose, cela peut aussi signifier que toute ma config est compromise de façon irréversible et dans ce cas la seule solution sera de tout changer (carte mère, processeur, mémoire).
D'ailleurs, est-ce qu'il y a moyen de savoir si la config a déjà été compromise ? Si la réponse est non, c'est quand un sacré risque de garder sa config même si on est un particulier, non ?
[^] # Re: au final, quoi choisir ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 4 (+1/-0).
En tant que particulier tu savais détecter avant cette faille si ton microcode CPU ou disque ou réseau, ton secteur d'amorçage, ton contrôleur RAID ou stockage distant, ton noyau courant ou tous tes programmes actifs ou sur disque sont vérolés ? Si non, alors ça change relativement peu de chose. Si oui, alors ça change probablement relativement peu de chose.
[^] # Re: au final, quoi choisir ?
Posté par mahikeulbody . Évalué à 3 (+1/-0). Dernière modification le 16 août 2024 à 09:59.
Tu ne fais aucune différence entre une faille connue et une faille hypothétique ? Moi si.
(sans parler que sur une partie des hypothèses de ta liste, je peux toujours réparer/réinstaller si j'ai un doute)
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.