Cybersécurité : le miroir aux alouettes de l’open source, la confiance dans les composants

Cybersécurité : le miroir aux alouettes de l’open source, la confiance dans les composants

« On ne doit plus faire de sécurité par obscurité »

Avatar de l'auteur
Sébastien Gavois

Publié dans

Internet

24/02/2021 10 minutes
43

Cybersécurité : le miroir aux alouettes de l’open source, la confiance dans les composants

En matière de cybersécurité, l’open source est un bon point de départ, mais pas suffisant pour autant. La traçabilité des composants est aussi importante, comme nous le rappelle l’affaire Supermicro. Quels sont les risques et les solutions envisagées sur ces sujets ? Une demi-douzaine de chercheurs répondent à ces questions.

La semaine dernière, Emmanuel Macron annonçait une stratégie cyber avec un milliard d’euros à la clé. Afin de revenir sur les ambitions de ce plan, le CEA, le CNRS et Inria organisaient une conférence commune pour faire un point de la situation de la recherche en France. 

Durant cette présentation, sur laquelle nous aurons l’occasion de revenir en détail, nous avons interrogé les chercheurs sur un point en particulier de la cybersécurité : les projets open source. Nous avions évidemment en mémoire la faille Heartbleed d’OpenSSL, qui a fait trembler Internet il y a maintenant sept ans. 

Des méthodes formelles à un « cyber centaure »

Pour Ludovic Mé, adjoint au directeur scientifique en charge du domaine de recherche Cybersécurité à Inria, il y a deux aspects à cette problématique. Il commence par voir le côté positif et rappelle qu’il y a « un certain nombre de failles dans SSL qui ont été découvertes grâce aux travaux académiques », notamment ceux « liés au domaine des méthodes formelles ».

Notre dossier sur le plan Cyber :

Pour résumer il s’agit de « techniques informatiques d'une grande rigueur permettant, à l'aide de langages spécialisés et de règles logiques, de s'assurer (idéalement) de l'absence de tout défaut de programmes informatiques », rappelle l’Universalis.

Le chercheur explique que, dans certains cas, « les failles et les attaques correspondantes étaient tellement compliquées qu’on ne pouvait pas les trouver avec un crayon et un papier pour le dire simplement ». « C’est le monde académique qui a découvert les failles et c’est le monde académique qui a produit en association avec Microsoft, pour être très précis, une nouvelle version de SSL exempte de ces failles », affirme-t-il.

Cette technique d’« épauler l’expert – l’être humain – avec des capacités automatisées, y compris à base de machine learning », est prometteuse pour Florent Kirchner, responsable du programme Cybersécurité du CEA List. Pour détailler son propos, il reprend la notion de Centaure (une créature mi-homme, mi-cheval de la mythologie) notamment utilisée par le Grand Maitre des échecs Garry Kasparov, pour qui une association « entre l’homme et la machine, qui en fait joue mieux que l’homme tout seul ou la machine toute seule ».

Pour Florent Kirchner, cette collaboration serait particulièrement efficace dans le cas de l’analyse d’un système : « Un cyber centaure c’est quelque chose que demain on va continuer d‘explorer […] et montrer que cette complémentarité libère du temps aux experts, apporte une valeur ajoutée significative pour leur permettre de se concentrer sur les problèmes intéressants et importants », affirme-t-il.

Le responsable du programme Cybersécurité du CEA List voit ce cyber centaure comme l’« organisation ultime en matière de cybersécurité ». Pour Ludovic Mé, c’est la preuve que « les travaux académiques peuvent avoir un impact extrêmement réel ».

Le risque zéro n’existe pas

A contrario, une seconde lecture de cette douloureuse affaire Heartbleed peut être faite : « Est-ce que ça change aujourd’hui ? Si on disait les choses un peu rapidement on dirait : "non, ça n’a pas changé aujourd’hui" ». Pour le chercheur, le fond du problème est « qu’on ne peut jamais assurer qu’il n’y a pas une faille résiduelle dans [un] système ; qu’il soit ouvert ou fermé ne change rien ».

Cette remarque est valable pour tous les systèmes, mais le risque se multiplie lorsqu’un même logiciel est largement utilisé, ce qui était le cas d’OpenSSL. Ludovic Mé précise néanmoins que, comme de nombreux autres chercheurs du milieu académique, il pense que « si c’est ouvert c’est mieux, mais ce n’est pas une garantie complète non plus ».

Il s’explique :

« Le système est tellement compliqué, il y a tellement de dizaines de milliers de lignes de code que personne n’est capable d’assurer qu’effectivement tout a été revu. Et même si tout a été revu, toutes les failles n’ont pas été découvertes. Il est impossible d'éliminer le problème, c’est pour ça que la réponse un peu rapide serait de dire "non, ce n’est pas mieux aujourd’hui" ».

