Systèmes open source vs systèmes à source fermée

Question

Ma compréhension est que systèmes open source sont généralement considérés comme plus sûrs que systèmes source fermés .

Les raisons d'adopter l'une ou l'autre de ces approches, ou leur combinaison, incluent: les normes culturelles, financières, le positionnement juridique, la sécurité nationale, etc.

L'une des principales préoccupations est la sécurité. Une position commune contre les systèmes open source est qu'un attaquant pourrait exploiter la faiblesse du système s'il est connu. Une position commune contre les systèmes à source fermée est qu'un manque de sensibilisation est au mieux une mesure de sécurité faible; communément appelé la sécurité par l'obscurité .

La question est: les systèmes open source sont-ils en moyenne meilleurs pour la sécurité que les systèmes open source? Si possible, veuillez citer une analyse dans autant d'industries que possible, par exemple: logiciel , militaire , marchés financiers , etc.

Cette question était Question de la semaine sur la sécurité informatique .
Lisez le 25 mai 2012 entrée de blog pour plus de détails ou soumettez le vôtre Question de la semaine.

Jesper M · Accepted Answer

L'idée que les logiciels open source sont intrinsèquement plus sûrs que les logiciels open source - ou la notion opposée - est un non-sens. Et quand les gens disent quelque chose comme ça c'est souvent juste FUD et ne fait pas avancer la discussion de manière significative.

Pour raisonner à ce sujet , vous devez limiter la discussion à un projet spécifique. Un logiciel qui gratte une démangeaison spécifique, est créé par une équipe spécifiée et a un public cible bien défini. Pour un tel cas spécifique, il peut être possible de déterminer si l'open source ou la source fermée serviront le mieux le projet.

Le problème avec le pitch de toutes les implémentations "open source" par rapport à toutes les implémentations "open source" est que l'on ne se contente pas de comparer les licences. En pratique, l'open source est favorisé par les efforts de bénévolat doit, et la source fermée est le plus courant dans les efforts commerciaux. Nous comparons donc en fait:

Licences.
Accès au code source.
Très différent structures d'incitation , à but lucratif ou pour le plaisir.
Situations de responsabilité juridique très différentes.
Tailles et compétences d'équipe différentes et très variables.
etc.

Pour tenter de juger de la façon dont tout cela fonctionne pour la sécurité de tous les logiciels publiés en tant que source ouverte/fermée, il suffit de tomber en panne. Cela devient une déclaration d'opinion, pas un fait.

Thomas Pornin · Answer

Maintenu le logiciel est plus sécurisé que le logiciel qui ne l'est pas. L'effort de maintenance étant, bien entendu, relatif à la complexité dudit logiciel et au nombre (et aux compétences) de personnes qui le regardent. La théorie derrière les systèmes open source étant plus sûrs est qu'il y a "beaucoup d'yeux" qui regardent le code source. Mais cela dépend beaucoup de la popularité du système.

