Question:
Comment savoir qu'un logiciel ne fait que ce que l'auteur prétend?
user3533
2013-02-07 03:08:39 UTC
view on stackexchange narkive permalink

Sans être un programmeur ou un expert en informatique, comment puis-je savoir si un programme particulier ou un logiciel en général ne possède pas de fonctions indésirables cachées compromettant la confidentialité et la sécurité?

De nombreux commentaires sont pertinents. De plus, si le logiciel s'exécute sur une machine * nix ou bsd, vous pouvez mettre une trace sur le logiciel et observer les fonctionnalités de bas niveau (c'est-à-dire ce que le système appelle il fait).
Si vous étiez un expert en programmation, vous pourriez utiliser l'analyse statique. Décompilez le programme en utilisant IDAPro et voyez une carte de tous les apis système appelés, c'est-à-dire ceux qui pourraient causer des dommages. En dehors de cela, vous pouvez voir si l'application ouvre des ports ou passe des appels téléphoniques à la maison en utilisant un pare-feu.
Si un logiciel particulier prétend ne rien faire, alors ce problème est facile.
-1
En général, vous ne pouvez pas savoir qu'un logiciel ne fait que ce que l'auteur prétend. Cependant, pour répondre à votre question spécifique: comment puis-je savoir si un programme particulier a caché des fonctions indésirables compromettant la confidentialité et la sécurité? Installez ce logiciel sur un ordinateur totalement déconnecté - pas d'Internet, de wifi, de réseau local, etc. N'utilisez cet ordinateur que pour exécuter ce programme. Si des fonctions indésirables cachées tentent de compromettre la confidentialité et la sécurité, elles échoueront.
Cette préoccupation est l'une des raisons pour lesquelles certaines personnes choisissent les logiciels Open Source. Si quelqu'un peut lire le code source, vous avez une bien meilleure chance de savoir si le programme fait quelque chose de fâcheux.
Btw, quelqu'un se souvient de ces vrais «virus» informatiques de l'ère pré-Internet? - Ils modifieraient les fichiers exécutables trouvés sur l'ordinateur de la victime, en y injectant leur propre code. C'est un autre cas où personne ne peut faire des affirmations sur le comportement des programmes, même s'ils ont été proprement construits à partir d'un code source fiable.
Sept réponses:
Tom Leek
2013-02-07 03:39:59 UTC
view on stackexchange narkive permalink

Vous pouvez savoir si certains logiciels ne font que ce qu'ils annoncent de la même manière que vous pouvez savoir si la nourriture qu'ils vous servent dans les restaurants est empoisonnée ou non. En termes simples, vous ne pouvez pas, mais la société a mis au point divers plans pour faire face au problème:

  • Vous pouvez écouter vos amis et critiques pour savoir si la nourriture d'un restaurant donné a une bonne réputation ou pas.
  • Vous pouvez prélever un échantillon et l'envoyer à un laboratoire qui recherchera de nombreuses (mais pas toutes) substances toxiques connues.
  • Vous pouvez demander gentiment si vous pouvez observer le cuisinier pendant qu'il prépare les plats.
  • Le cuisinier a un intérêt commercial direct à ce que son client soit satisfait de la qualité de la nourriture, et le bonheur comprend, en particulier, ne pas être mort.
  • La société punit les empoisonneurs avec la plus grande sévérité et on peut généralement supposer que le cuisinier le sait.
  • Vous avez toujours l'option extrême de ne pas y manger si vous êtes trop inquiet.

Tous ces éléments peuvent être directement transposés dans le monde du logiciel. Les méthodes extrêmes de vérification de la qualité du logiciel et du respect de son comportement publié incluent des choses très coûteuses et ennuyeuses telles que les Critères communs qui se résument à savoir qui a créé le programme et avec quels outils.