Point positif : il y a une « espèce de sensibilité globale à ce problème-là qui a augmenté, en particulier car il y a eu des cas comme ceux que vous mentionnez avec Heartbleed ». D’autres failles ont depuis fait trembler Internet et tomber certains protocoles de sécurité, renforçant la prise de conscience collective (souvent tardive). Mais il reste encore tellement de mauvaises pratiques, de « bugs », de défauts de conception… On est toujours surpris de les voir faire surface lorsqu’ils entrainent des fuites de données personnelles.

 « Open source » ne sont pas deux mots magiques en cybersécurité

Gildas Avoine, directeur du GDR CNRS Sécurité informatique et professeur de l’INSA Rennes à l’Institut de recherche en informatique et systèmes aléatoires, apporte son grain de sel sur la question de l’open source : « Ce qui est clair aujourd’hui [et] prôné par la communauté académique, c’est que les algorithmes et le code soient ouverts. On ne doit plus faire de sécurité par obscurité ».

Pour appuyer ses dires, le directeur de recherche cite le principe du linguiste Auguste Kerckhoffs Van Nieuwenhof, consigné dans son traité de La cryptographie militaire de 1883 : « La sécurité d’un système de cryptement ne doit pas dépendre de la préservation du secret de l’algorithme. La sécurité ne repose que sur le secret de la clé », comme l’indique l’ANSSI dans guide des bonnes pratiques de la cryptologie.

ANSSI Crypto
Crédits : ANSSI

Appliqué au monde moderne, ce principe « pourrait se traduire par l’open source », lâche Gildas Avoine. Son corolaire est tout aussi important : « la sécurité ne doit pas reposer sur le fait que le code n’est pas open source ».

« Bien souvent », personne n’a audité le code

Mais attention, si « open source » veut dire que tout le monde peut (en théorie) accéder au code source, cela ne signifie pas pour autant que des chercheurs passent des heures, semaines, mois ou années à le vérifier sous toutes les coutures… c’est même très loin d’être le cas : « Au final, il y a très peu de gens qui ont la compétence pour l’auditer, et bien souvent il n’y a personne qui l’a fait ». C’est malheureusement une triste réalité. 

Gildas Avoine en ajoute une couche : « Le code est dynamique, il évolue […] il y a différentes versions. Même s’il a été audité à un instant T, on s’aperçoit qu’il peut y avoir des failles qui arrivent un peu plus tard. C’était le cas de Heartbleed, une faille introduite avec le développement d’une nouvelle version ». Cette brèche était en plus passée sous les radars pendant plusieurs années. 

Pire encore selon Ludovic Mé : « quand une nouvelle version corrige, une faille est produite, il se passe parfois des mois, des années – des années – avant qu’elles soient déployées concrètement sur 99 % des systèmes. La faille résiduelle, même corrigée, est présente souvent pour de nombreuses années ». Dans le cas de Heartbleed par exemple, près de 200 000 serveurs étaient toujours vulnérables trois ans après la mise en ligne des correctifs. C’est un problème beaucoup plus large, que l’on retrouve par exemple dans les objets connectés embarquant d'anciens noyaux Linux, les ordinateurs, etc.

Pour résumer, « il faut être vigilant avec le code open source », explique Ludovic Mé. Même si l’open source est largement soutenue par le monde académique et que certaines sociétés sautent le pas notamment pour essayer de montrer qu’elles n’ont rien à cacher, « on n’a aucune garantie de sécurité parce que le code est open source ».

Supermicro : la crédibilité des déclarations de Bloomberg

Durant la conférence, le sujet des micropuces chinoises espionnes sur des cartes mères Supermicro est revenu sur le devant de la scène. Jacques Fournier, chef du laboratoire de sécurisation des objets et systèmes physiques du CEA Leti, était le premier à répondre : « Je n’ai pas d’information, je ne peux pas confirmer quoi que ce soit sur les révélations de Bloomberg ».

Il ajoutait néanmoins que c’est « effectivement une problématique qui est aujourd’hui existante […] On a des chaines d’approvisionnement de plus en plus complexes, qu’on n’arrive plus à tracer. Sur certains objets connectés et déploiements de systèmes critiques, ça peut poser problème ». Avec d’autres chercheurs et des partenaires privés, Fournier travaille sur des « processus qui permettent de réduire et mitiger les risques de supply chain ».

Florent Kirchner, responsable du programme Cybersécurité du CEA List, est plus sceptique : « jusqu’ici, il n’y a rien qui est venu prouver ces révélations là. On n’a pas trouvé ces puces chinoises. On aurait pu imaginer qu’en deux ans, on s’était laissé assez de temps pour regarder tout ça ».

Comme nous l’avions expliqué, des sociétés avec d’énormes moyens et de forts enjeux sur le sujet de la confidentialité (Amazon, Apple, OVH) se sont penchées sur ce sujet sans rien trouver jusqu’à présent. « Je prendrais ces révélations de Bloomberg avec une dose un peu sérieuse de sel en termes de crédibilité », ajoute Florent Kirchner. 

Des choses qu’on a « du mal à expliquer » dans les processeurs

