Microsoft corrige une faille critique affectant l’ensemble des Windows

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.

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.

Nikodym a écrit :



En scheme :

(define (syracuse x)

__(if (odd? x)

____(syracuse (+ (* 3 x) 1))

____(syracuse (/ x 2))))

Il ne termine pas, comme je l’ai écrit, mais ça ne nous empêche pas mathématiquement de chercher si le cycle trivial est atteint quel que soit x.



Tu te trompes sur mon propos. Dans cet exemple, c’est la preuve qui est difficile, ce n’est pas le code qui est difficile à prouver, nuance.



Je pourrais l’écrire comme ça : (j’ai essayé d’imaginer pire code, mais je fais un blocage " />)

void syracuse(int* n)

{

__while (*n != 1)

__{

____printf (“%d\t”, *n);

____n = (n % 2) ? 3(n)+1 : *n / 2;

__}

}



SI l’on imagine que ce bout de code est plongé dans un programme capable de toucher entre deux tours de boucles à la valeur de n, il devient plus difficile de le prouver (sauf à faire une hypothèse forte sur la valeur

déréférencée de n).





Heu…. tu imagines quand même un cas dégueulasse du mec qui fait de la merde en parallèle.



D’un point de vu purement pratique, j’ai une préférence pour les boucles qui ne font pas exploser la pile d’exécution (la mémoire ça peut être précieux) et si je peux, je fais de préférence des boucles for/foreach car je sais qu’elles s’arrêteront de toute façon un moment donné (je n’ai pas à réfléchir pour en être sûr, ni maintenant ni dans 6 mois). Bon, pour le premier point, a priori, certain compilo de langage fonctionnel (OCaml) semble pouvoir convertir du récursif en itératif.

Le récursif, je vais l’utiliser lorsqu’il me parait plus naturel. Par exemple le problème des tours de Hanoï c’est du récursif. Pour un parcours de liste du premier au dernier (pour y faire une opération), je vais plutôt utiliser de l’itératif (justement, j’itère sur ma liste) sauf si par exemple, c’est pour trouver le plus petit élément par exemple qui là sera récursif (car je sais que le minimum d’un liste c’est le minimum entre le minimum de la première moitié de la liste et le minimum de la seconde moitié.)



Sinon : raaa la notation polonaise, c’est horrible !!!