Journal Faille de l'open-source ?

Posté par (page perso) .
Tags : aucun
0
23
jan.
2005
Bonsoir mon journal,

Je viens de tomber sur une faille (possible) de l'open source dans un raisonnement se faisant dans ma tête il y a un bon quart d'heure ...

Imaginons un protocole X implémenté par un logiciel Y sur le principe du client/serveur ou du p2p.

Si le logiciel comme le client sont à source fermés, je peux
- définir un protocole obscur
- valider le code du logiciel donc
- valider les données qu'il échange sur le réseau.

Si le même logiciel est opensource et/ou le protocole ouvert, apparaîtront
- de nouveaux logiciels implémentant ce protocole
- des versions modifiées du logiciel, n'ayant pas forcément le même comportement.

Je me suis donc demandé s'il y avait une solution algorithmique de validation de logiciel "à distance" ? Avec un logiciel libre, cela me parait impossible.

Prenons un exemple (ça n'est pas le cas que je traite, mais il est proche ...) un jeu massivement multijoueurs, distribué (pas de serveur central) et libre (protocole et source ouvert).

Comment peut-on être sur que les joueurs ne modifient pas le logiciel pour que leur joueur triche et gagne ? Une validation des actions par les autres joueurs me parait très difficile, et une validation de code ou de protocole impossible vu que tout est opensource donc connu, donc trichable ...

Cruelle question ...

Tout en écrivant ce journal, je me demande d'ailleurs si ça n'est pas un des problèmes que les systèmes p2p n'arrivent pas à régler, (les clients p2p qui trichent et monopolisent la bande passante) y compris les propriétaires (ce qui rend ce problème tout aussi insolvable) comme kazaa

des avis d'expert dans la salle ?
  • # Comment être sur de ne pas tricher

    Posté par . Évalué à 3.

    Avant tout je ne suis pas expert.

    Comment peut-on être sur que les joueurs ne modifient pas le logiciel pour que leur joueur triche et gagne ?

    De la même manière que l'on crypte les mots de passe: Avec un hash "injectif" (genre MD5)...

    J'ai bon?
    • [^] # Re: Comment être sur de ne pas tricher

      Posté par (page perso) . Évalué à 3.

      Non, parce que ca serait au logiciel de calculer son propre hash, et il pourrait toujours tricher en se faisant passer pour un autre.

      NGBSC et TCPA proposent une solution a ce problème, mais il y a des effets de bord qui ne sont pour moi pas acceptables.
      • [^] # Re: Comment être sur de ne pas tricher

        Posté par (page perso) . Évalué à 1.

        J'ai des doute... Je dirais qu'il repose sur le fait que le code soit fermé, donc c'est pas viable pour l'open source. Parceque tu casses la "chaîne de confiance" en dissociant la négociation avec le matériel de l'action.
        • [^] # Re: Comment être sur de ne pas tricher

          Posté par (page perso) . Évalué à 2.

          > Je dirais qu'il repose sur le fait que le code soit fermé

          Non, il repose sur le fait que l'executable soit signé, et que la clé secrete qui l'a signé ne soit pas divulgée.

          > c'est pas viable pour l'open source.

          C'est clair : le principe est qu'une version modifiée n'a plus acces aux fonctionnalités "sécurisées", donc, par exemple, ne peut plus s'identifier comme client officiel dans un jeu multi-joueur. Bref, en pratique, ca empêcherait de faire des versions modifiées, ce qui est contraire au principe même de l'open-source.
          • [^] # Re: Comment être sur de ne pas tricher

            Posté par (page perso) . Évalué à 2.

            Ca n'empeche pas de faire des version modifié.

            Ca empeche juste ces versions de tourner sur des serveur "officiel". Mais rien ne t'empeche de faire de nouveau serveurs et de nouveaux clients, il ne pourront alors tournées que dans un "nouveau" reseau.

            Cela peut même etre util pour eviter la surpopulation d'un "serveur" par rapport la surface virtuel du jeu.

            De même la/les personnes phisiques ou morales gerent une instance du monde peuvent validers differents clients alternatifs. Le probleme reside surtout dans le fait que tu ne peut jouer avec un client compiler à la mano.
          • [^] # Re: Comment être sur de ne pas tricher

            Posté par . Évalué à 2.

            Et comment tu garanties que c'est bien les info de l'executable en train de tourner qui est envoyé sur le réseau mais pas un executable modifier qui fait les analyses sur un copie de l'executable non modifié (et non executé) ?

            Dam
            • [^] # Re: Comment être sur de ne pas tricher

              Posté par (page perso) . Évalué à 2.

              Ben c'est le principe de NGSCB et TCPA, ca n'est possible que par la présence d'un composant hardware. Le composant hardware garde des clés (secretes) et met ses services a disposition des applications signées uniquement. Si ce n'est pas l'executable lui même, mais un autre truc, ou même l'executable lancé dans un déboggueur, il n'a pas accès aux clés.
  • # Je ne suis de loin pas un expert...

    Posté par (page perso) . Évalué à 7.

    Ceci dit, j'ai déjà un peu réfléchi à la question en rapport avec les jeux vidéos.
    Prenons un FPS (First Person Shooter = quake 3, half-life). En gros, le client envoies ses déplacements et la direction de ses tirs. Tout cela passe par le serveur.
    Une implémentation simple du serveur consisterais à simplement renvoyer aux autres clients les données reçues. Dans ce cas-là, on peut effectivement tricher facilement.
    Maintenant, le serveur peut vérifier les données du client (il stock la position précédente du client et compare avec le déplacement envoyé par le client, si c'est au-delà de la vitesse limite, il réagit).
    En prenant le problème dans l'autre sens, à savoir quelles infos le serveur envoie au client, si on prend un modèle simple dans lequel chaque client connait la position de tout les autres, alors on peut facilement faire des wallhacks (vision a travers les murs).
    Ceci dit, le serveur peut, pour chaque client, n'envoyer que les positions des joueurs que ledit client voit.
    Le seul problème, c'est que ça demande beaucoup de calcul côté serveur....

    Maintenant pour le p2p, ou il n'y a pas de serveur central, pour éviter le monopole de bande passante:
    Imaginons un client A qui est "gentil" et un client B qui tente de monopoliser la bande passante de A.(B aurait mis sa vitesse de download très haut et sa vitesse d'upload très bas)
    Quand B demande à A de lui envoyer un fichier, A peut regarder à quelle vitesse il télécharge chez B et fixer une vitesse d'envoie maximum vers B en fonction de ça.

    Voilà, je ne suis pas sûr d'avoir été très clair... et je peux très bien me tromper.
  • # Et ?

    Posté par . Évalué à 5.

    Ben, il me semble que le code source des jeux comme Quake 2 et 3 sont passés en GPL, le coté serveur comme le client. C'est pas pour autant qu'on a vu plus de aimbot fleurir sur les serveurs de jeux il me semble.

    En gros tu pronnes le "vaut mieux essayer de cacher les failles du système en fermant le code" plutôt que de chercher une méthode pour empécher efficacement toute triche de façon ouverte. Aux dernières nouvelles il existe des protocoles de cryptographie utilisant des algos connus (avec du code source libre), ce n'est pas pour autant qu'ils sont vulnérables !

    Effectivement dans le cas de logiciel massivement réparti, le contrôle est plus dur à tenir ... mais toujours faisable en identifiant par exemple quelques "serveurs" comme "de confiances".

    Je ne suis pas un spécialiste de la question, mais franchement je ne vois pas en quoi le fait d'avoir un logiciel libre puisse poser plus de problème qu'un logiciel propriétaire ! Ce n'est pour moi qu'une question (complexe) de choix d'architecture/algorithme.

    Finalement je crois que mon post ne fait que reposer ta question:), mais au moins je renie le sujet et le début de ton journal sur la possible faille du modèle Open Source sur ce point là :). Comme tu le dis à la fin, ça n'ai pas un problème de code accessible ou non.
    • [^] # Re: Et ?

      Posté par (page perso) . Évalué à 1.

      et ?

      et bien ca m'embête bien, parce qu'au final, libre ou pas, j'ai pas trouvé de solution, si ce n'est avoir quelques serveurs "de confiance" ... pas glop hein ...

      Sinon, je ne remet pas du tout en cause le modèle open source, bien au contraire ;)
    • [^] # Re: Et ?

      Posté par (page perso) . Évalué à 2.

      C'est plutôt Quake 1 ert 2 qui ont été libérés, le 3 pas encore, mais vivement qu'il le soit : sont moteur 3D déchire !

      Pour en revenir au débat principal : le fait que les sources de Quake 3 ou d'autres jeux comme Counter Strike ne soient pas disponnibles n'empêche pas de voir fleurir des aimbots et autres cracks qui permettent de tricher, loin de là.
      • [^] # Re: Et ?

        Posté par . Évalué à 1.

        En effet, il existe deja de nombreuse techniques de triche, meme avec des jeux bien proprio .
        Je me souviens encore des codes pour le minerais illimité dans starcraft...
        Ceci dit, lorsqu'on jout avec des amis, on est là pour s'amuser; et si on triche, c'est pas marrant.
        Donc on ne triche pas et c'est tout, meme si on en a la possibilité.

        ça, c'est valable pour les jeus.
        Par contre, c'est vrai que pour des applications plus critiques, ça peu être un probleme.
        • [^] # Re: Et ?

          Posté par . Évalué à 2.

          > En effet, il existe deja de nombreuse techniques de triche, meme avec des jeux bien proprio .
          > Je me souviens encore des codes pour le minerais illimité dans starcraft...

          Euuuh c'est pas vraiment la même chose dont vous parlez ! Les codes dont tu parles ont été développés par les concepteurs du jeu, alors que l'auteur du journal se demande s'il est possible d'empecher que quelqu'un ne modifie un client pour tricher.
      • [^] # Re: Et ?

        Posté par (page perso) . Évalué à 1.

        le 3 pas encore

        Certaines légendes ont la peau dure...

        ftp://ftp.idsoftware.com/idstuff/quake3/source/(...)
        • [^] # Re: Et ?

          Posté par . Évalué à 3.

          Ce que tu nous montre là, c'est le code du "jeu", pas du moteur. Si tu avais pensé à regarder les dates des fichiers, tu aurais pu remarquer qu'ils sont là depuis plusieurs années. Rien à voir, donc, avec ce que Carmack a fait pour les deux premiers volets et qu'il promet plus ou moins de faire avec le troisième.

          Avec le code source que tu nous proposes, tu ne pourras pas obtenir un binaire de quake3, tout au plus le binaire du "mod" par défaut.

          Comme quoi, la peau dure des légendes, elle sert aussi à les protéger contre les petits malins ;)
  • # Triche

    Posté par (page perso) . Évalué à 7.

    C'est un vieux débat, qui a deja eu lieu plusieurs fois ici.
    La reponse est simple: quand tu fais du code, tu dois admettre que le gars qui voudra tricher, il voit tout. Ya des trucs pour tricher pour chaque jeu proprio, et generalement quand une solution est fournie par l'editeur sous la forme de patch, les programmes de triche se mettent a jour dans les heures qui suivent. Ya aussi des tres bons papiers qui en parlent, et qui montrent bien que les tricheurs ont bien plus de ressources que l'ont ne croit...

    Conclusion, quand on code, on se debrouille un maximum pour que, meme si un méchant aurait un acces au code, qu'il en ait vraiment un (dans le cas d'un projet open source donc) ou non, il ne peut faire qu'un minimum de choses. Ca passe par des verifications diverses et variées coté serveur par exemple - dans le cas d'un jeu solo, on s'en fiche un peu -.
  • # Précisions ...

    Posté par (page perso) . Évalué à 2.

    QUELQUES PRECISIONS

    ... Bon, quelques précisions, parce que visiblement on parle surtout du thème des jeux :
    L'idée que j'ai en tête ne serait pas un jeu, mais une sorte de moteur de recherche p2p. L'idée serait excellente si le groupe de développeur par exemple, pouvait valider les clients du réseau par quelque système que ce soit, (crypto, hash, protocole...) mais je ne trouve rien de satisfaisant, si ce n'est d'avoir des clients de confiance, donc peu de clients, ou de mettre en place un système de "points de confiance" qui pourrait donc tout aussi bien être falsifié, bref, je suis un peu perdu ...

    Ou alors on part comme sur l'idée wiki : il y aura une magnitude de plus de bons clients que de mauvais, qui seront donc plus ou moins invisibles ...
  • # protocole ouvert != danger

    Posté par . Évalué à 1.

    Dans le cadre d'un MMORPG un protocole ouvert n'a aucune incidence sur la triche, tout ce que voit et fais le jouer a lieu sur le serveur, le client ne faisant qu'afficher. Si on tente de modifier un client et son protocole pour en tirer des avantages sur le serveur ça n'aboutira qu'à n'avoir des erreurs et rien d'autres.

    La première source de triche sur ce type de jeu étant l'automatisation des taches et la seconde loin derrière étant le piratage du serveur directement. Un des moyens mis en oeuvre contre ces nuisances est une vérification de l'intégrité des fichiers au démarrage du jeu

    Le principe reste le même pour les FPS où la triche se fait au niveau de l'affichage pas du protocole/serveur. Et ça, ça peut se faire sans même toucher au fichier du jeu (ex:aimbot,wallhack)

    Pareil pour les logiciels de p2p, un client de leech basé sur emule peut bloquer tout upload mais ça sera à son détriment puisque les autres clients le note selon la participation qu'il a eu à leur égard. A moins de pouvoir forcer et trifouiller dans les clients des autres usagers, le leecheur finira vite par ne rien télécharger du tout.
  • # solution possible dans les jeux distribués

    Posté par . Évalué à 2.

    Tout d'abord, il met d'avis que pour un mmo massivement distribué par
    exemple il n'y a pas de solution parfaite.

    On peut juste trouver des solutions qui marchent presque tout le temps comme par exemple la validation se basant sur les probas.

    Explication : Puisqu'il n'y a pas de serveurs, ce sont chaque client qui s'occupent de gérer une petite partie du monde. Il "suffit" alors que la même partie du monde soit gérée par plusieurs clients entrevérifiant leurs calculs .. On peut alors partir du principe que les résultats minoritaires seront alors des résultats faux.

    On peut également partir sur des architectures mixtes, par exemple pour un mmorpg, un serveur central ne gardant que les carac des persos et validant leurs augmentation etc etc et les clients qui s'occuperaient de la gestion de petit bout de monde ( deplacement, combat, etc etc ). On peut alors penser que les parties gérées par des clients tricheurs seront rapidement désertées et dénoncées par les clients non tricheurs que l'on suppose plus nombreux.

    Enfin on peut imaginer un principe "d'arbitrage". La encore ca necessite la mise en place d'un serveur arbitre. Lorsque qu'un client est connecté sur un autre client qui gere une partie de monde, le premier client vérifie épisodiquement les calculs du second, si il detecte un problème il envoit un rapport a l'arbitre.

    Une autre facon d'utiliser le principe d'arbitrage est d'utiliser un serveur qui ne serait le point d'entrée vers la grille de client gérant le monde. Tout le traffic entre les clients joueurs et les clients
    gestionnaires passerait par ce "routeur". De temps en temps, ce routeur arbitre, vérifieraient ce que font les clients gestionnaires.

    Voila ce n'était que quelques idées jetées en vrac au petit matin.

    Mais l'un des trucs qu'il ne faut pas oublier dans le cas d'une architecture répartie, c'est que si vous utilisez un arbitre central pour vérifier les calculs, la vérification étant au moins aussi couteuse que le calcul du "calcul à vérifier".... suivant le nombre de vos vérifications, l'architecture répartie perds tout son charme.
    • [^] # Re: solution possible dans les jeux distribués

      Posté par (page perso) . Évalué à 2.

      En gros on cherhe a faire un serveur distribué et donc avec plusieur points d'entrées, les clients se connectant a un ou plusieurs point d'entrée.

      Les differentes noeuds du serveurs devant assurées l'intégretité du "serveur" même si une partie de ces noeuds tombe (que se soit piratage ou simple extinction).
      On peut donc imaginé que pour un groupement de N noeuds on ait un ou plusieurs serveur referents dont le status est assuré selon plusieurs critère comme :
      - La personne qui a mis le noeud en place
      - L'uptime du serveur
      - La cooptation (i.e. se serveur n'a pas envoyer de fausses info, il est fiable, il passe en referent)

      Il est donc bon de donner des niveau de "referent" un peut dans le meme genre des chaines de confiances des cle gpg.
      Dans le cadre d'un mmorpg chaque serveur peut etre (auto)parametré (en fct des besoin) pour assurée le boulot de serveur pour une zone géographique.

      Apres il faudrait que les actions des clients soient validées par 2+ noeuds de manieres a eviter la triche. Ces noeud verifiant la validité des actions. Le fait de rendre obligatoire la validation par plusieurs serveurs par exemaple en obtenant ainsi un certain score de confiance (i.e 1 noeud top confiance suffit mais il faut plusieurs noeud avec peut de confiance pour valider) permet d'eviter les clients qui tentents d'abuser et les serveurs frauduleux.

      En effet si un client frauduleux agit, les actions ne seront pas validées.
      Si elles sont validées par un serveur frauduleux, celui ci n'ayant que peut de confiance ne sera pas pris en compte, voire meme exclu en cas de trop grand nombre de tentative de fraude.
      • [^] # Re: solution possible dans les jeux distribués

        Posté par (page perso) . Évalué à 2.

        En gros, si je me comprend bien et que j'ai pas fait d'erreur dans ma logique, pour tricher avec un systeme comme ca il faut un reseau de tricheur plus important que le reseau de valide.

        Je presise aussi qu'un noeud ne se proclame pas referent de niveau N, mais qu'il est designé (élu) conne tel par les autres.

        Il est a noter aussi qu'il faut prevoir un coté serveur et un coté client parce qu'il est fort probable que dans une archie distribué d'une structure mellant les deux (un pgm a la fois client et serveur) des parties clientes tiers apparaitront qui elles ne gereront pas le coté serveurs.
        • [^] # Re: solution possible dans les jeux distribués

          Posté par . Évalué à 2.

          oui c'est bien le principe des méthodes basées sur les principes d'élection et de validation par les autres, si tu as plus de tricheur que de non tricheur, tout ton système part en couille..

          On pourrait même imaginer qu'avec un réseau suffisamment important de tricheurs, ce seront les non tricheurs qui seront considérés comme tricheurs et seront éjectés.
          • [^] # Re: solution possible dans les jeux distribués

            Posté par (page perso) . Évalué à 2.

            Mais pour se faire il faut aussi que le reseau "tricheur" se mette en place plus vite que le reseau "non tricheur" parce que sinon les serveurs tricheurs seront evincé avant qu'il ne puissent prendre le control.

            D'ailleur c'est un coup a syndé automatiquement le jeux avec d'un coté les tricheurs et de l'autre les non tricheurs, la confiance des deux reseaux s'entre exluant. Le but etant de garder le taux de non confiance des exclus de maniere a les blacklisté.
  • # Il suffit de valider les données recues

    Posté par (page perso) . Évalué à 1.

    J'avais lu un article ( http://www.bookofhook.com/Article/GameDevelopment/MultiplayerProgramming.html ) sur la programmation de jeux en réseaux. J'avais trouvé amusant de voir que la plupart des notions utilisées dans les jeux en réseau avec une architecture distribuée (pas de serveur central) sont les mêmes que celles de l'algorithmique distribuée. (il y a des slides de cours sur http://sardes.inrialpes.fr/people/krakowia/Enseignement/DEA/SR/ - le site a l'air down, mais il est dans le cache google)

    Dans ton cas, un protocole fermé ne t'assure en rien que personne ne pourra tricher : il suffit de reverse-engineerer le proto pour pouvoir le faire. Donc tu es obligé, au niveau du serveur (s'il y en a un) ou de l'ensemble des pairs (si n'y a pas de serveur) de vérifier que les données par un client sont valides.

    Dans le cas d'un réseau pair à pair, ça peut se faire avec des algos d'élection ou de consensus. Mais en général, ca fonctionne plutot en assurant une redondance des calculs (calculer la même chose sur plusieurs noeuds, et comparer les résultats). Certains réseaux à la BOINC/Seti et cie utilisent un système de notation de noeud : plus tu envoies des résultats justes, plus il te fait confiance, et moins il revérifie.
  • # C'est pas lié au libre

    Posté par . Évalué à 3.

    Tu as exactement le même problème avec le logiciel propriétaire, même si tu peux essayer de compliquer un maximum les choses, au final c'est toujours possible de tricher par reverse engineering.

    Quoi qu'il en soit, ça se rapproche du problème qu'a eu le SETI@Home, puis les autres projets de calcul distribué. Ils ont opté pour la fermeture du code en prétendant que c'était pour s'assurer de la qualité des résultats, mais malgré tout, ils ont compris que la sécurité ne reposait pas sur l'obscurité, et ils ont choisi la seule véritable solution: faire les calculs plusieurs fois.

    Dans le cas d'un jeu en P2P, tu peux faire en sorte qu'un joueur calcule une partie du jeu "éloignée" de lui, ce qui diminue son intention de fausser les résultats. En misant sur le fait que:
    - il y a beaucoup de joueurs, donc il est difficile de rendre négligeable leur part de calcul avec de la force brute
    - il est difficile de trouver qui calcule quoi
    - tous les calculs sont fait plusieurs fois par des joueurs différents
    On obtient un truc relativement sûr.

    Maintenant si tu veux un système encore plus sûr, tu peux calculer la confiance que tu as en chaque joueur, qui dépend du nombre d'unités de calcul en "conflit" avec le résultat communément admis.

    Solution parfaite ? Non, car sans serveur centralisé c'est très compliqué à mettre en place.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.