Cela ne doit par contre pas cacher le fond du problème, comme nous l’avions déjà expliqué : « On a des composants qui viennent de partout dans le monde, et qui sont intégrés un peu partout dans le monde, qu’on reçoit ensuite et dans lesquels se pose fondamentalement la question de "est-ce que je peux avoir confiance ?" » ; une question valable aussi bien pour la partie logicielle que matérielle.

On touche ici à la question de la souveraineté numérique : « qu’est-ce qu’on veut maitriser, en quoi on a confiance, comment on fait pour établir la confiance ? », se demande Ludovic Mé.

Ce dernier ajoute : « je ne sais pas quel est le statut juridique de ça, mais reverser [au sens rétro-ingénierie, ndlr] les processeurs de nos amis ou moins amis américains ou d’ailleurs, pour voir ce qu’il y a dedans. Ceux qui le font savent et voient qu’il y a parfois des choses qu’ils ont du mal à expliquer dans ces processeurs. C’est avéré pour le coup ».

43

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Des méthodes formelles à un « cyber centaure »

Le risque zéro n’existe pas

 « Open source » ne sont pas deux mots magiques en cybersécurité

« Bien souvent », personne n’a audité le code

Supermicro : la crédibilité des déclarations de Bloomberg

Des choses qu’on a « du mal à expliquer » dans les processeurs

Commentaires (43)


…avec une dose un peu sérieuse de sel en termes de crédibilité.
Pas compris.



Par contre aucun chercheur pour parler des failles dans les proc. Intel, Arm et Amd ?
https://www.inpact-hardware.com/article/1726/des-failles-sur-processeurs-amd-et-intel-comme-sil-en-pleuvait


je peux avoir mal lu, mais il me semble que le sujet est évoqué dans le dernier paragraphe de l’article.


Je ne crois pas que ça soit français…”take it with a grain of salt”


Ma petite remarque en passant : open source signifie que tout le monde peut contribuer au code. Dans “tout le monde”, il y a “tout le monde”. Je suis un attaquant, je m’intéresserais aux compilateurs, aux outils de chiffrements ou de compression (GPG, librairies SSL, zip divers et variés), et je ne parle pas des OS comme Linux. La traçabilité est une piste, l’audit en est une autre, mais qui en pratique vérifie ça ? Comme il est dit dans l’article, c’est extrêmement rare. TrueCrypt avait l’objet d’un audit avant d’être curieusement abandonné. GPG est réputé sûr mais j’ai entendu dire qu’en regardant certains versions, on aurait des surprises…


Ce n’est pas si facile d’introduire une vulnérabilité exploitable dans un code maintenu par une organisation tierce. Beaucoup de projets ont des relecteurs qui vérifient le code, en particulier quand il vient de contributeurs inhabituels. L’exemple de grsecurity https://grsecurity.net/huawei_hksp_introduces_trivially_exploitable_vulnerability est assez parlant dans ce cas.



En gros à par Bloomberg et ses sources anonyme, personne ne confirme et tous ceux qui ont publié sur leurs recherches disent qu’ils n’ont rien trouvé.
Pour les vulnérabilités hardware de processeurs, la vulnérabilité est plus théorique que pratique et je n’ai pas connaissance de code permettant effectivement de tirer un avantage de ces vulnérabilité. Des codes d’exploitation de vulnérabilités logicielles par contre …


pyrignis

Ce n’est pas si facile d’introduire une vulnérabilité exploitable dans un code maintenu par une organisation tierce. Beaucoup de projets ont des relecteurs qui vérifient le code, en particulier quand il vient de contributeurs inhabituels. L’exemple de grsecurity https://grsecurity.net/huawei_hksp_introduces_trivially_exploitable_vulnerability est assez parlant dans ce cas.



En gros à par Bloomberg et ses sources anonyme, personne ne confirme et tous ceux qui ont publié sur leurs recherches disent qu’ils n’ont rien trouvé.
Pour les vulnérabilités hardware de processeurs, la vulnérabilité est plus théorique que pratique et je n’ai pas connaissance de code permettant effectivement de tirer un avantage de ces vulnérabilité. Des codes d’exploitation de vulnérabilités logicielles par contre …

Le “beaucoup de relecteurs qui vérifient le code”, ça s’applique à quelques grosses / sérieuses boîtes mais c’est loin d’être une généralité, c’est d’ailleurs dans l’argumentaire de cet article.
Je me souviens de cette attaque en 2018 : https://medium.com/@hkparker/analysis-of-a-supply-chain-attack-2bd8fa8286ac
Parfois quand on veut s’attaquer à une cible, il suffit d’examiner les chaînes de dépendances, en dehors du contrôle de la cible, pour y trouver un maillon faible. Cette attaque de 2018 est ingénieuse et en même temps peut être réalisée par un seul hackeur doué, pas besoin d’une armée étatique. Comme dit dans l’article, même lorsqu’on essaye de sécuriser sa supply chain, on peut difficilement tout contrôler tellement ça grossit exponentiellement.


