Des chercheurs ont présenté un proof of concept montrant une faille de sécurité dans Mac OS X 10.5 et 10.6. Ils ont alerté Apple en juin dernier, mais rien n’a été fait pour réparer le problème.
Un problème connu
C’est d’autant plus dommage que le patch est relativement simple et que certains éditeurs ont réussi à l’implémenter en quelques heures, voire quelques jours au maximum. La faille touche, en effet, tous les logiciels et systèmes d’exploitation implémentant les nombres en virgule flottante gdtoa. Dans Mac OS X, le problème réside dans les libc/strtod(3) et libc/gdtoa. Seize autres applications sont concernées par cette faille (Firefox, Opera, Chrome, OpenBSD, FreeBSD, KDE et F-Lock, entres autres) et seulement deux sont encore vulnérables : Mozilla Sunbird et le langage de programmation J.
Un cas d’école
Le proof of concept montre qu’un code PHP malveillant pourrait faire planter la machine et la manipulation des registres esi et edi (qui s’occupent des opérations mémoire) pourrait permettre l'exécution de codes à distance. Dans les faits, aucun site n’exploite encore cette faille.
Si ce genre d'info pouvait bâillonner tous les extrémistes pro ceci ou cela en leur montrant que tous les OS sont "fragiles"...
[mode monde idéal OFF]
on m'a toujours menti alors.
Si ce genre d'info pouvait bâillonner tous les extrémistes pro ceci ou cela en leur montrant que tous les OS sont "fragiles"...
[mode monde idéal OFF]
et ce nest pas un troll
Je me souviens avoir du patcher un bug bizarre du ld dans 10.5 pour pouvoir faire tourner des applis Windows 16 bits dans Wine... Souvenirs, souvenirs.
Absolument, surtout dans un OS, et a fortiori un OS grand public !
Ceci dit, on peut toujours essayer.
ça me rappelle étrangement quelqu'un...
Bin c'est facile pourtant : il a une pomme derrière l'écran !
Derrière ou devant l'écran
Tremblés bandes d'insectes car avec vos langues fourchues vous allez réveillez le terrible LVM !
[Mode Chevalier de l'apocalypse OFF]
Je pense d'ailleurs que LVM est un BOT pour être aussi ...... LVM
Derrière. Devant, il y a une poire =)
depuis plusieurs années, visual studio génère un warning si il rencontre par exemple _ui64toa et préconise d'utiliser sa version "corrigée" (c'est à dire qui vérifie simplement la taille du buffer) _ui64toa_s. bon, si le developpeur choisi d'utiliser une fonction non sécurisée et sans lui même vérifier la taille de ses buffer, l'éditeur de l'os est-il vraiment a blâmer?
C'est un rien plus délicat je pense. Il y a deux points de vues possible:
- C'est le système qui doit être safe
- C'est aux développeurs de blinder leur part du boulot.
Or, dans les deux, ce sont des humains qui développent, et donc, "oublient" les failles potentielles. Allons plus loin: il arrivait (fut une époque maudite), qu'une correction de la JVM Sun engendrait des soucis avec les développements en version précédente... alors les failles perduraient, parce que le coût de repli vers la nouvelle version était trop élevée! Pénible, mais bien réel, ce problème fait perdurer aussi nombre d'anomalies de codage qui auraient dues êtres soldées.
Je te rejoins totalement sur la théorie: difficile de toujours blâmer l'éditeur, mais concrètement, le développeur s'adosse aussi à un environnement qu'il suppose "aussi fiable que possible" (le APAP - As Proof As Possible). De là, en pratique...