Réponse alternative: chaque logiciel a des bogues, il est donc garanti à 100% qu'il ne fait pas exactement ce qu'il est censé faire. (Cette assertion inclut le logiciel qui fonctionne dans la douzaine de petits ordinateurs qui sont intégrés dans votre voiture, d'ailleurs.)

Une des meilleures analogies jamais vues
C'est bon. Et la réponse alternative est également brillante.
Un point: un restaurant est assez connu et établi, alors que la personne qui fabrique un logiciel peut ne pas l'être. Certaines personnes anonymes peuvent ne pas être punies si le logiciel est mauvais, et vous ne connaissez pas nécessairement leur réputation. Si vous savez qui a réellement fait un morceau de logiciel et qu'ils ont une solide réputation à défendre, alors l'analogie fonctionne mieux.
L'analogie couvre cela très bien aussi, @cpast. Vous mangez plus en toute sécurité dans un restaurant bien connu et bien noté que d'acheter des sushis à un vendeur de rue qui pourrait disparaître après avoir accidentellement vendu du mauvais poisson.
Il y a aussi des choses comme la spécification formelle (vous pouvez lire la spécification si vous connaissez le langage de spécification) et tester si l'élément SW s'y conforme.
De plus, vous pouvez demander ou consulter la recette et préparer vous-même la nourriture à la maison.
Ou vous pouvez demander les ingrédients et le cuisiner vous-même (télécharger le code source et compiler).
C'est la réponse typique à ce genre de question. Ce n'est pas tout à fait vrai. Code! = Food car le concepteur du langage choisit les règles de l'univers. Exemple artificiel: dans un langage purement fonctionnel, je sais déjà à 100% avec certitude qu'aucune fonction ne peut provoquer d'effets secondaires en dehors de l'utilisation de l'espace / temps. "chaque logiciel a des bogues", est faux; la fonction d'identité `id: a -> a; id x = x` n'a pas de bogue, le type seul en est déjà la preuve. Je sais aussi que la fonction d'ajout multi-précision dans l'assemblage x64 que j'ai écrit aujourd'hui n'a pas de bogue par intuition - il est manifestement évident qu'elle est correcte.
Chaque analogie se décompose lorsqu'on la regarde de trop près. C'est ainsi que les analogies vont: elles illustrent les concepts afin que l'esprit humain puisse les digérer. Quant à votre fonction, puisque le matériel lui-même n'est pas exempt de bogues ...
Le code que j'ai écrit est sans bogue, que le matériel soit ou non sans bogue. Sans faire d'hypothèses, on ne peut jamais rien «savoir». Cela étant dit, ne continuez pas et ne faites pas confiance au matériel Intel. Aussi: "La société punit les empoisonneurs avec la plus grande sévérité et on peut généralement supposer que le cuisinier le sait." La société a-t-elle puni Debian pour le générateur aléatoire vuln qui l'a effectué pendant 2 ans (équivalent à une porte dérobée)? Non, ils n'ont même pas perdu leur crédibilité.
@Longpoke peut-être que le code que vous avez écrit est sans bogue et peut-être que le matériel est sans bogue. Le compilateur et / ou l'interpréteur sont-ils sans bogue? Indépendamment de l'espace / temps, l'utilisation peut être un problème en soi. Imaginez que l'ordinateur exécute (a) un système de survie et (b) votre fonction d'identité. Le LFS a un bogue de concurrence étrange qui ne ferait jamais surface dans un million d'années, sauf si l'utilisation de l'espace / temps de vos fonctions d'identification l'a forcé. Votre fonction d'identification a sans doute fait quelque chose au-delà de ce que vous prétendiez.
@emory: Il est facile de vérifier une implémentation non optimisante d'un langage FP. La cause du bogue de concurrence n'est pas «id», le problème est qu'une autre partie du système a un bogue de concurrence. Si vous vous souciez de la sécurité, vous vérifiez l'ensemble du TCB (ce qui signifie que vous ne pouvez pas utiliser une pile insensée comme gcc / * nix / x86) et assurez-vous qu'il n'y a pas de tels bogues de concurrence. Cela dit, si cette question ne concerne en réalité que la vérification du logiciel * nix, la réponse est assez simple: vous ne pouvez pas. Quiconque dit le contraire utilise une définition industrielle de «sécurisé». Par * nix, je veux dire BSD, Microsoft, Apple, UNIX, etc.
"Le cuisinier a un intérêt commercial direct à ce que son client ne soit pas mort." Je jure que si jamais j'écris un manuel d'introduction à l'économie d'entreprise (probablement jamais, mais bon), cette phrase sera là.
Maintenant, j'ai juste besoin d'inventer une neurotoxine latente qui amènera le buveur à réécrire lui aussi son testament juste avant de mourir. (Désolé, je suis un peu en voyage détourné, et cette analogie en manquait un;))
David Stratton
2013-02-07 03:35:08 UTC
view on stackexchange narkive permalink

Vous ne pouvez pas, du moins pas avec une précision de 100%. En tant que programmeur, il est très facile de coder ce que je veux, et ce n'est pas nécessairement juste ce qui est annoncé.

Toutes les activités inattendues ne sont cependant pas malveillantes. Je suppose que vous vous inquiétez davantage des activités malveillantes. Même cela n'est pas possible à 100% de détecter tout le temps, mais il y a de l'espoir.