pyrignis

Ce n’est pas si facile d’introduire une vulnérabilité exploitable dans un code maintenu par une organisation tierce. Beaucoup de projets ont des relecteurs qui vérifient le code, en particulier quand il vient de contributeurs inhabituels. L’exemple de grsecurity https://grsecurity.net/huawei_hksp_introduces_trivially_exploitable_vulnerability est assez parlant dans ce cas.



En gros à par Bloomberg et ses sources anonyme, personne ne confirme et tous ceux qui ont publié sur leurs recherches disent qu’ils n’ont rien trouvé.
Pour les vulnérabilités hardware de processeurs, la vulnérabilité est plus théorique que pratique et je n’ai pas connaissance de code permettant effectivement de tirer un avantage de ces vulnérabilité. Des codes d’exploitation de vulnérabilités logicielles par contre …

Yep, j’ai suivis les 2 articles de Bloomberg, c’est seulement que je connais pas cette expression.


pyrignis

Ce n’est pas si facile d’introduire une vulnérabilité exploitable dans un code maintenu par une organisation tierce. Beaucoup de projets ont des relecteurs qui vérifient le code, en particulier quand il vient de contributeurs inhabituels. L’exemple de grsecurity https://grsecurity.net/huawei_hksp_introduces_trivially_exploitable_vulnerability est assez parlant dans ce cas.



En gros à par Bloomberg et ses sources anonyme, personne ne confirme et tous ceux qui ont publié sur leurs recherches disent qu’ils n’ont rien trouvé.
Pour les vulnérabilités hardware de processeurs, la vulnérabilité est plus théorique que pratique et je n’ai pas connaissance de code permettant effectivement de tirer un avantage de ces vulnérabilité. Des codes d’exploitation de vulnérabilités logicielles par contre …

Si, comme tu le le dis, il n’est peut être pas facile d’introduire une vulnérabilité dans un code open source maintenu par une organisation tierce, il est certainement plus facile et plus fréquent d’introduire de manière involontaire une vulnérabilité avec un code mal conçu.


RatonLaveur54

Si, comme tu le le dis, il n’est peut être pas facile d’introduire une vulnérabilité dans un code open source maintenu par une organisation tierce, il est certainement plus facile et plus fréquent d’introduire de manière involontaire une vulnérabilité avec un code mal conçu.


C’est tout a fait véridique. Mais dans ce cas, sources ouvertes ou pas ça ne change pas grand chose. Ça va dépendre des processus de relecture (eventuels)


C’est le moment de ressortir ce dessin: https://xkcd.com/2347/


J’ai tendance à privilégier l’open-source dans les logiciels et outils que je choisis, pour diverses raisons, mais effectivement ce n’est aucunement une garantie de sécurité, et les logiciels propriétaires peuvent très bien être audités et le sont régulièrement, les projets à source fermée peuvent toujours faire l’objet d’une rétro-ingénierie, d’un brouillage, etc. La rétro-ingénierie d’un programme permet d’analyser son fonctionnement de manière beaucoup plus approfondie que ne le permet le simple examen du code source publié.



QTrEIX a dit:


La rétro-ingénierie d’un programme permet d’analyser son fonctionnement de manière beaucoup plus approfondie que ne le permet le simple examen du code source publié.




Je ne vois pas en quoi ce ne serait pas le cas. Il est bien plus simple d’analyser le code source d’un programme que sa forme compilée puis désassemblée. En pouvant analyser le compilateur et le code source du programme, on doit pouvoir obtenir un résultat plus facilement qu’en analysant le programme désassemblé. Sinon, il s’agit d’un problème de rigueur et non d’analyse.



QTrEIX a dit:


La rétro-ingénierie d’un programme permet d’analyser son fonctionnement de manière beaucoup plus approfondie que ne le permet le simple examen du code source publié.




T’as pas dû faire beaucoup de reverse engineering toi.




  1. Tu peux regénérer un programme à partir de son code source publié.

  2. Va pas dire ça à un électronicien, il va s’étouffer. Les conférences de reverse engineering d’électronique sont en général une démonstration de débauche de moyens techniques, alors que si t’avais les schematics sous les yeux, bah…



(reply:1856498:Salamandar) Je prend note, je suis pas un expert donc merci pour ses infos :)




Que l’open-source soit une garantie de sécurité = mythe, là par contre je pense qu’on sera d’accord, et c’est le sujet de l’article.


Disons que open source = vérifiable. Si tu as un nombre suffisant de contributeurs/testeurs,la fiabilité s’améliore
L’aspect open source est un bonus par rapport à un logiciel propriétaire en terme de sécurité. Mais en effet la licence n’assure rien.



Néanmoins, il est plus compliqué de cacher une back door dans un code source ouvert, que dans un logiciel déjà compilé… Donc niveau confiance, le logiciel libre a une avance considérable.



QTrEIX a dit:


