Se connecter avec
S'enregistrer | Connectez-vous

Apple ignore une faille pendant 7 mois

Par - Source: Security Reason | B 32 commentaires

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.

Commentaires
Afficher les 32 commentaires.
Cette page n'accepte plus de commentaires
Meilleurs commentaires
  • 11 Masquer
    magellan , 13 janvier 2010 09:47
    [mode monde idéal ON]
    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]
Tous les commentaires
  • vedge2000 , 13 janvier 2010 08:32
    C'est normal car tous les développeurs sont sur le iTabletteMachin!
    ;) 
  • jafar , 13 janvier 2010 09:13
    il peu y avoir des bug et des failles sous mac os ?
    on m'a toujours menti alors.
  • petitpandaroux , 13 janvier 2010 09:47
    @jafar : on n'est pas encore vendredi ...
  • 11 Masquer
    magellan , 13 janvier 2010 09:47
    [mode monde idéal ON]
    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]
  • -3 Masquer
    Anonyme , 13 janvier 2010 10:13
    hey en tt cas je suis sur snow depuis 1 mois jvois pas ce quil a de plus que 7!
    et ce nest pas un troll
  • Yannick G , 13 janvier 2010 10:16
    It's not a faille, it's a feature :o 
  • Vikk , 13 janvier 2010 10:33
    Mac = fail?
  • pluies , 13 janvier 2010 10:37
    libc étant open source, il est possible de développer un patch à partir des sources (eventuellement en suivant le patch développé par OpenBSD). Ca devrait être jouable pour tout kernel hacker qui se respecte. ;) 

    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. :D 
  • Serious Gilles , 13 janvier 2010 11:37
    Preuve qu'il n'y a pas de système sans failles...
  • pluies , 13 janvier 2010 12:05
    Serious GillesPreuve qu'il n'y a pas de système sans failles...

    Absolument, surtout dans un OS, et a fortiori un OS grand public !

    Ceci dit, on peut toujours essayer. :) 
  • Sn4kY , 13 janvier 2010 12:21
    Yannick GIt's not a faille, it's a feature

    ça me rappelle étrangement quelqu'un...
  • micaub , 13 janvier 2010 12:25
    pre13hey en tt cas je suis sur snow depuis 1 mois jvois pas ce quil a de plus que 7!

    Bin c'est facile pourtant : il a une pomme derrière l'écran ! :D 
  • sirius , 13 janvier 2010 12:47
    micaubBin c'est facile pourtant : il a une pomme derrière l'écran !

    Derrière ou devant l'écran ;) 
  • zeb , 13 janvier 2010 13:32
    Sirius: +1 :lol: 
  • frederpe , 13 janvier 2010 14:45
    [Mode Chevalier de l'apocalypse ON]

    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
  • pluies , 13 janvier 2010 15:13
    Un bot aurait répondu plus rapidement. :o 
  • ultrabill , 13 janvier 2010 15:33
    Citation :
    Un bot aurait répondu plus rapidement. :o 
    Son Mac viens de planter à cause d'une (autre) faille non corrigée :o 
  • fitfat , 13 janvier 2010 15:46
    siriusDerrière ou devant l'écran

    Derrière. Devant, il y a une poire =)
  • zorro3364 , 13 janvier 2010 16:21
    en même temps, le buffer overflow est le type de faille le plus répandu (il apparait quasiment dès qu'il y a conversion de données), mais est-ce au développeur ou à l'éditeur de la combler?
    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?
  • magellan , 13 janvier 2010 16:38
    zorro3364en même temps, le buffer overflow est le type de faille le plus répandu (il apparait quasiment dès qu'il y a conversion de données), mais est-ce au développeur ou à l'éditeur de la combler?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...
Afficher plus de commentaires