Developpez.com

Le Club des Développeurs et IT Pro

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

Suggèrent des chercheurs

Le 2018-08-08 05:11:45, par Patrick Ruiz, Chroniqueur Actualités
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.


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.


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
  Discussion forum
24 commentaires
  • setni
    Membre averti
    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!
  • Envoyé par captaindidou
    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.
  • BufferBob
    Expert éminent
    Envoyé par gangsoleil
    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.
  • CoderInTheDark
    Membre émérite
    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
  • Saverok
    Expert éminent
    Envoyé par setni
    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é.
  • arnaud33210
    Candidat au Club
    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.
  • Alvaten
    Membre éprouvé
    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.
  • hotcryx
    Membre extrêmement actif
    Je ne suis pas convaincu par leur technique.
    C'est une grosse perte de temps...
  • KsassPeuk
    Membre confirmé
    Envoyé par Patrick Ruiz
    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.
  • 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.