CaptainDangeax a écrit :



C’est le principe du “if it ain’t broken, don’t fix it” qui fonctionne bien dans la plupart des cas. Pour prendre un exemple automobile, les voitures des années 1990 étaient globalement fiables, puis début 2000, les constructeurs ont voulu améliorer en mettant en place le multiplexage (faire passer plusieurs signaux par un seul fil) et là bonjour les catastrophes ! Ça fonctionnait bien avant, pourquoi changer ? C’est pour le progrès et puis ça fait économiser du cuivre ! Donc l’industrie est frileuse et évite de toucher à quelque chose qui fonctionne, jusqu’à ce qu’il casse ou que le progrès propose quelque chose de vraiment meilleur. D’où la correction de la faille.





Le problème, c’est quand le code est écrit en fortran ou cobol, heureusement que ça ne plante pas, sinon il sera nécessaire de se mettre d’abord à la nécromancie pour trouver une personne capable d’y retoucher.

Kixtea a écrit :



C’est pitoyable d’avoir de telles failles …







J’ai envie de dire que ce genre de faille est normal. Ca ne te viens pas spécialement à l’idée de perdre du temps à faire un code blinder contre les attaques si ce code gère uniquement des police de caractère.

Je ne sais pas si tu te rends compte de la complexité nécessaire pour imaginer et tester tous les cas possibles ? C’est rarement fait, tout au plus, on en teste une poignée de cas qui nous semble critique et si ça passe, c’est valide.

Du coup, oui, le nombre de faille augmente avec la complexité du code et des possibilités d’usages.

raphke a écrit :



Je pense que c’est justement ça qui fait peur

 

 ”Quelques” (même si ils ont nombreux) ce n’est pas assez.

 J’espère que le code (et autres) va s’améliorer pour les voyages lointains dans l’espace car là le nombre de cas pour te plomber l’ambiance va crescendo ^^





Alors là, on est dans un autre genre de code. Déjà les codes sont généralement vérifié, voir si c’est possible prouvé comme infaillibles. Du coup, en particulier dans l’aviation (et les banques) il n’est pas rare d’avoir des réactions du genre “ce code fonctionne, ça fait 30ans qu’il n’a jamais faillie, on n’y touche surtout pas !”

Pour les missions spatiales, j’ai eux aussi vent d’une histoire de 3 codes différents, 2 travaillant en parallèle et si ils ne donnent la même réponse à un moment donné, le 3ième joue le rôle d’arbitre.

Edtech a écrit :



C’est complètement décorrélé des droits d’exécution. C’est un code qui s’incruste en mémoire et se fait exécuter à travers autre chose. Aucun rapport !





C’est pas le principe de la VM et des langages interprétés ? Je suis sûr qu’il est possible d’écrire un code bash qui va faire exécuter du bash contenu dans un fichier non exécutable (lire le texte, le coller dans une variable et interprété la variable).



Sinon, pour la police de caractère, on peut effectivement imaginer la présence d’un composant de programmation pour avoir une police (manuscrite ?) “dynamique”, qui ne va pas utiliser le même ‘e’ si la lettre précédente était un ‘a’ (trait bas) ou un ‘o’ (trait en haut) ou tout simplement changer légèrement les glyphes pour une même lettre pour casser la monotonie.

Kalariel a écrit :



On m’a donné des bases de fortran dans mon iut Génie Chimique… ya que 3 ans de ça





J’ai entendu parler de cette tribu de physicien et de chimiste qui utilise encore du Fortran.









js2082 a écrit :



Non, justement, ce n’est pas normal qu’une faille dans les polices de caractère puissent faire tomber la sécurité de ta machine. On parle de police de caractère là, pas de firewall ou d’accès réseau: on voudrait le faire exprès qu’on ne ferait pas mieux.

 



Je dirais même plus c’est de la connerie pure. Je ne sais pas comment la chose a été programmée mais en arriver là, c’est que la base logique de la programmation est très mal conçue.



 Comparaison bagnolesque: c’est comme si ta voiture tombait en panne en raison d’une tache sur le siège du conducteur. Le genre de truc qui n’a aucun lien, aucun rapport.







Justement, c’est parce que ce code semble tellement anodin qu’il n’a pas été aussi sécurisé.







Nikodym a écrit :



C’est le process de production de code qui est à revoir.

Ce qui me fait marrer, c’est les “développeurs web” qui se mettent à faire de l’XP sans connaitre quoi que ce soit au développement. Dans la plupart des cas le TDD (notion que je déteste soit dit en passant) que j’ai vu était d’une totale aberration, qui donnait une fausse impression de sûreté/sécurité au développeur.



Simplement, faire du code sûr, c’est faire du code prouvé, en donnant en plus les complexités moyennes mémoire et temps et les variances, ce qui n’est pas facile en langages impératifs, mais d’un autre côté les langages fonctionnels et récursifs ne sont pas maîtrisés par les développeurs payés au lance-pierre. Développeurs qui par ailleurs ne sont pas familiers avec la notion mathématique de preuve.



Je conçois très souvent du code prouvé (en C/C++ ou Scheme/Lisp), mais même comme ça, je ne suis jamais à l’abri d’une mal-façon (on s’en rend compte très rapidement, de toute façon, les lapsus dans le code et autres joyeusetés), mais on ne trouvera pas de failles de sécurité dans mon code. " />





Ce n’est pas parce qu’un code est récursif qu’il est facilement prouvable. L’exemple classique est la conjecture de Syracuse.



syracuse(entier x) :

….si x = 1 return

….fin si

….si x pair : return f(x)/2

….sinon : return f(x)*3+1

….fin si



Difficile de prouver que cette fonction finisse quelque soit x, x>0.