Vous pouvez utiliser un logiciel qui surveille des choses comme le trafic réseau, l'activité des fichiers, etc., pour trouver des indices que le logiciel se comporte de manière inattendue façon. Par exemple (et je sais que ce n'est qu'un outil de base), vous pouvez utiliser Fiddler pour voir si une application particulière accède à Internet via http (s). (Oui, je sais qu'il existe de meilleurs outils, cependant. Fiddler n'est que le premier qui me vient à l'esprit.) Sous Windows, vous pouvez utiliser Process Monitor pour obtenir encore plus d'informations. Des outils similaires existent pour d'autres plates-formes.

Il existe également plusieurs autres services que vous pouvez utiliser et qui effectueront l'analyse pour vous.

L'analyse dynamique ne vous achète rien. Vous êtes coincé avec le problème d'arrêt de toute façon. Une simple bombe logique écrite par un enfant de 12 ans déjouera tous les types d'analyse dynamique tant que le code est suffisamment dense.
Jeff Ferland
2013-02-07 03:41:27 UTC
view on stackexchange narkive permalink

D'autant plus que les logiciels deviennent plus volumineux et plus compliqués, il devient impossible * même pour les experts de répondre à cela. Dans cette mesure, la confidentialité et la sécurité d'une application sont mieux gérées en utilisant les méthodes bac à sable ou contrôle d'accès obligatoire. L'idée derrière ces méthodes est que le logiciel est exécuté dans un système qui contrôle ce qu'il peut faire et vous lui permettez de ne faire que ce que vous attendez de lui. Fait correctement, vous pouvez limiter les connexions possibles et être averti si le programme essaie d'accéder à des fichiers auxquels vous ne vous attendiez pas. Des méthodes très avancées peuvent être utilisées pour surveiller la mémoire ou décrypter le trafic réseau via un service proxy.

En bref, si vous ne pouvez pas comprendre tout ce qu'il fait, la réponse est de restreindre tout ce qu'il peut faire avec quelque chose qu'il s'exécute à l'intérieur de (le système d'exploitation).

Il y a un astérisque suspendu après votre «impossible» mais, de droit, vous devriez citer Donald Knuth et MetaPost ici.
L'astérisque suspendu implique que le temps ne serait pas infini, tout simplement trop long.
les bacs à sable typiques (VM, java, etc.) / MAC / ACL / DAC etc. ont tous échoué. Le seul modèle que je connais et qui fonctionne actuellement est le modèle de capabilité. D'un autre côté, si vous êtes bloqué en utilisant * nix, votre seul choix est vraiment ce que vous avez mentionné.
@Longpoke SELinux, au moins, contrôle chaque appel système et inclut donc un contrôle de capacité.
@JeffFerland Je ne parle pas des capacités Linux, je parle du modèle de capacité.
Mok-Kong Shen
2013-02-07 19:35:15 UTC
view on stackexchange narkive permalink

