IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Affichage des résultats du sondage: L’introduction de faux bogues pour le renforcement de la sécurité d’une application ...

Votants
14. Vous ne pouvez pas participer à ce sondage.
  • est une méthode à explorer à fond par les industriels

    2 14,29%
  • n'a aucune chance de devenir un standard de l'industrie

    9 64,29%
  • Autres, à préciser

    3 21,43%
Sécurité Discussion :

Il faut truffer une application de milliers de faux bogues pour en augmenter la sécurité


Sujet :

Sécurité

  1. #1
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Redacteur web
    Inscrit en
    Février 2017
    Messages
    1 834
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Redacteur web
    Secteur : Communication - Médias

    Informations forums :
    Inscription : Février 2017
    Messages : 1 834
    Points : 51 343
    Points
    51 343
    Par défaut Il faut truffer une application de milliers de faux bogues pour en augmenter la sécurité
    Il faut truffer une application de milliers de faux bogues pour en augmenter la sécurité
    Suggèrent des chercheurs

    Dans l’actuelle industrie du logiciel, la sécurisation des applications passe par la recherche et l’élimination des bogues ou par l’introduction d’artifices destinés à rendre ces derniers plus difficiles à exploiter. Des chercheurs de l’université de New York ont décidé de procéder d’une tout autre manière. Ils ont une idée qui fait sens même si elle a l’air d’une blague : il suffit de truffer une application de milliers de faux bogues pour en augmenter la sécurité.

    Dans le flux de travail du pirate informatique, la phase de tri (destinée à évaluer l’exploitabilité des bogues) s’en trouve donc considérablement rallongée. « L’espoir est que les attaquants s’ennuient, se sentent submergés ou manquent de temps ou de patience dans leur processus de recherche d’une véritable vulnérabilité », écrit Motherboard.

    « On arrive ainsi à augmenter considérablement l’effort d’obtention d’un exploit fonctionnel puisqu’il est difficile pour les chercheurs de déterminer d’avance que les faux bogues ne sont pas fonctionnels », écrivent les chercheurs.

    La manœuvre se justifie dans une industrie où les développeurs d’exploit sont rares et très pointilleux sur le temps qu’ils mettent à atteindre leurs objectifs. Aussi, tout moyen de le leur gaspiller est de nature à produire un fort effet dissuasif.

    Nom : workflow.png
Affichages : 5620
Taille : 75,1 Ko

    Les chercheurs proposent un outil d’automatisation du processus d’injection de bogues. Ce dernier est une extension d’un autre programme développé en interne pour l’insertion de bogues à des applications développées en faisant usage des langages C et C++. Grosso modo, leur système permet de mettre les attaquants sur des pistes non exploitables de dépassement de pile et de heap. La technique employée dans le développement de ce logiciel s’appuie sur l’hypothèse de départ que l’attaquant n’aura accès qu’au binaire de l’application pour laquelle il cherche à développer un exploit. « Cela veut dire que notre stratagème ne peut être utilisé pour la protection des applications open source », précisent-ils.

    Nom : stack overflow.png