Que l’open-source soit une garantie de sécurité = mythe, là par contre je pense qu’on sera d’accord, et c’est le sujet de l’article.




Disons que open source = sécurité est un mythe SAUF pour les logiciels qui ont énormément de contributeurs et/ou méfiance, ce qui n’est pas le cas pour tous les projets open sources.



Exemple SElinux généré par la NSA a la base a été audits par énormément de monde pour être sur qui avais pas une backdoor, la ou la calculette de jane doe sur GitHub n’a jamais été audit par personne.


Bon, effectivement vu comme ça oui, et j’avais mis un commentaire sur un autre article où j’écrivais que si un projet open-source a une merde dans le code, comme un script espion, potentiellement, ça se vérifie plus facilement et la communauté peut être alerté plus rapidement, encore plus si le projet est connu et a beaucoup de contributeur, j’ai par exemple confiance en la sécurité de Signal, mais pas du tout en celle de Silence (un fork) parce que toutes les MAJ depuis 1 an ou plus sont pour des traductions et non pour le code, c’est un projet devenu obsolète.



L’open-source a ce côté éthique que le closed-source n’a pas, bien que les deux peuvent contenir du code malveillant et les deux peuvent subir des audits et des rétro-ingénierie, le closed-source n’est pas une back-door non vérifiable, mais je dois dire que quasiment tous mes logiciels et outils sont open-sources, quand je découvre un logiciel propriétaire, je veux toujours savoir quelle est son alternative open-source, l’autre avantage est que si un projet open-source meurt, il peut plus facilement être repris, ou amélioré, prenons l’exemple de Blender, au début ce logiciel ne tenait pas la comparaisons avec Maya de Autodesk, mais depuis quelques temps, il est aussi bien voir encore mieux, je ne suis pas du tout certains que ça aurait été la même si le logiciel avait été propriétaire, il aurait probablement coulé.


anonyme_6fe7c92f62c257fced6328182e378c61

Bon, effectivement vu comme ça oui, et j’avais mis un commentaire sur un autre article où j’écrivais que si un projet open-source a une merde dans le code, comme un script espion, potentiellement, ça se vérifie plus facilement et la communauté peut être alerté plus rapidement, encore plus si le projet est connu et a beaucoup de contributeur, j’ai par exemple confiance en la sécurité de Signal, mais pas du tout en celle de Silence (un fork) parce que toutes les MAJ depuis 1 an ou plus sont pour des traductions et non pour le code, c’est un projet devenu obsolète.



L’open-source a ce côté éthique que le closed-source n’a pas, bien que les deux peuvent contenir du code malveillant et les deux peuvent subir des audits et des rétro-ingénierie, le closed-source n’est pas une back-door non vérifiable, mais je dois dire que quasiment tous mes logiciels et outils sont open-sources, quand je découvre un logiciel propriétaire, je veux toujours savoir quelle est son alternative open-source, l’autre avantage est que si un projet open-source meurt, il peut plus facilement être repris, ou amélioré, prenons l’exemple de Blender, au début ce logiciel ne tenait pas la comparaisons avec Maya de Autodesk, mais depuis quelques temps, il est aussi bien voir encore mieux, je ne suis pas du tout certains que ça aurait été la même si le logiciel avait été propriétaire, il aurait probablement coulé.


Pour info, Silence ne chiffre que les SMS (pas de connexion internet), contrairement à Signal qui ne chiffre PLUS les Sms :)



Comme tu le dis l’autre avantage du logiciel libre est la reprise. Quand Mozilla n’existera plus (ça ne saurait tarder), Firefox sera probablement repris par d’autres personnes qui sauront, j’espère, mieux investir leur énergie. Ça a été le cas pour Libreoffice, et déjà pour Firefox (enfin… Netscape !).



jotak a dit:


Je me souviens de cette attaque en 2018 : https://medium.com/@hkparker/analysis-of-a-supply-chain-attack-2bd8fa8286ac …Cette attaque de 2018 est ingénieuse et en même temps peut être réalisée par un seul hackeur doué, pas besoin d’une armée étatique.




Intéressant : le pb vient des sources compilées et pas du code source lisible.
Donc pour le coup ce pb vient de l’outil qui utilise une version “compilée” plutôt que la source.
Si npm était correctement conçu, il chargerait le code source des dépendances avant de le compiler sa propre version minignifiée locale.



Ce pb est récurrent sous windows : la plupart des softs ou dépendances (y compris open source), sont livrées en EXE ou DLL : Impossible de s’assurer que la version téléchargée correspond réellement aux sources fièrement affichées dans github.
Pas mal de sites de téléchargement en profitent pour ajouter leur propre malware soit directement compilée dans le binaire, soit simplement packagé dans le package d’installation (.msi ou le setup.exe) en plus de l’exe légitime.



Sous gentoo c’est l’opposé : (presque) aucun code compilé n’entre sur ma machine, tout mon environnement a été compilé en local et les sources sont visibles quelque part dans github. Mais comme le signal l’article ça n’est qu’une sécurité supplémentaire, pas une sécurité absolue !
Il “resterait” à lire (et comprendre) les millions de lignes de codes téléchargées depuis github :)


