Quel est l'intérêt d'utiliser un système d'exploitation open source et sécurisé si vous l'exécutez sur une machine avec un micrologiciel open source?
Je suis très intéressé par le système d'exploitation OpenBSD, car il me semble actuellement être l'option qui prend la sécurité plus au sérieux que ses contemporains. Mais alors que je lisais à ce sujet, il m'est venu à l'esprit que même si OpenBSD est tout ce qu'il prétend être, comment toute cette sécurité et cette ouverture sont-elles importantes, si j'utilise le système d'exploitation sur un BIOS/matériel propriétaire à source fermée?
Je connais Open BIOS, coreboot et Libreboot, mais je me demande pourquoi les systèmes axés sur la sécurité comme OpenBSD ne font pas tant d'importance à l'utilisation d'un firmware ouvert. Ne battez-vous pas le but de la sécurité ouverte en utilisant en premier lieu un firmware fermé?
Historiquement, le mouvement open source ne concerne pas la sécurité mais bien la liberté. Fondamentalement, Richard Stallman était très consterné de ne pas pouvoir jouer avec son imprimante car la source du pilote n'était pas disponible.
La position d'OpenBSD sur le fait d'être "sécurisé" ne vient pas du fait qu'il soit open source, mais d'un objectif déclaré et d'un engagement à faire les choses correctement en matière de sécurité (toujours historiquement, OpenBSD a vu le jour parce que certains développeurs de NetBSD étaient bien meilleurs en programmation que à gérer les relations pacifiques d’humain à humain).
L'association entre la sécurité et l'open source est plus récente. En fait, dès le départ, il a été expliqué comme étant un concept incomplet (voir le célèbre Ken Thompson Reflections on Trusting Trust ). Un élément de la discussion est Loi de Linus qui dit:
étant donné suffisamment de globes oculaires, tous les insectes sont peu profonds
L'idée centrale est que, avec suffisamment de réviseurs, des bogues seront trouvés, et cela s'étend aux bogues liés à la sécurité. Cependant, cela ne repose que sur la prémisse qu'il y a sont critiques. Les logiciels open source facilitent les révisions externes, mais cela ne signifie pas que les révisions externes se produisent réellement. À quand remonte la dernière fois que vous avez parcouru le code source existant?
Exemple concret: OpenSSL. Après qu'une autre vulnérabilité ait été trouvée dans la base de code, une fourchette a été créée, appelée LibreSSL , et ils ont commencé un effort de révision explicite, qui a trouvé plusieurs problèmes graves dans la base de code. Ces problèmes existaient depuis des années, en plein milieu d'une bibliothèque qui peut être considérée comme l'une des bibliothèques les plus cruciales en matière de sécurité dans l'écosystème Linux. C'était donc open source, et pourtant pas suffisant (du tout) pour obtenir une détection de vulnérabilité appropriée.
Bien sûr, l'open source contribue à la sécurité, mais pas autant qu'on peut l'espérer.
Ce que l'open source apporte vraiment est un risque beaucoup plus élevé pour les personnes qui souhaitent planter volontairement des portes dérobées. Il est difficile de créer un code qui semble inoffensif pour les réviseurs et qui fait toujours de mauvaises choses (il y a contest pour ce code).
L'open source n'est pas sans équivoque = plus sécurisé/sûr
N'importe qui PEUT regarder le logiciel/matériel open source, mais cela ne garantit pas que "n'importe qui" SERA regardez-le; de plus, s'ils l'examinent, cela ne signifie pas non plus qu'ils divulgueront quelque chose qui pourrait constituer une vulnérabilité. Les gens pensent trop de l'open source, et l'un des sophismes qu'ils croient est que si un groupe de personnes PEUT regarder quelque chose, c'est tout à coup plus sûr et plus sûr. Ce n'est pas vrai sans équivoque. C'est agréable de pouvoir avoir beaucoup d'yeux sur le produit, mais l'éthique et la morale de ces yeux me préoccupent autant que leurs prouesses techniques.
Cela étant dit, l'open source présente de nombreux avantages si son concept est correctement mis en œuvre.
De plus, la source fermée n'est pas automatiquement = moins sécurisée/dangereuse.
Mais pour répondre directement à votre question, non, vous ne défaites pas automatiquement l'objectif d'utiliser un système d'exploitation connu qui est concerné par la sécurité comme OpenBSD en l'exécutant sur du matériel de source fermée car le matériel lui-même pourrait avoir un code très sécurisé/firmware derrière tout autant que quelque chose d’ouvert pourrait le faire.
Laissant de côté l'argument "open source == secure", vous pouvez également considérer cette question comme "Pourquoi exécuter un système d'exploitation sécurisé lorsque le BIOS/firmware n'est pas garanti pour être sécurisé".
Pourquoi prendre la peine de verrouiller ma porte d'entrée lorsqu'un attaquant peut simplement casser les fenêtres?
Vous ne ferez jamais un système complètement sécurisé. Ce que vous pouvez faire, c'est vous assurer de travailler sur la sécurisation des pièces faciles à exploiter pour un attaquant. Il faut beaucoup plus de travail pour faire des exploits de firmware, et ils se limitent à cibler un certain modèle de matériel. Alors qu'un bogue OS est plus facile à exploiter et affecte une base cible plus large.
Alors oui, idéalement, vous voulez les deux, mais n'en avoir qu'un n'est pas inutile.
Les logiciels open source (gratuits/libres) ne concernent pas (principalement) la sécurité. Un de ses aspects les plus importants est la confiance : vous pouvez vérifier ce qui fonctionne, il est beaucoup plus difficile de cacher quelque chose de malveillant. Certaines personnes affirment également que davantage de personnes liront (pourraient) lire le code, ce qui signifie que les vulnérabilités sont plus nombreuses à être trouvées et corrigées, ce qui entraîne une meilleure qualité de code. Cela a déjà été discuté en profondeur dans la réponse de Tom Leek. Je n'entrerai pas dans ce sujet discutable plus en profondeur dans cette réponse, car votre question n'est pas de savoir pourquoi les logiciels open source sont plus sécurisés, mais pourquoi se soucier du tout si le firmware est en source fermée.
Mis à part le fait que les logiciels open source ne sont pas nécessairement sécurisés non plus, l'exécution de code de confiance sur un micrologiciel non fiable ne rendra-t-elle pas l'exécution de code non fiable? Mais le vecteur d'attaque est potentiellement plus petit. Il est beaucoup plus difficile d'accéder aux interfaces du micrologiciel de l'appareil que d'accéder au système d'exploitation et aux logiciels d'application de votre ordinateur, qui pourraient même fournir des services sur Internet (et de nombreuses autres interfaces à de parfaits inconnus). Il n'y aura jamais de sécurité complète, mais vous pouvez essayer de minimiser les risques dans un budget donné.
Avec un effort suffisant, le firmware open source (UEFI/BIOS) peut être remplacé par un logiciel open source : Coreboot est un excellent exemple qui implémente un firmware ouvert pour certains des produits. Mais le UEFI/BIOS n'est pas le seul firmware : des BLOBs comme le moteur de gestion d'Intel sont parfois encore nécessaires, les périphériques matériels comme les graphiques et les cartes réseau ont un firmware, votre disque dur a, il y a même un microcode chargé dans le CPU. Et tous ont un contrôle plus ou moins arbitraire sur la mémoire et/ou le stockage. Enfin, vous pourriez même vous méfier du vendeur de CPU, qui pourrait implémenter des circuits malveillants dans du matériel standard.
Vous devez vous arrêter à un moment donné et simplement faire confiance au fournisseur , car les coûts augmentent considérablement à mesure que vous descendez la pile vers le matériel. Avez-vous la capacité de vérifier enfin une conception de CPU complexe et de fabriquer vous-même le CPU?
Lors du Chaos Communicaiton Congress 2015 (32C3), il y a eu une grande discussion sur la façon d'obtenir Vers des ordinateurs portables x86 dignes de confiance , fournir un résumé sur le sujet.
Il n'y a pas de sécurité totale, mais il peut être plus difficile de briser la sécurité. Bien qu'il soit possible de compromettre le système depuis l'intérieur du BIOS, UEFI, Intel SME, BIOS du réseau ou des cartes graphiques, microcode du CPU, mauvaise conception du CPU ... c'est beaucoup plus difficile que d'utiliser un bug dans un programme d'espace utilisateur ou le noyau du système d'exploitation. Ainsi, les gars d'OpenBSD se soucient des problèmes qu'ils peuvent résoudre et qui aident vraiment. Cela ne signifie pas qu'ils ne sont pas conscients des autres problèmes.
Il y a toujours des niveaux plus profonds à considérer et les utilisateurs doivent choisir où s'arrêter.
- De nombreuses puces ont un firmware/BIOS non flashable. Voulez-vous cela, même si vous ne pouvez jamais le modifier?
- Et le microcode de votre processeur? Cela peut être remplacé (et est)
- Qu'en est-il du microcode non modifiable de votre processeur/GPU/...?
La seule façon d'être "vraiment sûr" serait d'avoir la conception exacte de chaque puce de votre machine, et un moyen de vérifier que les puces physiques ont cette conception exacte, mais aucun Intel/AMD ne vous donnerait jamais cela, il y a toujours un bloc auquel vous ne pouvez pas faire confiance.
Le micrologiciel est généralement intégré au matériel, et dans la plupart des situations, vous êtes obligé de faire confiance au matériel (faute d'une meilleure alternative). Vous finissez donc par faire confiance au firmware.
Ce n'est pas une bonne chose - la confiance n'est jamais dans InfoSec! Mais si vous faites confiance au matériel, vous ne gagnez pas trop en ne faisant pas confiance au firmware. Si vous voulez vous faire peur à ce sujet, regardez Ralf Weinmann parler du logiciel de bande de base que chaque téléphone a, mais que personne ne pense jamais: https://www.youtube.com/watch?v=fQqv0v14KKY
Comme peut l'avoir dit, l'open source n'est pas synonyme de sécurité. L'open source est extrêmement transparent, ce qui peut aider à l'examen, mais il suppose que l'examen est terminé. Cela suppose également que l'examen se fait en tenant compte de vos intérêts. Est-il révisé à un niveau de confiance?.
Dans de nombreux laboratoires gouvernementaux, le code open source est en fait méfiant. Ils font davantage confiance au code source fermé commercial. Il existe de nombreuses raisons, mais l'une des plus pertinentes ici est que le code source commercial fermé a une société commerciale derrière lui. S'ils ont des problèmes de sécurité particuliers qu'ils souhaitent résoudre, il peut être plus facile de travailler avec une entreprise pour résoudre les problèmes que d'embaucher votre propre expert pour faire l'examen. D'un autre côté, il n'y a pas de société produisant un produit open source, il peut donc être très difficile de convaincre la légion de critiques qui examinent le code open source de se pencher sur vos problèmes particuliers. Ils ont constaté que, dans le cas d'adversaires écrivant intentionnellement des portes dérobées qui ciblent eux, plutôt que de cibler tout utilisateur arbitraire, il est beaucoup plus facile de se faufiler dans l'open source et ne sont pas souvent pris en compte. Une entreprise a beaucoup plus à perdre en permettant aux backdoors de nuire à ses clients qu'un programmeur écrivant open source pendant son temps libre.
Même si vous ne pouvez pas faire confiance au firmware, le fait de pouvoir faire confiance au système d'exploitation (et aux applications) augmente la confiance globale que vous pouvez avoir dans le système.
En outre, le micrologiciel est rarement (voire jamais) utilisé au-delà du démarrage du système et les chances qu'une vulnérabilité ou une porte dérobée affectent avec succès le système d'exploitation une fois qu'il est opérationnel sont pratiquement nulles.
Je vous rappelle que vous ne devez pas laisser le parfait être l'ennemi du bien.
Oui, OpenBSD est à risque car il s'exécute sur un firmware à source fermée. Il y a un petit problème ici. Les plates-formes matérielles fermées constituent l'essentiel de ce qui est disponible sur le marché sur le marché libre. Donc, si vous voulez que les gens utilisent votre logiciel/soient utiles à quelqu'un d'autre, vous devrez exécuter certains de ces micrologiciels.
Du point de vue de la sécurité, ils peuvent résoudre de nombreux problèmes de sécurité des logiciels en écrivant et en exécutant le logiciel OpenBSD. Les exploits qui existent dans le firmware sont généralement effectués par un petit groupe de personnes (la plupart des attaques de firmware sont beaucoup plus spécialisées).
Étant donné un système d'exploitation open source, les groupes de matériel open source peuvent démarrer avec une base logicielle connue. Sans une grande base de capital, la construction des deux en même temps est prohibitive (la plupart des années, OpenBSD a à peine la base du logiciel qu'il écrit).
Jusqu'à ce qu'une solution matérielle open source bonne et abordable existe, se plaindre que les gens n'utilisent pas une solution matérielle open source semble cracher sous la pluie.
Veuillez garder à l'esprit que la complexité récente du logiciel du BIOS (c'est-à-dire qu'il est vulnérable aux attaques), est un nouveau développement par rapport à l'histoire du domaine. Pour cette raison, il existe très peu d'évaluations complètes des menaces pour le BIOS et le micrologiciel. Pour accomplir une situation sécurisée, vous devez utiliser à la fois un micrologiciel sécurisé, qu'il soit à source ouverte ou fermée, et un système d'exploitation sécurisé. L'utilisation d'un BIOS sécurisé et fermé et d'un système d'exploitation ouvert sécurisé est une option parfaitement raisonnable.