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

Citation:

---

Envoyé par Aurelien.Regat-Barrel

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

---

J'ai pas de problème avec le fait de faire de la recherche et d'essayer de nouvelles idées. J'ai beaucoup plus de problèmes avec un papier qui n'est cité nulle part et où le seul bibtex qu'on peut avoir (sur arxiv) n'indique aucune conférence ou journal (et après avoir cherché ailleurs, il y a toujours aucune trace d'une conf/journal associé).

Et d'un point de vue validité, j'ai aussi beaucoup de problèmes avec un papier qui indique pouvoir créer des bugs " provably (but not obviously) non-exploitable" ... justement sans fournir la moindre preuve. Il n'y a rien non plus qui évalue l'impact de ces bugs "inexploitables" sur l'exploitabilité des bugs qui pourraient se trouver dans l'application avant de commencer les injections.

Citation:

---

Envoyé par Aurelien.Regat-Barrel

As-tu des outils à recommander ?

---

Pour le C :

• Frama-C
• Infer static analyzer
• Astrée
• Polyspace
• Verifast
• Microsoft VCC

Et après, on peut prendre du moins intégré et travailler un peu plus le problème à bras le corps, comme ce qui a été fait pour seL4 par exemple, ou ce qui est fait régulièrement à travers PVS Specification & Verification System, ou avec différents Model-Checkers, ou avec des assistants de preuve genre Isabelle ou Coq (pour les plus courageux).

La vérification formelle, c'est encore autre chose, il faut l'impliquer dès le début du projet, sinon c'est extrèmement compliqué à ajouter après -- comme la sécurité d'ailleurs.

Je reste persuadé, comme BufferBob, qu'un code sécurisé, clair, vérifié et validé reste la meilleure des protections. Néanmoins, il existe aussi des cas d'applications (fonctionels) qui ne sont pas courants et dans lesquels on pourrait avoir besoin d'autres pistes de sécurisation, pourquoi pas comme celle-ci. En effet, dans certains cas, les besoins peuvent nécessiter des fonctionalités qui ne sont pas applicables aux cas courant, et dans ce cas il est souvent intéressant d'avoir des pistes plus ou moins exotiques.

Celà voudrait dire que... Microsoft est visionnaire? :ptdr:


J'aimerai quand même qu'on teste la performance d'un code rempli de leurres de ce type.
Puisque tout code exécuté prend du temps et de l'énergie; pas sûre qu'une appli sécurisée de la sorte ne soit ni green, ni rapide à exécuter.

Enfin on sait bien que l'idée d'un code performant est abandonné depuis belle lurette (il n'y a qu'à voir les langages à la mode maintenant 8O )

Le papier du projet LAVA (Large-scale Automated Vulnerability Addition) mentionne qu'il ne produit que des buffers overflow. Cela est suffisant à un attaquant pour déclencher une attaque ROP (Return Oriented Programming) en écrasant l'adresse retour dans la pile par une ROP-chain. De plus, l'article nous informe que LAVA introduit des bugs non intentionnels concernant des pointeurs (déférencement de pointeur et use-after-free).
A défaut de corriger le programme, LAVA rajoute des bugs volontaires ou non... :bravo: Pour les supprimer, les chercheurs du projet LAVA ont dû utiliser des outils de détections de vulnérabilités :mouarf: puis ils ont supprimé ces vulns :mouarf:. Ne suffisait-il pas d'utiliser directement les outils de détection de vulns sans en introduire de nouvelles avec LAVA ? :calim2:

Aujourd'hui, les techniques de recherches de vulnérabilité sont automatisées, on utilise du fuzzing, du monitoring d'application, de l'instrumentation du binaire (ou du noyau de l'OS). On peut utiliser également de l'exécution symbolique avec MIASM (merci Serpi !) ou angr. Il suffit au chercheur de vulns de trouver un seul bug exploitable dans le code original (ou code LAVA :D).

LAVA ne supprime pas les bugs mais en ajoute (au pire sans le vouloir). En plus, il faut de toute façon faire une recherche de vulns classique après avoir utilisé LAVA...

Le problème est qu'il faut bien justifier le travail réalisé et publier (sinon adieu les futurs budgets) même si au final cela n'est pas utile. Dure loi de la recherche académique.

Citation:

---

Envoyé par Alvaten

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.

---

J'adore cette analogie avec la porte. Ça s'est vu mainte et mainte fois, une porte avec 3 verrous différents, et les cambrioleurs s'attaquent aux charnières, voire à la cloison en placo à coté qui se découpe au cutter.