Affichages : 5259
Taille : 9,3 Ko

    La non-exploitabilité des faux bogues constitue elle-même une question épineuse. En effet, en cherchant à confondre l’attaquant avec une panoplie de vulnérabilités non exploitables, on pourrait plutôt lui offrir un système entier sur un plateau en or. Dans tous les cas, les chercheurs reconnaissent que leur méthode est encore frappée par plusieurs limitations : manque de diversité des bogues à injecter, nécessité d’entrer en possession du code source de l’application à protéger, etc.

    « Je pense néanmoins qu’il s’agit d’une approche qu’il vaut la peine d’explorer à fond, car elle pourrait s’avérer pratique dans certains environnements », rapporte Motherboard des propos d’un des chercheurs.

    L’outil a fait l’objet de tests sur le serveur web nginx et le codec flac. Dans le premier cas, les chercheurs ont procédé à l’introduction d’un total de 864 bogues dont 54 de dépassement de pile (et 810 de débordement de heap). Pour ce qui est du codeur-décodeur, l’équipe de recherche a introduit 500 bogues de dépassement de pile et 500 de débordement de tas. Ces essais ont révélé une autre faiblesse de l’outil d’automatisation de l’équipe de recherche. Pour le moment, les bogues insérés s’appuient sur des techniques qui permettent aux outils de tri disponibles sur le marché de les classer comme exploitables.

    Source : Motherboard

    Et vous ?

    Que pensez-vous de l'approche de ces chercheurs ?

    Voir aussi :

    Un bogue affectant Chrome et Firefox permet le spoofing de la barre d'adresse afin de faciliter des attaques d'hameçonnage

    Facebook désigne un bogue comme responsable de l'enregistrement des vidéos non publiées sur sa plateforme et promet de les supprimer

    Google dévoile un bogue dans Windows 10 que Microsoft a corrigé partiellement qui affecte Windows 10 Fall Creators Update

    Les correctifs du bogue « Memory Leak » sur GNOME Shell sont disponibles et seront embarqués dans la version 3.28 de l'environnement de bureau

    Android 8.0 Oreo : un bogue entraîne la consommation de données mobiles même en étant sous Wi-Fi, Google prépare un correctif
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre expérimenté
    Profil pro
    Ingénieur système Linux N3
    Inscrit en
    Juillet 2008
    Messages
    416
    Détails du profil
    Informations personnelles :
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur système Linux N3

    Informations forums :
    Inscription : Juillet 2008
    Messages : 416
    Points : 1 517
    Points
    1 517
    Par défaut trop marrant
    Bahahaha, trop marrant. Rendre les applications closed source encore plus bugguées pour qu'elles soient plus difficiles à pirater et en même temps plus difficiles à tester, à maintenir et à intégrer . Et programmer proprement comme dans le monde opensource, vous y avez pensé ? Et dire que je me prends des votes négatifs pour cette contribution. Serais-je stigmatisé par une horde de mauvais programmeurs qui ne sont pas en vacances à la plage ?

  3. #3
    Membre averti

    Homme Profil pro
    Développeur Web
    Inscrit en
    Janvier 2014
    Messages
    153
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Janvier 2014
    Messages : 153
    Points : 316
    Points
    316
    Par défaut
    En fait, le débat est déjà clos

    Dans l'industrie et autres grands comptes à la ramasse, les devs sont soumis à des budgets tellement serrés et ridicules par rapport aux besoins qu'ils n'ont pas d'autre choix que de construire des apps à moitier finies et complètement boggées.

    Problem solved, next!
    Ma plateforme de formations digitales (développement Web, cybersécurité, SEO, Marketing digital)

    https://monformateurindependant.com

  4. #4
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2007
    Messages
    2 161
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2007
    Messages : 2 161
    Points : 7 953
    Points
    7 953
    Par défaut
    Citation Envoyé par setni Voir le message
    En fait, le débat est déjà clos

    Dans l'industrie et autres grands comptes à la ramasse, les devs sont soumis à des budgets tellement serrés et ridicules par rapport aux besoins qu'ils n'ont pas d'autre choix que de construire des apps à moitier finies et complètement boggées.

    Problem solved, next!
    Sauf que les bugs ne sont pas maîtrisés et probablement exploitable.
    Là, les chercheurs proposent de mettre en place des leurres ce qui est assez judicieux car très exploités dans l'armée depuis des siècles.

    Lors de la seconde guerre mondiale, par exemple, les anglais avaient déployé au sol tout un tas de faux chars et avions gonflables pour tromper les bombardements allemands et ça a plutôt bien fonctionné.

  5. #5
    Inactif  
    Profil pro
    Inscrit en
    Août 2008
    Messages
    238
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2008
    Messages : 238
    Points : 620
    Points
    620
    Par défaut
    C'est une idée originale mais si saugrenue.

    Merci pour la maintenabilité !
    Sans même parler de la robustesse. Et les soucis d'intégration ? : le bogue peut faire ricochet sur la vulnérabilité d'un composant logiciel client.

    Vous en avez d'autres comme celle-là pour me faire passer une bonne soirée ?

    Bref, je ne trouve pas cela bien sérieux.

  6. #6
    Membre expérimenté
    Profil pro
    Ingénieur système Linux N3
    Inscrit en
    Juillet 2008
    Messages
    416
    Détails du profil
    Informations personnelles :
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur système Linux N3

    Informations forums :
    Inscription : Juillet 2008
    Messages : 416
    Points : 1 517
    Points
    1 517
    Par défaut Oui, mais non
    Citation Envoyé par Saverok Voir le message
    Sauf que les bugs ne sont pas maîtrisés et probablement exploitable.
    Là, les chercheurs proposent de mettre en place des leurres ce qui est assez judicieux car très exploités dans l'armée depuis des siècles.

    Lors de la seconde guerre mondiale, par exemple, les anglais avaient déployé au sol tout un tas de faux chars et avions gonflables pour tromper les bombardements allemands et ça a plutôt bien fonctionné.
    Il faudrait voir à ne pas confondre des leurres qui ne peuvent en aucun cas remplacer ce qu'ils doivent remplacer, et des produits rendus sciemment défectueux, et vendus en plus.

  7. #7
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2007
    Messages
    2 161
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2007
    Messages : 2 161
    Points : 7 953
    Points
    7 953
    Par défaut
    Citation Envoyé par CaptainDangeax Voir le message
    Il faudrait voir à ne pas confondre des leurres qui ne peuvent en aucun cas remplacer ce qu'ils doivent remplacer, et des produits rendus sciemment défectueux, et vendus en plus.
    L'étude n'a jamais indiqué qu'il fallait dégrader les fonctionnalités de l'appli et encore moins l'expérience utilisateur.
    Il est question de tromper le reverse engineering avec des fausses pistes de bug.
    Le terme de leurre n'est pas utilisé mais c'est bien de cela qu'il s'agit.

    Ce qu'ils proposent est un peu la même chose que la compression du code JS pour la partie front des sites web.
    Le but est de rendre le code illisible pour un humain et ainsi, limiter son exploitation frauduleuse.
    Par contre, tout comme la compression JS, ça peut compliquer la maintenance.

  8. #8
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par captaindidou Voir le message
    C'est une idée originale mais si saugrenue.

    Merci pour la maintenabilité !
    Sans même parler de la robustesse. Et les soucis d'intégration ? : le bogue peut faire ricochet sur la vulnérabilité d'un composant logiciel client.

    Vous en avez d'autres comme celle-là pour me faire passer une bonne soirée ?

    Bref, je ne trouve pas cela bien sérieux.
    QUID d'intégrer la "bug-factory" dans un cycle de CI ? Lorsque c'est possible, bien sur. Mais cela permet de conserver un code source "clean", puis d'en produire une version sale/leurrée.

  9. #9
    Candidat au Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Novembre 2014
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Novembre 2014
    Messages : 1
    Points : 3
    Points
    3
    Par défaut
    J'ai lu une énorme connerie dans les commentaires.

    En je la minification n'est pas là pour rendre le code illisible mais pour optimiser le temps de chargement.
    Il existe de nombreux outils pour deminifier un js.

  10. #10
    Expert éminent Avatar de BufferBob
    Profil pro
    responsable R&D vidage de truites
    Inscrit en
    Novembre 2010
    Messages
    3 035
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : responsable R&D vidage de truites

    Informations forums :
    Inscription : Novembre 2010
    Messages : 3 035
    Points : 8 400
    Points
    8 400
    Par défaut
    Citation Envoyé par Patrick Ruiz Voir le message
    « Cela veut dire que notre stratagème ne peut être utilisé pour la protection des applications open source »
    on dirait du storytelling pour geeks tellement c'est idiot, on nous dit en clair "ça sécurise un peu plus le binaire si personne a le code source" (sachant que la sécurité par l'opacité n'est pas valable)

    est-ce que les entreprises vont mettre du pognon là dedans ? qui sait... on est plus à ça près m'est avis

    reste que c'est un aveu assez clair nullité pour les développeurs concernés, et je rejoins CaptainDangeax là dessus (au moins sur le fond de sa remarque), d'un coté il y a les dev opensource qui font des efforts pour coder plus propre/plus safe, et de l'autre il y a le dev moyen à qui on demande de moins en moins de choses, qu'on paye de moins en moins cher, et qui ne verra pas arriver la brouette de l'automatisation

    en gros non seulement on met la poussière sous le tapis, mais en plus on multiplie les tapis maintenant, super.

    si à l'arrivée on se rendait compte que les leurres dans le binaire font de bons gadgets ce serait d'autant plus comique.

  11. #11
    Membre éclairé Avatar de Matthieu76
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Mars 2013
    Messages
    568
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2013
    Messages : 568
    Points : 890
    Points
    890
    Par défaut
    Encore une actualité Trolldi ?

  12. #12
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Manager / Cyber Sécurité
    Inscrit en
    Mai 2004
    Messages
    10 149
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Manager / Cyber Sécurité

    Informations forums :
    Inscription : Mai 2004
    Messages : 10 149
    Points : 28 116
    Points
    28 116
    Par défaut
    Citation Envoyé par BufferBob Voir le message
    reste que c'est un aveu assez clair nullité pour les développeurs concernés, et je rejoins CaptainDangeax là dessus (au moins sur le fond de sa remarque), d'un coté il y a les dev opensource qui font des efforts pour coder plus propre/plus safe, et de l'autre il y a le dev moyen à qui on demande de moins en moins de choses, qu'on paye de moins en moins cher, et qui ne verra pas arriver la brouette de l'automatisation

    en gros non seulement on met la poussière sous le tapis, mais en plus on multiplie les tapis maintenant, super.
    Je pense que vous n'avez pas compris l'article : il ne s'agit pas de rendre le code sale, ou bien de mettre volontairement, et de manière automatique, des bugs dans une appli. L'exemple donné dans l'article est assez parlant -- mais encore faut-il prendre le temps de lire l'article.

    Quant à opposer développeur open-source et closed-source, je ne vois vraiment pas ce que ça vient faire dans le débat : on parle ici d'ajouter une étape automatique dans la chaîne de compilation, rien à voir avec le fait que le code soit comme-ci ou comme-ça.
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  13. #13
    Membre éprouvé Avatar de Alvaten
    Homme Profil pro
    Développeur Java / Grails
    Inscrit en
    Novembre 2006
    Messages
    324
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur Java / Grails
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2006
    Messages : 324
    Points : 1 023
    Points
    1 023
    Par défaut
    C'est un peu le principe du pot de miel. Ca sert surtout à identifier les attaquants et pas à protéger directement son système.

    C'est un peu comme installer 10 fausses serrures sur une porte pour qu'un cambrioleur perde du temps à savoir laquelle fracturer. Je suis vraiment pas sur sur résultat, celui qui voudra entrer prendra le temps qu'il faut pour cela. Ca va faire une belle jambe à mes client de savoir que mon appli a été hacké par quelqu'un qui à mis 2 jours ou un mois à entrer. Peut être que ca va décourager certains, mais celui qui veut vraiment entrer y arrivera, sans compter que même si tous les attaquant se contente de 1 essai, il y a sur le nombre certains qui vont tomber dessus directement.

  14. #14
    Expert éminent Avatar de BufferBob
    Profil pro
    responsable R&D vidage de truites
    Inscrit en
    Novembre 2010
    Messages
    3 035
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : responsable R&D vidage de truites

    Informations forums :
    Inscription : Novembre 2010
    Messages : 3 035
    Points : 8 400
    Points
    8 400
    Par défaut
    Citation Envoyé par gangsoleil Voir le message
    il ne s'agit pas de rendre le code sale, ou bien de mettre volontairement, et de manière automatique, des bugs dans une appli.
    Citation Envoyé par Patrick Ruiz Voir le message
    Des chercheurs de l’université de New York (...) ont une idée (...): il suffit de truffer une application de milliers de faux bogues pour en augmenter la sécurité.
    je vois pas même pas d’ambiguïté perso.




    Citation Envoyé par gangsoleil Voir le message
    L'exemple donné dans l'article est assez parlant -- mais encore faut-il prendre le temps de lire l'article.
    ah ben je veux bien que tu me l'explique c'est peut-être ça que je n'ai pas compris, pour moi il n'y a aucun exemple dans l'article, à peine un schémas de stack frame sans annotation particulière, au mieux on peut y voir le principe d'un stack overflow mais on est pas plus avancé

    mais on peut cogiter un peu :

    Citation Envoyé par Patrick Ruiz Voir le message
    Grosso modo, leur système permet de mettre les attaquants sur des pistes non exploitables de dépassement de pile et de heap
    en clair le but est de lever pleins de segfault pour faire perdre le bénéfice d'un fuzzer, sauf que ça soulève tout un tas de questions (à priori traitées dans l'article que je n'ai pas lu)

    on peut citer la source (Motherboard) :
    Dolan-Gavitt said that because of its many limitations, it probably isn’t a method that will see widespread use anytime soon, and it might never be practical.



    Citation Envoyé par gangsoleil Voir le message
    Quant à opposer développeur open-source et closed-source, je ne vois vraiment pas ce que ça vient faire dans le débat
    Citation Envoyé par Patrick Ruiz Voir le message
    La technique employée dans le développement de ce logiciel s’appuie sur l’hypothèse de départ que l’attaquant n’aura accès qu’au binaire de l’application pour laquelle il cherche à développer un exploit. « Cela veut dire que notre stratagème ne peut être utilisé pour la protection des applications open source », précisent-ils.
    Citation Envoyé par https://motherboard.vice.com/en_us/article/43p7dm/software-chaff-bugs-could-make-it-more-secure
    To name a few of those limitations: It can’t be used on open-source software

  15. #15
    Membre extrêmement actif
    Profil pro
    Développeur
    Inscrit en
    Mars 2012
    Messages
    1 969
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : Mars 2012
    Messages : 1 969
    Points : 3 375
    Points
    3 375
    Par défaut
    Je ne suis pas convaincu par leur technique.
    C'est une grosse perte de temps...
    Si la réponse vous a aidé, pensez à cliquer sur +1

  16. #16
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Manager / Cyber Sécurité
    Inscrit en
    Mai 2004
    Messages
    10 149
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Manager / Cyber Sécurité

    Informations forums :
    Inscription : Mai 2004
    Messages : 10 149
    Points : 28 116
    Points
    28 116
    Par défaut
    Merci pour la précision sur l'open-source, j'étais passé à côté.

    Pour ce qui est de l'intérêt, je maintiens que la piste est, à mon avis, intéressante, et il ne faut pas la rejeter parce que le principe est différent de ce qui existe aujourd'hui. Il ne faut pas oublier que toutes les attaques ne sont pas le fait de professionnels qui prendront tout leur temps parce qu'ils veulent rentrer à tout prix, mais il y a aussi pleins de hacker en herbe qui utilisent des outils pour trouver des failles potentielles. Et dans ce cas précis, voir qu'un logiciel a 500 failles potentielles peut les emmener sur une fausse piste, et les faire abandonner.

    Est-ce suffisant pour autant ? Bien sûr que non. Pour reprendre l'image des (fausses) serrures ajoutées sur une porte, nous sommes bien d'accord sur le fait que si la fenêtre est ouverte, ou si les murs sont en carton, cette sécurité supplémentaire est inutile.
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  17. #17
    Expert éminent Avatar de BufferBob
    Profil pro
    responsable R&D vidage de truites
    Inscrit en
    Novembre 2010
    Messages
    3 035
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : responsable R&D vidage de truites

    Informations forums :
    Inscription : Novembre 2010
    Messages : 3 035
    Points : 8 400
    Points
    8 400
    Par défaut
    Citation Envoyé par gangsoleil Voir le message
    la piste est, à mon avis, intéressante, et il ne faut pas la rejeter parce que le principe est différent de ce qui existe aujourd'hui.
    ça tombe bien, c'est pour une toute autre raison que je la rejette; on cherche à coller la poussière sous le tapis, à dissuader le reverser plutôt que s'assurer que le code est propre, c'est un problème.

    il y a 20 ans quand on condamnait Serge Humpich à de la prison pour avoir trouvé une vulnérabilité dans la puce T2G, on estimait que c'était de nature à dissuader celui qui voudrait faire pareil, finalement c'est précisément sous l'élan du full disclosure et des succès de l'opensource en matière de sécurité que les décideurs ont commencé à prendre la sécurité informatique au sérieux et qu'on a commencé à mettre de l'argent dedans

    d'un point de vue technique ça casse pas des briques, mais c'est surtout d'un point de vue politique/éthique que ça me pose problème en l'occurrence; ça ne va pas dans la bonne direction.

  18. #18
    Membre confirmé Avatar de KsassPeuk
    Homme Profil pro
    Ingénieur Chercheur
    Inscrit en
    Juillet 2013
    Messages
    138
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur Chercheur
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2013
    Messages : 138
    Points : 635
    Points
    635
    Par défaut
    Citation Envoyé par Patrick Ruiz Voir le message
    Que pensez-vous de l'approche de ces chercheurs ?
    Que le papier n'a été publié nulle part, donc je doute qu'il y ait eu la moindre review par les pairs dessus, et vous le faites probablement mousser sans aucune raison.

    Aujourd'hui montrer qu'un logiciel ne contient plus de :
    • de runtime error, c'est possible mais très dur,
    • de bugs fonctionnels, c'est possible à condition d'avoir une spec formelle, mais extrêmement dur

    Alors introduire des bugs et montrer qu'ils ne pètent pas la sémantique du code et sont inexploitables : LOL. D'autant que le papier contient 0 formalisation donc je vois pas quelle confiance accorder à leur outil.

    Et merde : on se met dans quel contexte ? Celui d'un programme qui contient des bugs donc on en introduit d'autres pour rendre la tâche plus difficile ? C'est quoi le suppositions réelles de l'outil ? Non parce que si le code contient un undefined behavior (ce qui représente la vaste majorité des bugs en C), il se passe quoi quand je combine ça avec d'autres bugs ? Je préserve quoi comme sémantique avec l'outil quand j'injecte des bugs puisque le programme n'a pas de sémantique ?

    Si on veut plus voir des bugs à la con dans du soft, on peut se baser sur des langages qui donnent des garanties de safety, ou alors se bouger et faire une vérification de validité sur du code.

  19. #19
    Expert éminent sénior

    Homme Profil pro
    pdg
    Inscrit en
    Juin 2003
    Messages
    5 749
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : pdg

    Informations forums :
    Inscription : Juin 2003
    Messages : 5 749
    Points : 10 666
    Points
    10 666
    Billets dans le blog
    3
    Par défaut
    C'est dingue l’agressivité que déclenche ce papier... Ces sont juste des chercheurs qui font leur boulot d'explorer des pistes qui n'ont jamais été explorées jusqu'ici. Pour info il est là :
    https://arxiv.org/pdf/1808.00659.pdf

    Il faut être un minimum familiarisé avec comment un attaquant s'y prend pour analyser un binaire afin de localiser des failles potentielles. L'idée est d'augmenter le nombre de faux positifs de façon considérable pour le décourager. C'est pas totalement stupide comme sujet de recherche !

    Précisons que leur outil effectue une modification automatisée du code source, donc aucun impact sur la maintenabilité du code originel. C'est le même principe que les obfuscateurs de code, raison pour laquelle ça "marche pas" avec l'open source : simplement parce que l'attaquant va travailler avec la version non offusquée de l'appli vu qu'il a accès à son source.

    Bon après de ce que j'ai vu c'est quand même très orienté langage C et pas vraiment C++. D'ailleurs ils ont testé leur outil sur des projets écrits en C (nginx, libFLAC).

    Citation Envoyé par KsassPeuk Voir le message
    on veut plus voir des bugs à la con dans du soft, on peut se baser sur des langages qui donnent des garanties de safety, ou alors se bouger et faire une vérification de validité sur du code.
    As-tu des outils à recommander ?

  20. #20
    Membre émérite

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Octobre 2013
    Messages
    1 062
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Octobre 2013
    Messages : 1 062
    Points : 2 561
    Points
    2 561
    Par défaut
    Juste concernant la 2ème guerre mondiales, les faux chars en caoutchouc ont été utilisé dans le cade d'une opération plus vaste, "Fortitude".
    Il s'agissait d'une vaste opération d'intoxication visant à faire croire aux nazis que les alliées débarquerait dans le nord de la France Pas-de-Callais pour détourner l'attention de la Normandie
    Même un port avait été construit pour conforter les services de renseignements de l'axe.
    Et ces faux chars ont fait croire à une armée prépositionnée
    Pendant longtemps l'état major a cru que le débarquement en Normandie était une mystification, et avait mis des troupes en réserves loin du front
    La question est en quoi une telle approche va tromper les hackers ?
    Les hackers ne sont pas toujours des virtuoses techniques, il y en a, mais la plus part du temps ils agissent par opportunisme.
    En tout cas c'est mon avis.
    Pour quoi crocheter une serrure si la porte est ouverte ?
    La beauté du geste technique ?
    Je n'y crois pas.
    Ca peut bloquer ceux qui travaille qu'avec les rapports de failles
    Ils vont tester les failles une à une, mais s'ils utilisent un outils ça ne sera pas si chronophage

    De toute façon je pense que ça pose plus de problème que ça en résoud
    Il faut documenter et commenter les bogues, car il y aura quelqu'un pour les corriger.
    Déjà que la doc est pas à jour.
    Même si le code n'est pas open source, la documentation des bogues peu fuiter

    Et puis en introduisant un faux bogue on peut en insérer un vrai
    Et ça peut dégrader les performances, d'est du code qui sera exécuter pour rien
    Et c'est du code à maintenir aussi

    C'est une technique du passé.
    Pour pirater les jeux dans les années 80 et 90 on passait par des éditeur de secteurs.
    Par exemple les jeux protéger par mot de passe, on rentrait dans le code et on changeait tous les mot de passes par un mot de passe unique, car ils étaient en claire.
    Personnellement c'est la seul technique que je savais exploiter avec un éditeur de secteurs.
    Car faire sauter les protections dans le code avec un éditeur de secteur était une technique très compliquée et surtout très fastidieuses

    Mais ça me fait penser à une technique d'intoxication de l'époque, les programmeurs de jeux un peu plus malins mettaient plusieurs protection une facile que les pirates faisait sauter et une plus compliquer qui agissait plus loin dans le jeux.
    Comme ils ne testaient pas le jeux en profondeur pour être les premiers à le distribuer avec leur intro
    On se retrouvait a jouer à un jeux et à être bloqué , et si on était vraiment accros on achetait le jeux
    Par exemple Dragon's Lair a posé des problèmes aux pirates de l'époque car les protections étaient éparpillées et mélanger aux code du jeux

    pour moi au final cela pose plus de problème que ça en règle
    Consultez mes articles sur l'accessibilité numérique :

    Comment rendre son application SWING accessible aux non voyants
    Créer des applications web accessibles à tous

    YES WE CAN BLANCHE !!!

    Rappelez-vous que Google est le plus grand aveugle d'Internet...
    Plus c'est accessible pour nous, plus c'est accessible pour lui,
    et meilleur sera votre score de référencement !

Discussions similaires

  1. Réponses: 0
    Dernier message: 07/03/2012, 16h30
  2. Réponses: 5
    Dernier message: 11/12/2009, 13h20
  3. Que faut-il pour une applic sur PC sans Acc
    Par rlejeune dans le forum Modélisation
    Réponses: 5
    Dernier message: 05/10/2009, 15h03
  4. [Kylix] Execution d'une application hors de l'edi
    Par Sadam Sivaller dans le forum EDI
    Réponses: 1
    Dernier message: 20/04/2002, 23h22
  5. Réponses: 2
    Dernier message: 15/04/2002, 12h56

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo