Le bug de Zlib touche aussi des produits Microsoft

Posté par  (site web personnel) . Modéré par Yann Hirou.
Étiquettes : aucune
0
19
mar.
2002
Microsoft
En regardant en détail la liste des applications utilisant Zlib, on trouve quelques produits Microsoft (DirectX 8.0, Frontpage, IE...) ainsi que d'autres produits commerciaux (Adobe Acrobat, Macromedia Shockwave, Lotus Notes...). A priori, eux aussi peuvent être touchés par le "double free"... Messieurs, mesdames, à vos service-pack :-)

D'autre part, j'en ai profité pour vérifier la licence de Zlib. A priori, ce n'est pas incompatible avec des licences propriétaires mais les applications doivent faire référence à la Zlib. Est-ce réellement respecté ? A titre d'exemple, je viens de faire une recherche sur les fichiers d'Acrobat Reader, la bibliothèque utilise bien la Zlib mais aucun document n'y fait référence...

Aller plus loin

  • # Vérifie mieux :)

    Posté par  (site web personnel) . Évalué à 10.

    La licence n'impose pas de faire référence à zlib dans la doc du produit si le source n'est pas diffusé.

    http://www.gzip.org/zlib/zlib_license.html(...)

    • [^] # Re: Vérifie mieux :)

      Posté par  (site web personnel) . Évalué à 3.

      Content pour moi. J'ai lu la license en diagonale. Toutefois, elle suggere une sitation dans la doc mais pour autant l'exiger. Donc, je reforme ma question : avez-vous deja vu des softs close-source sites la Zlib dans leur doc (juste pour savoir si certains sont "polis") ?

      Laurent

    • [^] # Re: Vérifie mieux :)

      Posté par  (site web personnel) . Évalué à 10.

      Il est *regrettable* que les softs closed source ne soit pas obligé de citer Zlib en tant que composant Open Source dans leur doc. Cela aiderait pas mal de gens à prendre conscience de l'importance de l'Open Source, y compris dans "leurs" softs qu'ils payent !
      Et bien sur cela n'est pas spécifique à Zlib.

      • [^] # groumff

        Posté par  . Évalué à -7.

        Il est surtout regrettable que la licence utilisée ne soit pas la GPL. Cela aurait au moins obligé Hublot à fournir le code de leurs logiciels machins.

        • [^] # Re: groumff

          Posté par  . Évalué à 0.

          Enfint pour une librairie comme la zlib, la LGPL conviendrait bein mieux que la GPL...

          Bon ok, -1

      • [^] # Re: Vérifie mieux :)

        Posté par  . Évalué à 4.

        Grace à ça, ils peuvent même l'utiliser sans le savoir : en utilisant un composant qui utilise lui-même la zlib ...

  • # Securite Proprietaire vs Open Source.

    Posté par  . Évalué à 10.

    Ceci me semble un bon exemple concret de l'avantage de l'open source sur les logiciels proprietaires. Le patch correctif de la zlib est par exemple apparu des le 11 mars sur le site Debian (no troll, c'est juste la que je l'ai vu en premier http://www.debian.org/(...) ).
    Pour les logiciels proprio, encore apres cette date, on avait encore des declarations style Microsoft tentant de minimiser l'affaire ( http://www.vnunet.com/News/1130151(...) )

  • # "Ils" sont + "mals" que nous ces utilisateurs!

    Posté par  . Évalué à 10.

    En effet, Microsoft va certainement réagir plus lentement (pas ne pas dire jamais!) que développeurs et entreprises issus/liés aux logiciels libres. (c'est une conséquence directe du libre).

    Si je me souviens bien, dans la première news à propos du bug de la zlib, il y avait déjà une annonce de correctifs RedHat.
    Dans combien de temps pour ces produits? Dans combien de MOIS apparaitra-t-il éventuellemnt une liste des produits à risques?

    C'est un examples des moments clés pour les choix des admins et/ou des entreprises quant aux parcs logiciels.

  • # URL étrange

    Posté par  (site web personnel) . Évalué à -6.

    personne ne trouve çà bizarre comme URL : http://news.com.com/2100-1001-860328.html(...) ?

    le double ".com", çà ne m'inspire pas confiance.

    • [^] # Re: URL étrange

      Posté par  . Évalué à 5.


      $ whois com.com
      [...]
      Registrant:
      CNET Networks, Inc (COM2994-DOM)
      235 2nd Street
      San Francisco, CA 94104
      US

      Domain Name: COM.COM
      [...]

    • [^] # Re: URL étrange

      Posté par  (site web personnel) . Évalué à -7.

      ça doit etre un nom de domaine dynamique ????

      @+
      Code34

    • [^] # Re: URL étrange

      Posté par  . Évalué à -1.

      Soit c'est le domaine "com", avec le TLD ".com", soit c'est le domaine "news" avec le "sous TLD" (qui n'est rien d'autre qu'un domaine redecoupe, si je ne m'abuse) "com.com" (comme .gouv.fr, etc....).

      Je serais tenté de dire que c'est la première solution...

      Allez, vas déposer "org.org"... ah non, trop tard aussi...

  • # win Xp -- les ecrans bleus -- beau titre de zik ;))

    Posté par  (site web personnel) . Évalué à -10.

    hello,

    J écris un petit post à l'intention de "Pasbillpasgate", concernant win XP. Suite à ton post, concernant les écrans bleus sous winxp, j'ai recherché un livre qui me permettrait de localiser le bug :()

    Sans faire de pub, j'ai trouvé un livre :"xp inside out" qui décrit le fonctionnement de xp en surface édité par microsoft.

    Rien d'énorme, enfin ça ne conviendrait à aucun linuxien...

    Cependant celui ci donne tout les types d erreurs que l'on peut rencontrer:

    Stop 0x0000000A or IRQL_NOT_LESS_OR_EQUAL
    le kernel ou un driver a accédé à une zone non autorisée en mémoire. (possibilité de virus ou de trojan)

    Stop 0x0000001E or KMODE_EXCEPTION_NOT_HANDLED
    instruction processeur inconnue (mauvais driver, ou mémoire invalide)

    Stop 0x00000024 or NTFS_FILE_SYSTEM
    probleme avec le système de fichier ntfs. (peut provenir d un probleme hardware)

    Stop 0x0000002E or DATA_BUS_ERROR
    Défaillance de la memoire physique (cela peut etre aussi celle de la carte graphique, disque dur, carte mère)

    Stop 0x0000003F or NO_MORE_SYSTEM_PTES
    La mémoire de pagination est saturée

    Stop 0x00000050 or PAGE_FAULT_IN_NONPAGED_AREA
    Un driver ou un service réclame des données qui ne sont plus en mémoire (peu provenir de la mémoire physique, d un antivirus, control distance)

    Stop 0x00000077 or KERNEL_STACK_INPAGE_ERROR
    Le kernel essaie de lire des données dans la mémoire virtuelle (pagination) mais n'arrive pas à les trouver. (peu provenir du disque, mémoire, controller, etc...)

    Stop 0x00000079 or MISMATCHED_HAL
    Les paramêtres acpi du bios ont été modifié anormalement.

    Stop 0x0000007A or KERNEL_DATA_INPAGE_ERROR
    Une page du kernel n'a pas été trouvé dans la mémoire virtuelle. (probleme disk, controler, scsi etc..)

    Stop 0x0000007B or INACCESSIBLE_BOOT_DEVICE
    Xp ne trouve pas la partition système ... (c mal barré) ;))

    Stop 0x0000007F or UNEXPECTED_KERNEL_MODE_TRAP
    Probleme hardware. chipset défaillant, cpu, ventilateur ...

    Stop 0x0000009F or DRIVER_POWER_STATE_FAILURE
    Un dirver n'a pas été arreté correctement à l'extinction du système, et n'a pas le bon statut.

    Stop 0x000000C2 or BAD_POOL_CALLER
    Un process a tenté une allocation mémoire pas authorisé.

    Stop 0x000000D1 or DRIVER_IRQL_NOT_LESS_OR_EQUAL
    Un driver a essayé d acceder à une zone mémoire incorrect

    Stop 0x000000D8 or DRIVER_USED_EXCESSIVE_PTES
    un mauvais driver consomme trop de pagination

    Stop 0x000000EA or THREAD_STUCK_IN_DEVICE_DRIVER
    Probleme de driver de carte graphique, le système attend.

    Stop 0x000000ED or UNMOUNTABLE_BOOT_VOLUME
    Impossibilité d accesser à la partition de boot. (controller les nappes)


    Stop 0x000000F2 or HARDWARE_INTERRUPT_STORM
    Le système n'arrive pas à liberer un irq pour un périphérique. (probleme de driver)

    Stop 0xC000021A or STATUS_SYSTEM_PROCESS_TERMINATED
    Probleme sérieux de sécurité. Winlogon , ou csrss.exe est compromis , (problemes de permissions sur les repertoires)


    Stop 0xC0000221 or STATUS_IMAGE_CHECKSUM_MISMATCH
    Corruption de fichier ou de disk (hardware pour la plus part du temps)

    Je n'ai pas encore utilisé le débugueur ... Mais si je trouve le temps, je m'y plongerais [affaire à suivre]

    @+
    Code34

  • # Verifions mieux BIS ;-)

    Posté par  . Évalué à 10.

    Restons calme.

    le bug dans la zlib est un double free. Ce genre de bug peu avoir des effets completement differents selon l'implementation de malloc/free dans le système.
    Linux est completement vulnerable, le double free peu mener a un bel exploit, mais windows utilise une implementation de gestion mémoire assez différente (pour notre plus grand bonheur vu les perfs :-).

    Il se pourrait bien que free() chez eux s'appercoive que la zone est déjà dé-allouée et ne fasse rien par exemple. Pour le moment l'article Cnet dit qu'ils verifient si c'est un probleme chez eux. D'après ce que j'ai lu sur bugtrack, il a des chances que sous windows ce genre de bug soit juste un bug de plus et pas un trou de sécurité ...

    Que ceux qui ont des preuves avancent, que les autres attendent d'en savoir plus, mais de grace restons calmes avant de devenir ridicules.

    • [^] # Re: Verifions mieux BIS ;-)

      Posté par  . Évalué à 4.

      Le probleme de securite ici detecte ne reside pas tant dans le fait qu'il y ait une faille potentiellement exploitable, mais bien dans le temps de latence de reaction de la part des logiciels closed source par rapport aux logiciels open source.
      Il n'est pas ridicule de dire qu'il y a un probleme lorsque d'un cote, le bug est corrige en 24h, et que de l'autre, on en est encore a poser des conditionnels sur ce bug, et si peu affirmation. Pendant ce temps, si il y a bug exploitable, les "hackers" (placez entre les guillemets precedents le terme qui vous convient le mieux) se sont probablement fait une joie de le verifier...

      • [^] # Re: Verifions mieux BIS ;-)

        Posté par  . Évalué à 10.

        si la faille n'est pas exploitable, ce n'est plus un probleme de sécurité mais simplement un BUG.
        Chez microsoft, on ne corrige pas les bugs a la volée cela n'est plus a démontrer.

        Vu l'ampleur du probleme (zlib est utilisée de partout), il y a des TONNES de logiciels a corriger. Je trouve donc OPTIMAL de vérifier d'abord a quoi cela expose les clients avant de faire des release de patchs a gogo.

        Si l'implementation de free() sur windows ne fait rien quand on l'appelle une seconde fois pour le meme segment de mémoire, il y a un bug dans l'algo de zlib qui n'est pas une faille, ni un probleme pour l'utilisateur (puisque ne crash pas le logiciel non plus). Si c'est le cas, je ne comprendrais pas que tout le monde fasse des release de patch pour un bug qui est pour le moins 'virtuel'.

        Par contre il est vrai qu'un peu plus de certitude sur le diagnostique du cote windows ne ferai pas de mal.

        • [^] # Re: Verifions mieux BIS ;-)

          Posté par  . Évalué à 0.

          >Par contre il est vrai qu'un peu plus de certitude sur le diagnostique du cote windows ne ferai pas de mal.

          On est d'accord dans l'ensemble. Ce que cette affaire met surtout en lumiere, c'est l'obscurite inherente au logiciel closed source. En cas de probleme eventuel, on ne peut que ne rien savoir et attendre. Youpi.

        • [^] # Re: Verifions mieux BIS ;-)

          Posté par  . Évalué à -1.

          Hum .. si la zlib est une librairie .. y suffirait pas de relinker (si c'est en static) ou de remplacer le .so .. pas besoin de tt modif comme des bourrins ..

      • [^] # Re: Verifions mieux BIS ;-)

        Posté par  . Évalué à 7.

        > Le probleme de securite ici detecte ne reside pas tant dans le fait qu'il y ait une faille potentiellement exploitable, mais bien dans le temps de latence de reaction de la part des logiciels closed source par rapport aux logiciels open source.

        Il y'a un autre inconveniant aux logiciels closed source.
        C'est le manque de bibliothèques partagés qui découle directement du côté fermé de la chose.

        Puisque zlib n'est pas dans Windows en standard, les editeurs n'ont pas le choix que de compiler zlib en statique dans leur logiciel.
        En admettant que ce bug puisse être exploité (remarquez bien le "en admettant que"), le nombre de mises-a-jour dans un environnement closed-source sera donc plus important que dans un environnement open-source. Il y aura donc plus de patches (donc plus de travail pour l'admin et plus de chance que quelque chose foire).

        • [^] # Re: Verifions mieux BIS ;-)

          Posté par  . Évalué à 2.

          Rien a voir avec open source.

          Si une lib X n'est pas en standard avec ta distrib les gens doivent faire quoi ? la mettre en statique...

          C'est juste une question de choix de l'editeur(de distrib ou de Windows)

          • [^] # Re: Verifions mieux BIS ;-)

            Posté par  (site web personnel) . Évalué à 10.

            C'est vrai que les gens qui font des bibliothèques ont parfois une fâcheuse tendance à la mettre uniquement en statique.

            Pour pallier à ça, Debian impose de distribuer systématiquement une version dynamique des bibliothèques. J'imagine que les autres distributions font la même chose (peut-être moins strictement).

    • [^] # Re: Verifions mieux BIS ;-)

      Posté par  . Évalué à 7.

      Le type d'attaque possible est expliqué par zlib ( http://www.gzip.org/zlib/advisory-2002-03-11.txt(...) ): "On many systems, freeing the same memory twice will crash the application. Such "double free" vulnerabilities can be used in denial-of-service attacks"

      Le bug Zlib n'est pas dangereux sur un desktop : au mieux fin du programme concerné au pire reboot.
      Par contre, les risques d'attaques par dénis de service sont inacceptables pour un serveur en exploitation.

      À la vue de la liste des "produits" Microsoft concernés, je ne crois pas qu'il y aura beaucoup de mises à jour chez Microsoft.

      Pour le Libre, les développeurs étant des gens sérieux, ils fourniront rapidement une version corrigée même si cela n'est pas réellement nécessaire pour les programmes qui n'ont rien à faire sur un serveur en exploitation.

      • [^] # Re: Verifions mieux BIS ;-)

        Posté par  (site web personnel) . Évalué à 6.

        Pour le Libre, les développeurs étant des gens sérieux, ils fourniront rapidement une version corrigée même si cela n'est pas réellement nécessaire pour les programmes qui n'ont rien à faire sur un serveur en exploitation.
        Ça a déjà été fait... http://www.debian.org/security/2002/dsa-122(...)
        On notera que grâce à l'utilisation de bibliothèques dynamiques, seuls 8 logiciels ont du être corrigés séparément. D'ailleurs, ça a servi à lancer un débat à ce sujet, qui conduira probablement à un nettoyage de tout lien statique inutile.

      • [^] # Re: Verifions mieux BIS ;-)

        Posté par  . Évalué à 6.

        Humm, désolé mais apparemment tu ne sais pas lire.
        je quote la meme phrase que toi:
        "On many systems, freeing the same memory twice will crash the application"

        comme vous insistez cette fois je vais argumenter avec une URL sur cet exellent article de phrack:
        http://www.phrack.org/phrack/57/p57-0x09(...)

        il y est expliqué les différentes implémentations de malloc/free et quels systèmes les utilises.
        il y est aussi expliqué comment en profiter pour lancer un shell sous linux et hurd.
        Je cite quelques extraits de l'article (long et tres technique, pas la peine de poster ici):


        There are only a few common malloc implementations. The most common ones
        are the System V one, implemented by AT&T, the GNU C Library implementation
        and the malloc-similar interface of the Microsoft operating systems
        (RtlHeap*).

        Here is a table of algorithms and which operating systems use them:

        Algorithm | Operating System
        ------------------------+--------------------------------------------------
        BSD kingsley | 4.4BSD, AIX (compatibility), Ultrix
        BSD phk | BSDI, FreeBSD, OpenBSD
        GNU Lib C (Doug Lea) | Hurd, Linux
        System V AT&T | Solaris, IRIX
        Yorktown | AIX (default)
        RtlHeap* | Microsoft Windows *
        ------------------------+--------------------------------------------------

        <snip>

        ell, however, exploitation is pretty straight forward now:

        <jmp-ahead, 2> <6> <4 bogus> <nop> <shellcode> |
        \xff\xff\xff\xfc \xff\xff\xff\xfc <retloc - 12> <retaddr>



        CQFD

  • # Et le support utilisateur ??

    Posté par  . Évalué à 7.

    Bon je viens de faire un ldd sur acroread et biensûr ce n'est pas un éxécutable dynamiquement lié aux librairies.

    Cepdendant sous linux c'est un version 4.05 a peine maintenue et il n'y a pas de nouveaux binaires realeasés. il y a un peu de foutage de gueule quand meme.

    Bon on va me dire que j'ai qu'à utiliser ghostview, mais ce dernier ne gère pas le plein écran. C'est très utile pour les présentation en PDF avec prosper (prosper.sourceforge.net).

    Quelqu'un connait-il une alternative ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.