+1.
Pour Windows, j’utilise désormais Chocolatey. Gestionnaire de paquets dont les paquets sont open source (ce sont des fichiers de configuration qui vont télécharger le logiciel sur le site officiel).
Pour avoir contribué un paquet, je plussoie le processus de vérification. J’ai une confiance assez bonne en Chocolatey et ses paquets.



(et ils ont une version pro utilisée pra des entreprises, ce qui améliore la confiance).


C’est bien à ça que sert le fichier de signature accompagnant certain EXE. Il permet de vérifier la provenance du fichier et qu’il n’a pas été trafiqué par un tier. ^^



Exemple pour Onion Share dont il y avait une actualité hier : https://onionshare.org/#downloads


Mithiriath

C’est bien à ça que sert le fichier de signature accompagnant certain EXE. Il permet de vérifier la provenance du fichier et qu’il n’a pas été trafiqué par un tier. ^^



Exemple pour Onion Share dont il y avait une actualité hier : https://onionshare.org/#downloads


Ça ne sert pas à grand-chose : si tu as trouvé le fichier signature sur le site officiel, autant prendre l’install officielle directement.



Si tu es sur un site cheloud de téléchargement l’ASC correspondra à l’EXE télécharger et certifiera que l’install inclus bien le logiciel complémentaire. :)


fofo9012

Ça ne sert pas à grand-chose : si tu as trouvé le fichier signature sur le site officiel, autant prendre l’install officielle directement.



Si tu es sur un site cheloud de téléchargement l’ASC correspondra à l’EXE télécharger et certifiera que l’install inclus bien le logiciel complémentaire. :)


@Mithitiath parle de site officiel, tu réponds site louche.



Aller sur le site de l’éditeur, c’est quand même le B-A BA…


Cumbalero

@Mithitiath parle de site officiel, tu réponds site louche.



Aller sur le site de l’éditeur, c’est quand même le B-A BA…


Non c’est moi qui parle de site officiel, dans tous les cas cette signature est peu utile.



Quand “au B à BA” merci de préciser pour windows, sous les autres OS ça fait des années que tout est sécurisé (dpkg à 27ans, rpm 24ans ! ) le contrôle de signature est automatique, tout comme la récupération des paquets, leur installation et leur mise à jour…en central… Largement avant la démocratisation d’internet les gestionnaires de paquets Linux étaient déjà capable de prendre leurs sources sur internet, cd-rom voir disquettes :)



Sous Windows tu veux un outil pour imprimer en PDF, tu trouves pdfcreator qui-a-bonne-presse que tu télécharges sur sourceforge qui-avait-bonne-presse: bim tu te retrouves avec un malware et/ou logiciel indésirable type McAfee ou une barre de navigateur.


fofo9012

Non c’est moi qui parle de site officiel, dans tous les cas cette signature est peu utile.



Quand “au B à BA” merci de préciser pour windows, sous les autres OS ça fait des années que tout est sécurisé (dpkg à 27ans, rpm 24ans ! ) le contrôle de signature est automatique, tout comme la récupération des paquets, leur installation et leur mise à jour…en central… Largement avant la démocratisation d’internet les gestionnaires de paquets Linux étaient déjà capable de prendre leurs sources sur internet, cd-rom voir disquettes :)



Sous Windows tu veux un outil pour imprimer en PDF, tu trouves pdfcreator qui-a-bonne-presse que tu télécharges sur sourceforge qui-avait-bonne-presse: bim tu te retrouves avec un malware et/ou logiciel indésirable type McAfee ou une barre de navigateur.


Je n’aime pas Windows, mais il faut reconnaître qu’ils ont enfin(!) fait des progrès. Prendre les softs sur le store plutôt que télécharger sur Clubic et autres miroirs foireux…



Mais on en revient toujours au même: ferais-tu, IRL, ce que tu fais sur le net? Moi quand je veux une bonne entrecôte d’une bête élevée pour sa viande, je vais chez mon boucher, pas au supermarché. Quand je cherche un soft, je vais le chercher auprès d’une source sûre.


Cumbalero

@Mithitiath parle de site officiel, tu réponds site louche.



Aller sur le site de l’éditeur, c’est quand même le B-A BA…


” SI même à EUX on ne doit pas s’y fier…. doit-on chercher (la vraie)
information, alors ?



≠ mondedefakenews :mad:


Pour les processeurs, je me demande qui se lancera dans le «reverse».
Tout d’abord, il faut signaler que sur une puce (le morceau de silicium) en plus de la «circuiterie» du processeur, d’autres circuits sont ajoutés pour valider le process de fonderie (fabrication de la puce). Ces ajouts permettent de valider la puce. On ne teste pas le processeur lui-même avant qu’il soit «emballé». Ces circuits peuvent sembler étrange, sans forcément être malveillant et actif.
Pour vraiment décoder la combinaison de milliards de transistors, c’est un budget. Pour refaire un le petit processeur du TI99/4A une entreprise que je connais à investit plus d’un million, pour une dizaine de millier de transistors.
Donc pour le hardware, même pour un processeur open-source, il faut avoir confiance. En Europe, il nous reste deux «fondeurs», STMicroelectronis et Infineon. Les autres sont en principalement en Asie (Taïwan, Chine, Corée, Japon,…) et états-unis.
Pensons aussi que le processeur n’est pas le seul organe de l’ordinateur.



Salamandar a dit:


Pour info, Silence ne chiffre que les SMS (pas de connexion internet), contrairement à Signal qui ne chiffre PLUS les Sms :)



Comme tu le dis l’autre avantage du logiciel libre est la reprise. Quand Mozilla n’existera plus (ça ne saurait tarder), Firefox sera probablement repris par d’autres personnes qui sauront, j’espère, mieux investir leur énergie. Ça a été le cas pour Libreoffice, et déjà pour Firefox (enfin… Netscape !).




Oui, Signal chiffre aussi les métadonnées (ce que ne fait pas WhatsApp), mais n’empêche que je ne conseillerai pas Silence pour la sécurité, pas de MAJ du code depuis longtemps : https://git.silence.dev/Silence/Silence-Android/-/commits/master



Concernant Mozilla, y a un problème avec leurs CEO mais je préfère rester optimiste, je ne pense pas qu’ils vont disparaître de sitôt bien que c’est une menace qui existe, même si Firefox est repris, ça ne garantie rien pour autant, pour le moment, qu’ils continuent de travailler sur une sandbox pour la version mobile (projet Fission), qu’ils améliorent celle de la version bureau et que Rust continue sa croissance.


Oui bon… on le dit dans les commentaires depuis un moment. Ces citations enfonces des portes ouvertes.



Ça ne fourni toujours pas de solution et encore moins d’action.



refuznik a dit:


…avec une dose un peu sérieuse de sel en termes de crédibilité. Pas compris.




L’interview a été faite en anglais et c’est une traduction littérale, l’expression “with a pinch of salt” se traduirait plutôt par “avec des pincettes”.


Ah merci :inpactitude:



TexMex a dit:


Oui bon… on le dit dans les commentaires depuis un moment. Ces citations enfonces des portes ouvertes.



Ça ne fourni toujours pas de solution et encore moins d’action.




Les analyse automatique du code GitHub/GitLab sont un début de solution je dirais, analyse automatisée d’éventuels CV-XXXXX connue.


C’est très maigre et ne remplacera pas l’humain. Ni une autorité étatique.



On le voit. La CNIL est en train de prévenir tout le monde en mode discret sous couvert de jeu de chat perché. On peut imaginer aisément qu’un paquet de loi est en préparation et que celui-ci pourrait bien être à base de solutions punitives dures.



Mais cela n’est pas ce qu’il faut. Il y a un énorme travail humain pour faire circuler l’information et comme c’est rappelé plus haut il y a nombre de thèmes (hardware, software, Open Source / fermé).



Il faut au moins une structure qui puisse aller vérifier (en termes de droit) qu’une boite qui traite du dossier médical (par ex) soit effectivement à jour. Aujourd’hui … bon … c’est pas vraiment fait. Il y a des “exigences” (RGPD et consort) mais pas beaucoup plus.



Alors il y en aura bien un qui va nous dire que cette idée est une Gestapo du numérique. Ce genre de troll va foisonner. Car d’un coté cela coûte de le faire évidement mais aussi, l’entrepreneur ne le voit pas d’un bon œil car il sait au tréfonds de son fion que l’on va trouver un tas de trucs inavouables sur ses plateformes (et pas dans son fion).


TexMex

C’est très maigre et ne remplacera pas l’humain. Ni une autorité étatique.



On le voit. La CNIL est en train de prévenir tout le monde en mode discret sous couvert de jeu de chat perché. On peut imaginer aisément qu’un paquet de loi est en préparation et que celui-ci pourrait bien être à base de solutions punitives dures.



Mais cela n’est pas ce qu’il faut. Il y a un énorme travail humain pour faire circuler l’information et comme c’est rappelé plus haut il y a nombre de thèmes (hardware, software, Open Source / fermé).



Il faut au moins une structure qui puisse aller vérifier (en termes de droit) qu’une boite qui traite du dossier médical (par ex) soit effectivement à jour. Aujourd’hui … bon … c’est pas vraiment fait. Il y a des “exigences” (RGPD et consort) mais pas beaucoup plus.



Alors il y en aura bien un qui va nous dire que cette idée est une Gestapo du numérique. Ce genre de troll va foisonner. Car d’un coté cela coûte de le faire évidement mais aussi, l’entrepreneur ne le voit pas d’un bon œil car il sait au tréfonds de son fion que l’on va trouver un tas de trucs inavouables sur ses plateformes (et pas dans son fion).