Par exemple, en 2008 ont été découverts dans OpenSSL plusieurs débordements de tampon , dont certains conduisant à l'exécution de code à distance. Ces bogues se trouvaient dans le code depuis plusieurs années. Donc, même si OpenSSL était opensource et avait une base d'utilisateurs importante (il s'agit, après tout, de la bibliothèque SSL principale utilisée pour les sites Web HTTPS), le nombre et la compétence des auditeurs de code source n'étaient pas suffisants pour surmonter la complexité inhérente au décodage ASN.1 (la partie d'OpenSSL où se cachent les bogues) et du code source d'OpenSSL (franchement, ce n'est pas le code source C le plus lisible jamais).

Les systèmes à code source fermé ont, en moyenne, beaucoup moins de personnes pour faire des Q&R. Cependant, de nombreux systèmes fermés ont payé développeurs et testeurs, qui peuvent s'engager à plein temps dans le travail. Ce n'est pas vraiment inhérent à la question ouverte/fermée; certaines entreprises emploient des personnes pour développer des systèmes open source, et, en théorie, on pourrait produire un logiciel open source gratuitement (c'est relativement courant dans le cas des "freewares" pour Windows). Cependant, il existe toujours une forte corrélation entre avoir des testeurs rémunérés et être une source fermée (la corrélation n'implique pas de causalité, mais cela ne signifie pas non plus que les corrélations doivent être ignorées).

D'un autre côté, être une source fermée facilite la dissimulation des problèmes de sécurité, ce qui est mauvais, bien sûr.

Il existe des exemples de systèmes à source ouverte et fermée, avec beaucoup ou très peu de problèmes de sécurité. Les systèmes d'exploitation opensource * BSD ( FreeBSD , NetBSD et OpenBSD , et quelques autres) ont un très bon bilan en matière de sécurité. Solaris aussi, même s'il s'agissait d'un système d'exploitation à source fermée. D'un autre côté, Windows a (avait) une terrible réputation en la matière.

Résumé: à mon avis, l'idée "opensource implique la sécurité" est surfaite. Ce qui est important, c'est le temps (et les compétences) consacré au suivi et à la résolution des problèmes de sécurité, ce qui est principalement orthogonal à la question de l'ouverture de la source. Cependant, vous voulez non seulement un système sécurisé, vous voulez aussi un système que vous avez positivement sachez pour être sécurisé (ne pas être cambriolé est important, mais pouvoir dormir la nuit aussi). Pour ce rôle, les systèmes open source présentent un léger avantage: il est plus facile d'être convaincu qu'il n'y a pas de faille de sécurité délibérément cachée lorsque le système est open source. Mais la confiance est une chose flottante, comme cela a été démontré avec la récente tragicomédie autour des prétendues portes dérobées dans OpenBSD (pour autant que je sache, il s'est avéré être un hareng rouge, mais, conceptuellement, je ne peux pas être à moins que je vérifie le code moi-même).

user2213 · Answer

Je pense que la solution la plus simple et la plus simple est celle du génie logiciel. L'argument suit généralement: le logiciel open source est plus sécurisé car vous pouvez voir la source !

Avez-vous les connaissances en génie logiciel pour comprendre le noyau de haut en bas? Bien sûr, vous pouvez regarder un tel pilote, mais avez-vous une connaissance complète de ce qui se passe vraiment pour dire "ah oui, il doit y avoir un bug"?

Voici un exemple intéressant: il n'y a pas si longtemps, un bug de déréférencement de pointeur nul est apparu dans l'un des noyaux bêta qui était une chose assez importante, découvert par le gars de grsecurity (correctifs PaX):

Il a été introduit dans un morceau de code comme celui-ci:

pointer = struct->otherptr; if ( pointer == NULL ) { /* error handling */ } /* code continues, dereferencing that pointer which with the check optimised out, can be NULL. Problem. */

et le pointer == NULL check a été optimisé à juste titre par le compilateur - puisqu'un pointeur nul ne peut pas être déréférencé à une structure contenant des membres, cela n'a aucun sens que le pointeur de la fonction soit jamais nul. Le compilateur supprime ensuite la vérification que le développeur attendait.

Ergo, vis a vis, de manière concordante, le code source pour un projet aussi important peut bien sembler correct - mais en fait ce n'est pas le cas.

Le problème est le niveau de connaissances nécessaire ici. Non seulement vous devez être assez familier avec (dans ce cas) C, Assembly, le sous-système de noyau particulier, tout ce qui accompagne le développement de noyaux, mais vous devez également comprendre ce que fait votre compilateur.

Ne vous méprenez pas, je suis d'accord avec Linus qu'avec suffisamment d'yeux, tous les insectes sont superficiels. Le problème est la connaissance dans le cerveau derrière les yeux. Si vous payez 30 enfants pour développer votre produit mais que votre projet open source ne compte que 5 personnes ayant une réelle connaissance de la base de code, alors la version source fermée a plus de chances de réduire les bogues, en supposant une complexité relativement similaire .

De toute évidence, cela s'applique également à tout projet donné transitoire dans le temps, comme l'explique Thomas Pornin.

Mise à jour modifiée pour supprimer les références aux erreurs de gcc, car ce n'était pas le cas.

Ori · Answer

Je pense que les prémisses que la plupart utilisent pour différencier les sources fermées et ouvertes sont assez bien définies. Beaucoup d'entre eux sont énumérés ici, tous deux ont leurs défenseurs. Sans surprise, les partisans de la source fermée sont ceux qui la vendent. Les partisans de l'Open Source en ont également fait une entreprise agréable et bien rangée (au-delà de quelques-uns qui l'ont considérée comme une religion).

Le mouvement Pro Open Source parle des bases, et en ce qui concerne la sécurité en général, voici les points qui correspondent le mieux à la discussion:

La prémisse de personnalisation
Le principe de gestion des licences
La prémisse Open Format
La prémisse de Many Eyes
La prémisse Quick Fix

Donc, décomposant cela par prémisse, je pense que les deux derniers ont été couverts assez succinctement par d'autres ici, alors je les laisse tranquilles.

Le lieu de personnalisation
En ce qui concerne la sécurité, le local de personnalisation donne aux entreprises qui adoptent le logiciel la possibilité de créer des contrôles de sécurité supplémentaires sur une plate-forme existante sans avoir à obtenir une licence ou convaincre un fournisseur de réparer quelque chose de la leur. Il permet aux organisations qui ont besoin ou voient une lacune d'augmenter la sécurité globale d'un produit. SELinux est un parfait exemple, vous pouvez remercier le NSA pour avoir rendu cela à la communauté.
Le principe de gestion des licences
Souvent, il est mentionné que si vous utilisez des technologies F/OSS, vous n'avez pas besoin de gérer des licences technologiques avec des tiers (ou si vous le faites bien moins.), Et cela peut être vrai de Entièrement Open Écosystèmes sources. Mais de nombreuses licences (notamment la GPL) imposent des exigences aux distributeurs, et la plupart des environnements du monde réel sont des mélanges hétérogènes de technologies fermées et open source. Ainsi, même si cela réduit les dépenses en logiciels, la disponibilité de la source peut conduire certaines entreprises à violer les licences OSS en gardant la source privée lorsqu'elles ont l'obligation de libérer la source. Cela peut finalement transformer le principe de gestion des licences en un passif (qui est l'argument de source fermée contre les licences comme la GPL.)
La prémisse du format ouvert
C'est un gros problème, et je suis généralement d'accord avec ça, donc je vais être bref pour ne pas prêcher. Dans 30 ans, je veux pouvoir ouvrir un fichier que j'ai écrit. Si le fichier est "protégé" à l'aide de contrôles DRM propriétaires et que le logiciel dont j'ai besoin pour y accéder n'est plus vendu, la difficulté d'accéder à mon propre contenu a augmenté de façon spectaculaire. S'il y a un format utilisé pour créer mon document qui est ouvert et disponible dans un produit open source d'il y a 30 ans, je serai probablement en mesure de le trouver et de pouvoir l'utiliser légalement. Certaines entreprises sautent sur le wagon "Open Formats" sans sauter sur le wagon Open Source, donc cet argument, je pense, est assez solide.

Il y a une sixième prémisse que je n'ai pas énumérée, car elle n'est pas bien discutée. J'ai tendance à rester coincé (appeler cela de la paranoïa). Je pense que la sixième prémisse est la plume du chapeau des départements de la défense du monde entier. Il a été expliqué au monde entier lorsqu'une partie de la source Windows 2000 a été divulguée.

Le principe de la responsabilité de source fermée
Si une entreprise a produit une bibliothèque de code source fermée ou une API via plusieurs versions au cours des décennies, de petits groupes de personnes ont eu accès à cette source tout au long de sa production. Certains d'entre eux sont des groupes d'audit tiers et des développeurs qui sont passés à d'autres sociétés/gouvernements. Si ce code est suffisamment statique, pour maintenir la compatibilité, tout comme les avantages des sources fermées, certaines faiblesses peuvent donc rester inopinées pendant de nombreuses années. Ceux qui ont accès à cette source fermée ont la liberté d'exécuter des outils d'analyse de code pour étudier ces faiblesses, les référentiels de bogues de ces magasins de développement de logiciels sont pleins de bogues "mineurs" qui pourraient conduire à des exploits. Toutes ces informations sont disponibles pour de nombreuses personnes internes.

Les attaquants le savent et veulent ces informations par eux-mêmes. Cela met un objectif géant sur l'infrastructure interne de votre entreprise si vous êtes l'un de ces magasins. Et en l'état, vos processus de développement deviennent un problème de sécurité. Si votre entreprise est suffisamment grande et votre base de code bien répartie, vous pouvez même être la cible d'efforts d'infiltration humaine. À ce stade, la technique Charlie Miller: soudoyer un développeur avec suffisamment d'argent et il vous écrira qu'un bug indétectable devient une possibilité distincte.

Cela ne signifie pas non plus qu'il n'entre pas dans les produits OSS de la même manière. Cela signifie simplement que vous disposez d'un ensemble de données, puis lorsqu'elles sont publiées, elles peuvent révéler des faiblesses dans votre base d'installation. Le maintien de sa confidentialité a créé une dette de codage par rapport aux systèmes installés par vos clients que vous ne pouvez pas rembourser immédiatement.

Bruce Ediger · Answer

Vous voudrez regarder ces papiers:

Le résultat est que l'ouverture ou la fermeture est à peu près équivalente selon la quantité de tests effectués sur eux. Et par "test", je ne veux pas dire ce que fait votre "testeur" de drone d'entreprise moyen, mais plutôt comme sur le terrain.

knocte · Answer

Soyons honnêtes ici, lorsque quelqu'un prétend que l'open source est plus sûr que la source fermée, il généralise ce qui se passe aujourd'hui dans les systèmes d'exploitation serveur/bureau, tels que Linux (open source) contre Mac/Windows (propriétaire, source fermée).

Pourquoi les logiciels malveillants sont-ils plus susceptibles d'affecter ces derniers et non les premiers? Pour plusieurs raisons, pour lesquelles je pense que la plus importante est la première (empruntée à cette autre réponse à une question marquée comme doublon de celle-ci ):

Le logiciel installé par l'utilisateur dans le cas d'une distribution Linux (ou autre OS open source), est généralement conditionné par une organisation centralisée (c'est-à-dire dans le cas d'Ubuntu, c'est fait par Canonical, et hébergé par lui), qui héberge des binaires compilés à partir de sources organisées/surveillées par la communauté open source. Cela signifie que la probabilité que l'utilisateur installe un logiciel infecté, ou la probabilité que la communauté open source accepte des modifications de code malveillantes, est beaucoup plus faible que dans le cas de Mac/Windows, où l'utilisateur installe généralement des logiciels à partir de nombreux endroits différents sur le Web. ou auprès de nombreux fournisseurs différents des AppStores. Il y a aussi le risque que les serveurs de l'organisation (par exemple Canonical) soient piratés, mais ce risque est mineur car ces organisations emploient des experts informatiques de premier ordre pour exécuter leurs serveurs.
Le nombre d'utilisateurs de Linux (ou d'autres systèmes d'exploitation open source) est beaucoup plus faible que les utilisateurs Windows/Mac , donc les créateurs de logiciels malveillants préfèrent ne pas les cibler (comme avantage/coût est plus faible dans ce cas).
Linux, n'étant qu'un noyau, est disponible en différentes distributions parmi lesquelles vous pouvez choisir , donc les créateurs de logiciels malveillants devraient consacrer plus d'efforts à créer leur code malveillant être compatible avec beaucoup d'entre eux (donc le rapport bénéfice/coût est plus faible dans ce cas).
Les sources de Linux (ou d'autres OS open source) sont ouvertes à tout le monde pour voir/modifier. Cela signifie que lorsqu'une vulnérabilité de sécurité est trouvée, n'importe qui peut écrire un correctif (il n'y a pas de blocage de fournisseur, vous n'êtes pas lié à une organisation spécifique que vous devez attendre pour développer un correctif), donc en théorie, le les correctifs de sécurité se produisent plus tôt que dans les cas de logiciels propriétaires. (Cependant, dans la pratique, il n'y a généralement pas de différence, car les sociétés qui exploitent des plates-formes propriétaires telles que Windows et MacOS, sont de grandes sociétés qui se trouvent être suffisamment compétentes.)

Geremia · Answer

L'article de Jim Fruchterman sur OpenSource.com " Votre logiciel de sécurité open source est-il moins sécurisé? " donne une très bonne analogie sur la façon dont l'open source, malgré le fait que les attaquants savent comment il fonctionne, rend le logiciel plus sûr pour les utilisateurs finaux :

Considérez le chiffrement comme une combinaison verrouillée sûre pour vos données. Vous pouvez être le seul à avoir la combinaison, ou vous pouvez la confier à quelques associés proches. Le but d'un coffre-fort est d'empêcher les personnes non autorisées d'accéder à son contenu. Il peut s'agir de cambrioleurs qui tentent de voler des informations commerciales précieuses, d'employés qui tentent d'obtenir des informations confidentielles sur le salaire de leurs pairs ou d'un fraudeur qui souhaite obtenir des informations confidentielles afin de commettre une arnaque. Dans tous les cas, vous voulez que le coffre-fort garde vos affaires en sécurité et empêche les personnes non autorisées.

Supposons maintenant que je choisis un coffre-fort pour mes objets de valeur. Est-ce que je choisis Safe Number One qui est annoncé comme ayant des murs en acier d'un demi-pouce, une porte d'un pouce d'épaisseur, six boulons de verrouillage et qui est testé par une agence indépendante pour confirmer que le contenu survivra pendant deux heures dans un incendie? Ou, dois-je choisir le coffre-fort numéro deux, un coffre-fort auquel le vendeur dit simplement de faire confiance, car les détails de conception du coffre-fort sont un secret commercial? Il pourrait être sûr que le numéro deux est en contreplaqué et en tôle mince. Ou, il se pourrait qu'il soit plus fort que Safe Number One, mais le fait est que je n'en ai aucune idée.

Imaginez que vous ayez les plans et spécifications détaillés de Safe Number One, suffisants pour construire une copie exacte de ce coffre-fort si vous aviez les bons matériaux et outils. Est-ce que cela rend Safe Number One moins sûr? Non. La sécurité de Safe Number One repose sur deux protections: la force du design et la difficulté de deviner ma combinaison. Avoir des plans détaillés m'aide, moi ou des experts en sécurité, à déterminer la qualité de la conception. Il aide à établir que le coffre-fort n'a pas de défauts de conception ou une deuxième combinaison de "porte arrière" autre que ma propre combinaison choisie qui ouvre le coffre-fort. Gardez à l'esprit qu'une bonne conception sûre permet à l'utilisateur de choisir sa propre combinaison au hasard. La connaissance de la conception ne devrait pas du tout aider un attaquant à deviner la combinaison aléatoire d'un coffre-fort spécifique utilisant cette conception.