Dans sa célèbre conférence ACM Turing Award "Reflections on Trusting Trust" (il y a presque exactement 30 ans maintenant!) Ken Thompson a déclaré: "Vous ne pouvez pas faire confiance à un code que vous n'avez pas totalement créé vous-même." Dans la pratique, les logiciels commerciaux ne font pas exception aux autres produits commerciaux dans la mesure où ceux des producteurs ayant de bons noms sur le marché ont généralement une probabilité plus élevée d'être meilleurs. Cependant, il n'y a aucune garantie absolue pour cela. Il y a des décennies, j'ai reçu des disquettes d'un producteur renommé qui avait un virus. Dans ce cas, je pense personnellement qu'il ne s'agissait pas d'un acte malveillant de la part de quiconque au sein de l'entreprise, mais que certains ordinateurs de l'entreprise ont été infectés par un virus de l'extérieur. Cependant, il n'est évidemment pas possible en général d'exclure à 100% la possibilité que des portes dérobées soient introduites dans le logiciel par des initiés de l'entreprise, que cela soit connu ou non de son PDG. Les portes dérobées pourraient être à mon humble avis un problème extrêmement critique, maintenant que les cyber-guerres se profilent dans le monde. Une agence secrète d'un gouvernement pourrait notamment gérer d'une manière ou d'une autre (via l'argent, la coersion ou même des logiciels malveillants) pour avoir de telles portes dérobées implantées dans certains logiciels qui servent normalement à assurer la sécurité des communications (par exemple, celles qui concernent les signatures numériques) et qui sont vendues et utilisé par certaines nations étrangères non amies ou potentiellement non amies et, immédiatement ou à des moments ultérieurs appropriés («bombes à retardement», etc.), exploitent les portes dérobées pour atteindre leurs objectifs de perturbation des infrastructures critiques des nations cibles, etc. etc. Stuxnet, Flame et Gauss sont quelques noms qui devraient donner quelques indications sur les capacités des malfaiteurs potentiels.

Étendre votre point de vue ... Même si vous compilez à partir des sources que vous avez écrites vous-même ... Qui veut dire que le compilateur que vous utilisez ne fait rien de néfaste (en supposant que vous n'ayez pas écrit le compilateur à partir de l'assembly ...)
@Josh: Tout dépend de la hauteur de votre mise. Non seulement les logiciels d'application, mais aussi les compilateurs, le système d'exploitation et le micrologiciel / matériel peuvent être des sources potentielles de danger. Vous devez décider judicieusement quelles mesures de sécurité sont nécessaires dans votre cas et ce qui sont superflues (et prendre la responsabilité des omissions). En décembre 2012, une conférence DAPRA aux États-Unis a eu pour objectif de trouver et de fermer les failles de logiciels malveillants de porte dérobée dans les appareils informatiques commerciaux (https://www.fbo.gov/?s=opportunity&mode=form&id=55b80a80971c739699e410584819e767&tab=core&_cview=0). Voir en particulier la section "Contexte" dans le fichier pdf vers lequel il renvoie.
@Josh - Ensuite, il y a le matériel. C'est pourquoi, pour construire mon ordinateur, j'ai commencé avec du sable pour fabriquer du silicium. Bien sûr, je n'en ai pas encore ** tout à fait ** fini ...;)
@NathanLong: Selon les informations des médias normaux, il y a au moins un pays qui travaille à développer ses propres puces, visant ainsi à être indépendant des conceptions comme celles d'Intel. Je suppose que je ne sais pas si le problème de sécurité ne pourrait finalement pas être une motivation mineure pour ce projet.
F. Hauri
2013-02-07 03:43:46 UTC
view on stackexchange narkive permalink

Malheureusement, vous ne pouvez pas ...

Comme un bon programmeur pourrait être appelé assistant par ses utilisateurs, un bon cheval de Troie serait complètement faux un environnement normal pour calmer la victime.

Certains virus / chevaux de Troie effectuent un nettoyage du système de la victime, afin

  • d'assurer un autre virus ne brisera pas son travail
  • garantira qu'un antivirus ne le trouvera pas
  • fera fonctionner correctement le système de la victime pour que la victime reste confiante.

Donc, vous ne pouvez pas !! En cas de doute, consultez !!!!

AJ Henderson
2013-02-07 03:43:59 UTC
view on stackexchange narkive permalink

Tout dépend de la confiance. Faites-vous confiance à la réputation de l'entreprise qui publie le logiciel? S'il est open source, est-il utilisé par suffisamment de développeurs pour qu'ils lèvent des drapeaux en cas de problème. Il y a une certaine force dans les nombres car un produit couramment utilisé est plus susceptible de faire l'objet de recherches approfondies pour savoir s'il est digne de confiance. Sauf si vous êtes très paranoïaque, regarder généralement ce que la communauté a à dire sur un logiciel particulier est le meilleur pari, mais il y aura toujours des bugs et il y aura toujours des erreurs.

Il convient de noter ce qui est généralement négligé en ce qui concerne les logiciels open-source: il n'y a aucun moyen technique qui garantirait qu'un programme binaire / compilé a été construit à partir exactement du code source dont il prétend avoir été construit.
@HannoBinder - c'est vrai, bien que vous ayez également la possibilité de créer votre propre version et bien que ce ne soit pas simple, si c'est bien fait, cela devrait être faisable pour un utilisateur technique limité.
Tim X
2013-02-08 03:36:01 UTC
view on stackexchange narkive permalink

Comme d'autres l'ont souligné, il n'y a pas de moyen garanti de le savoir. La plupart du temps, vous devez faire confiance à l'intégrité et à la réputation du fournisseur. Suivre des pratiques sécurisées, comme installer uniquement des logiciels à partir de sources fiables, peut vous aider, mais comme dans la vraie vie, nous faisons parfois confiance aux mauvaises personnes.

En fin de compte, je pense que nous devrions adopter un certain niveau de paranoïa. Si vous installez une application sur votre téléphone, n'acceptez pas ou ne dites pas simplement oui lorsque le système d'exploitation de votre téléphone vous informe que le téléphone souhaite accéder à vos informations privées, à votre emplacement, etc. Demandez-vous pourquoi il a besoin de cet accès. Si vous pensez que l'accès demandé par l'application est justifié en fonction de ce que vous attendez d'elle, alors dites oui peut-être OK. D'un autre côté, s'il semble demander l'accès à des informations ou à des services qui sont bien en dehors de ce dont il devrait avoir besoin ou qui l'intéresse, alors soyez un peu méfiant et réfléchissez bien avant de simplement dire oui.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...