Personnellement je pense que sans répression rien changera ces boites parfois préfère payer l’amande que changer ça coûte moins chère :S
Une répression forte et amande dissuasive (en pourcentage des bénéfices et non en montant fixe) pourrait forcé les grosse boite à bouger.
Il suffi de voir que le TLS 1.0 et 1.1 ont été abandonnés uniquement car chrome les a viré sans quoi ils seraient encore utilisés.
Pour preuve beaucoup de serveurs permettent encore l’utilisation d’algorithmes qui ne supporte pas le perfect forward secret ou n’ont pas activé TLS1.3


anonyme_f525e46a95b50f94ea596fa0bc1b20fd

Personnellement je pense que sans répression rien changera ces boites parfois préfère payer l’amande que changer ça coûte moins chère :S
Une répression forte et amande dissuasive (en pourcentage des bénéfices et non en montant fixe) pourrait forcé les grosse boite à bouger.
Il suffi de voir que le TLS 1.0 et 1.1 ont été abandonnés uniquement car chrome les a viré sans quoi ils seraient encore utilisés.
Pour preuve beaucoup de serveurs permettent encore l’utilisation d’algorithmes qui ne supporte pas le perfect forward secret ou n’ont pas activé TLS1.3

je pense que sans une répression……rien changera, ces boites parfois préfèreront souvent
payer l’amende plutôt que changer quoi-que-ce-soit, cela leur coûte moins cher




  • 2 !



Macqael a dit:


Disons que open source = sécurité est un mythe SAUF pour les logiciels qui ont énormément de contributeurs et/ou méfiance, ce qui n’est pas le cas pour tous les projets open sources.




sudo, serveur mail BSD (y compris OpenBSD, “spécialisé sécurité”), sont deux composants qui auraient dû être plus audités vu les failles béantes trouvées dedans ces 4 dernières années, failles qui étaient parfois présentes depuis plusieurs années.
(Celle du serveur mail BSD est particulièrement facile à exploiter, et franchement à se demander si elle n’était pas là volontairement).


Moi j’accorde toute ma confiance au pare-feu d’OpenOffice !



refuznik a dit:


…avec une dose un peu sérieuse de sel en termes de crédibilité. Pas compris.



Expression, on dit prendre une chose avec “un grain de sel”, donc on doute sérieusement.




Cumbalero a dit:


Je n’aime pas Windows, mais il faut reconnaître qu’ils ont enfin(!) fait des progrès. Prendre les softs sur le store plutôt que télécharger sur Clubic et autres miroirs foireux…




1) Windows n’a rien à voir là-dedans : tu pointes ici un pur problème d’interface chaise-clavier, qu’on retrouve tout aussi bien avec Linux (notamment les PPA sur la famille Ubuntu, les dépôts tiers non officiels sur Arch…) ou macOS (il vient d’où, ce DMG ?).



2) Tu sais qu’on peut télécharger depuis les sites officiels ou autres dépôts GitHub/GitLab (ou d’autres reconnus comme propres : Ninite, Chocolatey, win-get bientôt…) ?



Certes, c’est pas toujours une garantie de propreté, certains sites officiels proposant quand même des installeurs qui refilent des PUP si on fait pas gaffe. Mais là aussi, c’est surtout un problème d’interface chaise-clavier qui ignore qu’il ne faut jamais, au grand jamais, passer par l’installation « rapide/express », mais bien toujours par la « personnalisée », et bien lire tous les écrans de l’assistant, sans cliquer comme un taré sur « Suivant, suivant, suivant, terminé ».



(quote:1857128:Trit’)
Certes, c’est pas toujours une garantie de propreté, certains sites officiels proposant quand même des installeurs qui refilent des PUP si on fait pas gaffe. Mais là aussi, c’est surtout un problème d’interface chaise-clavier qui ignore qu’il ne faut jamais, au grand jamais, passer par l’installation « rapide/express », mais bien toujours par la « personnalisée », et bien lire tous les écrans de l’assistant, sans cliquer comme un taré sur « Suivant, suivant, suivant, terminé ».




Et surtout ne pas se fier aux habitudes : un soft qui n’a jamais eu de PUP intégré au setup (et sur lequel on fait next les yeux fermés à force), peut s’en voir refourguer un du jour au lendemain! (coucou Ccleaner :cartonrouge: )


Erreur..



(reply:1857128:Trit’)
Mais là aussi, c’est surtout un problème d’interface chaise-clavier qui ignore
qu’il ne faut jamais, au grand jamais, passer par l’installation « rapide/express »
mais bien toujours par la « personnalisée », et bien lire tous les écrans de l’assistant
sans cliquer comme un taré sur « Suivant, suivant, suivant, terminé ».




le gros problème de nos ‘sociétés, c’est ‘le-manque-de-temps’ !
(ça “nous tuera”) :windu:


Si c’est pas le pouvoir de la c××nerie, ou la pandémie (celle-là ou une autre à venir, plus féroce)…