Journal Virus autorun sous Linux par l'exemple

Posté par  (site web personnel) .
Étiquettes :
9
9
fév.
2011
Conférence bien sympathique sur les vulnérabilités d'un "Bureau" Linux.

Centré autour de Gnome (même si éventuellement cela peut surement aussi arriver avec KDE même si les paramètres par défaut de KDE sont plus "secure").

Différent types d'attaque:
- Au niveau du noyau: usb, fs, ... (avec donc accès root)
- Au niveau du Bureau: gio, udev, *-thumbnailer, ... (accès utilisateur)
- Contournement des différentes techniques de sécurisation (PIE, ASLR, ...)
- Contournement de AppArmor (exemple sous Ubuntu) mais ca doit aussi fonctionner avec SELinux & co.

http://www.net-security.org/secworld.php?id=10544

  • # A noter

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

    Maintenant que j'ai vu la fin:
    - L'auteur n'a pas réussi à contourner AppArmor (mais il y travail).
    - L'auteur a presque réussi à contourner ASLR (il y travail aussi).

  • # Version texte

    Posté par  . Évalué à 6.

    Il existe une version texte du "talk" ?

    DLFP >> PCInpact > Numerama >> LinuxFr.org

  • # Un peu plus d'informations

    Posté par  . Évalué à 8.

    pour ceux qui sont au boulot ou qui ne regarde pas de vidée sur internet.

    Je vois pas pourquoi on parle d'autorun, j'en ai jamais eu. C'est une nouveauté de Gnome et KDE récent ?

    Sinon qu'est ce qui, dans le montage d'un périphérique va entraîner l'exécution d'un code arbitraire ?

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Un peu plus d'informations

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

      http://specifications.freedesktop.org/autostart-spec/autosta(...)

      Gnome utilise la spec ci dessus.

    • [^] # Re: Un peu plus d'informations

      Posté par  . Évalué à 8.

      Ce n'est pas forcément l'autorun a proprement parler mais les nombreuses fonctions liées au montage du FS et surtout les nombreuses libs impliquées dans les preview thumbnails de nautilus. Il suffit qu'une faille soit exploitable dans l'une d'entre elle et le tour est joué.

      Vidéo instructive.

    • [^] # Re: Un peu plus d'informations

      Posté par  . Évalué à 3.

      L'autorun dont il est question ici n'est pas vraiment un autorun comme ceux des CD je pense.

      Quand tu insères un média éjectable, il y a une fenêtre qui apparait et te demande si tu veux lancer un programme en réaction. Tu as la possibilité de choisir d'effectuer cette action à chaque fois. Dans le cas présent, si tu choisis de lancer Nautilus pour explorer ton média, une faille qui était présente dans le thumbnailer permettait de faire exécuter du code arbitraire à ton ordinateur si celui-ci était insérer dans un fichier DVI (de mémoire) spécialement conçu.

      Par la suite, en déployant les habituelles manœuvres visant à contourner les protections et la gestion des droits, il est théoriquement possible de gagner les droits de root et de faire faire ce que l'on veut à ton ordinateur.

      Bon ça c'est la théorie. En pratique, il y a du travail pour en arriver là pour reprendre les propos du journal.

      • [^] # Re: Un peu plus d'informations

        Posté par  . Évalué à 6.

        Et j'ai juste oublier de préciser que la faille du thumbnailer exploiter ici a été corrigé en janvier.

        La couverture par H online est intéressante : http://www.h-online.com/security/news/item/Linux-vulnerable-(...)

      • [^] # Re: Un peu plus d'informations

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

        Il y'a aussi une porte ouverte pas l'execution de autorun.sh sur les support amovible par KDE et Gnome... (même si normalement il y'a une fenêtre de confirmation).

      • [^] # Re: Un peu plus d'informations

        Posté par  . Évalué à 2.

        Merci beaucoup pour l'explication.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Un peu plus d'informations

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

          D'ou les conseils de l'auteur:
          - Pas d'automount
          - Pas de thumbnails

          Ce que fait KDE par défaut.

          • [^] # Re: Un peu plus d'informations

            Posté par  . Évalué à 9.

            Bof pas d'automount, ça ne sert presque à rien: si c'est toi l'utilisateur final qui veut regarder le contenu d'une clef USB alors même s'il faut taper 'mount', tu vas le faire et le niveau de sécurité est inchangé.
            Par contre désactiver l'automount quand l'ordinateur a son écran vérouillé, là oui c'est intéréssant.

            Pour la génération de thumbnail désactiver les thumbnails est une grosse perte de fonctionnalité qui va en** les utilisateurs, c'est le niveau 0 de sécurité: tu désactive la fonctionnalité..
            Il vaudrait mieux utiliser un "thumbnailer" sandboxé, et que les images générées soient dans un format d'image unique ou le décodeur est audité rigoureusement..

            • [^] # Re: Un peu plus d'informations

              Posté par  . Évalué à 2.

              > si c'est toi l'utilisateur final qui veut regarder le contenu d'une clef USB alors
              > même s'il faut taper 'mount', tu vas le faire et le niveau de sécurité est inchangé.

              La difference, et il l'explique dans la video, c'est qu'avec un automount, les chemins sont connus a l'avance : la clef est montee dans /media/un_nom_previsible. Connaitre le nom du repertoire aide a concevoir le code malveillant. Dans mon code en dur dans fstab, ma clef usb est montee dans /mnt/divers, /mnt/cle, ce genre de choses. Ca le concepteur du vers ne peut pas le savoir a l'avance.

              • [^] # Re: Un peu plus d'informations

                Posté par  . Évalué à 4.

                ouh la vu les differentes facon de monter par udev et hal c'est pas aussi vrai que ca la predictabilite du nom de point de montage... (cela peut etre le nom du volume, son UUID, son device unix, l'age du capitaine...)

                • [^] # Re: Un peu plus d'informations

                  Posté par  . Évalué à 3.

                  ou la date de péremption de hal.

                • [^] # Re: Un peu plus d'informations

                  Posté par  . Évalué à 4.

                  L'attaque qu'il présente nécessite une clef USB physique, elle nécessite la collaboration de l'utilisateur (le convaincre d'insérer la clef) ou un accès physique au matériel. C'est uniquement une attaque ciblée, pas une attaque en masse où tu envoies un million de clef USB à un millions de pékins choisis dans le bottin. Le mode d'attaque fait que tu as sans doute moyen de te renseigner sur la machine (tu peux entrevoir l'écran ou parler à l'utilisateur). Une fois que tu sais quelle version de quelle distribution ça doit être, tu peux l'installer chez toi et voir ce qui se passe.

                  • [^] # Re: Un peu plus d'informations

                    Posté par  . Évalué à 5.

                    A partir du moment ou il y a acces physique a l'appareil c'est mort la securite.

                    • [^] # Re: Un peu plus d'informations

                      Posté par  . Évalué à 2.

                      Tu peux envoyer la clef par courrier physique accompagnant un CV, une offre commerciale, ou autre excuse tant que tu convaincs le pigeon d'insérer la clef sans suspicion. Retenir qu'il ne faut pas connecter de périphérique douteux a son ordinateur. Ceux qui ont connu les virus MBR des disquettes s'en souviennent.

                  • [^] # Re: Un peu plus d'informations

                    Posté par  . Évalué à -4.

                    L'attaque qu'il présente nécessite une clef USB physique, elle nécessite la collaboration de l'utilisateur

                    - Tiens Gérard, j'ai sur mon disque USB externe l'ISO de la dernière ubuntu, tu veux?
                    - Cool, donne, je vais le brancher.

                    Et hop, chopé!

                    Des périph externes à base de Fat/NTFS contaminé, j'en ai vu des tonnes et vu le côté pratique de ces périph, c'est un moyen de prolifération de saleté pas si négligeable. Ce comportement n'est en rien impossible sous Linux c'est même encore plus facile.

                    Bref, il faut plutôt "durcir" le gestionnaire de montage/détection automatique, par retirer la fonctionnalité.

              • [^] # Re: Un peu plus d'informations

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

                Dès lors que du code peut être exécuté, pourquoi pas pwd ?

                Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

                • [^] # Re: Un peu plus d'informations

                  Posté par  . Évalué à 3.

                  Vers la 40e minute [http://www.youtube.com/watch?v=ovfYBa1EHm4&t=2400], il explique la faille employée. Le format DVI permet de mettre en dur des chemins vers des polices de caractères, et l'exécution de code arbitraire n'est permise que grâce à une faille dans la lecture des polices. Il faut donc que les dangereux fichiers de polices soient chargés. [http://www.ubuntu.com/usn/usn-1035-1].

                  La vidéo contient énormément d'informations, il n'expose pas uniquement la faille qu'il a découverte, c'est plutôt tous les chemins qu'il a exploré puis cette faille qu'il a trouvée.

          • [^] # Re: Un peu plus d'informations

            Posté par  . Évalué à 2.

            C'est pour ça que ça m'intéressais. Moi mon shellet mon montage à la main ne sommes pas impacté.

            Pour ceux qui utilisent un gestionnaire de fichier, il n'y a pas d'option "pas de miniatures pour les périphériques amovibles" ?

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Un peu plus d'informations

              Posté par  . Évalué à 2.

              Toutes les options sont prévues par gnome et KDE pour éviter l'attaque qu'il présente. Le problème est plutôt la configuration par défaut des distributions destinées à Mme Michu. Il illustre sa présentation avec Ubuntu, j’espère que cela incitera cette distribution à améliorer ses réglages par défaut.

              • [^] # Re: Un peu plus d'informations

                Posté par  . Évalué à 1.

                En meme temps il utilise un bug deja corrige dans la creation de thumbnails donc en fait le vers il aurait pu marcher mais cela est reste au conditionnel.

                • [^] # Re: Un peu plus d'informations

                  Posté par  . Évalué à 7.

                  oui le bug du dvi est corrigé mais il pourra toujours y avoir des bugs l'un ou l'autre des dizaines de formats supportés. Par exemple, si tu cherches sur le net, il y a eu des vulnérabilités chez libpng, libjpeg, libtiff.

                  Dans tous les cas, ouvrir tous les fichiers de la racine d'un media non de confiance, sans même que l'utilisateur ait eu à dire oui ou non, c'est une mauvaise politique. C'est comme le vieux bug d'Outlook qui ouvrait automatiquement les pièces attachées.

                  • [^] # Commentaire supprimé

                    Posté par  . Évalué à 3.

                    Ce commentaire a été supprimé par l’équipe de modération.

                  • [^] # Re: Un peu plus d'informations

                    Posté par  . Évalué à 3.

                    Oui il y a eu et il y aura des trous mais bon pour le moment c'est encore une fausse alerte.
                    Moi ce qui m'embette plus dans la securite avec les cles usb c'est le format de fichier utilise generalement le FAT32. La raison en est simple: par defaut les fichiers sont executables sous linux et ca ce n'est clairement pas bon).

                    • [^] # Re: Un peu plus d'informations

                      Posté par  . Évalué à 2.

                      Justement, jusqu'à il y a peu, il était possible sous GNOME de configurer les options de montage des volumes FAT32 via une clef GConf.

                      Malheureusement, ça ne semble plus possible, je crois que c'était lié à HAL.

                      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                    • [^] # Re: Un peu plus d'informations

                      Posté par  . Évalué à 3.

                      > par defaut les fichiers sont executables sous linux

                      Tu veux dire que ta distribution n'utilise pas par défaut les bonnes options de montage ? Je pense que tu peux le leur suggérer. Chez moi, fstab dit :

                      /dev/sdb1 /mnt/floppy auto noatime,noauto,noexec,user,fmask=0137,dmask=0027 0 0

                      Je suis sûr que les auto-truc peuvent être configurés de la même façon.

                      • [^] # Re: Un peu plus d'informations

                        Posté par  . Évalué à 2.

                        HAL pouvait se configurer relativement facilement (au travers de fichiers XML assez lisibles), mais pour udisks, j'ai un peu cherché mais pas trouvé de doc claire.

                        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Un peu plus d'informations

      Posté par  . Évalué à 4.

      > Sinon qu'est ce qui, dans le montage d'un périphérique va entraîner l'exécution d'un code arbitraire ?

      * Le montage du FileSystem en lui-même: note qu'un attaquant peut choisir d'utiliser un FS rare (pas très utilisé) et donc à priori peu audité.

      * La génération des thumbnails: il y a eu pas mal de vulnérabilité sur les décodeurs d'images.. et la aussi l'attaquant peut choisir un format d'image rare.
      Idéalement aucun décodeur d'image ne devrait avoir accès a "l’environnement ambiant" mais comme actuellement cela demande pas mal d'effort à faire (conception de la plupart des OS pas terrible au niveau sécurité) et que cela peut même avoir un coût en performance, j'imagine qu'en pratique cette isolation est rarement faite..

      • [^] # Re: Un peu plus d'informations

        Posté par  . Évalué à 2.

        Je vois toujours une énorme différence avec l'autorun à la Windows.

        Ce dernier permettait d’exécuter un code machine directement.

        Si la fonctionnalité de l'autorun Linux se limite à fournir un fichier de données, ce sont les programmes installés sur la machine hôte qui doivent être sécurisées.

        Ceux-ci doivent éviter d’exécuter du code malveillant, comme dans le cas des injections SQL dans un formulaire Web.

        Pourquoi devrait-on remettre en cause la règle Unix qui interdit l'exécution de code sur un fichier extérieur, non audité, non reconnu.

        Les paquets de nos distrib sont compilés, audités, signés pour intégrer nos machines. Suffirait-il d'insérer une clé USB pour passer outre tout cela?

  • # ouin

    Posté par  . Évalué à 1.

    un rapide coup d'oeil à la concurrence http://www.zdnet.fr/actualites/l-autorun-dans-windows-c-est-(...)

    • [^] # Re: ouin

      Posté par  . Évalué à 2.

      l'autorun de la concurrence est un peu different vu qu'il lance un logiciel si present. Le nouveau truc c'est ce que fait linux actuellement c'est a dire propose un certains nombre d'action. Et c'est l'utilisateur qui choisit. Bon maintenant vu que le probleme numero 1 en securite c'est l'interface chaise-clavier cela ne risque pas de changer grand chose sauf par exemple, eviter les spywares sony (si cle sony)...

      • [^] # Re: ouin

        Posté par  . Évalué à 1.

        Attention, je crois que tu confonds l'autorun optique (sur les CD) qui effectivement est capable de faire un shellexec sur un programme ou un document, avec l'autorun sur support USB qui se comporte comme sous Gnome, c'est à dire avec une fenêtre avec des actions.

        une capture d'écran est dispo dans l'article http://www.zdnet.fr/actualites/windows-7-microsoft-desactive(...)

        Bon, maintenant, reste à sécuriser l'utilisateur

        • [^] # Re: ouin

          Posté par  . Évalué à 2.

          Tu es sur que avec un fichier autorun sur la cle usb cela ne le lance pas automatiquement comme sous pour les CDs?

          • [^] # Re: ouin

            Posté par  . Évalué à 2.

            Le même fichier autorun s'installe même sur les disques locaux quand un virus cherche à se propager.

            Double cliquer sur le disque depuis le poste de travail l’exécute.

            Testé positivement sur le disque d: d'un XP (avec Maj).

        • [^] # Re: ouin

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

          Euh, cela fonctionne avec tout disque amovible hein (mais après essai, pas les lecteurs réseau on dirait, heureusement !). Sous windows la fenêtre avec des actions c'est un fallback, c'est ce qui apparaît s'il n'y a pas eu d'autorun, justement !

          sur un media amovible quelconque (CD, clé usb, carte mémoire, appareil photo...), mettre à la racine un fichier autorun.inf
          écrire dedans
          [autorun]
          icon=mon-icone.ico

          et mettre aussi à la racine un fichier mon-icone.ico

          (j'ai réussi à en faire une reconnue par Windows avec GIMP en enregistrant au format 'Windows Icon' 24bpp, 1-bit alpha, no palette (non compressée)

          Lorsque votre média amovible sera automonté, vous aurez une jolie icone.

          D'ailleurs vous verrez (ou pas) que nautilus interprète le variable icon= de l'autorun et l'affiche, mais ne semble pas aller plus loin.

          TIP : j'ai pas encore trouvé de virus assez évolué qui sache écrire par dessus un fichier autorun.inf existant (même marqué en écriture), donc le fait de mettre soi-même un autorun est déjà un protection (àlacon).

          De plus, si un jour les virus seront un peu plus évolués pour ne pas seulement écrire un nouveau fichier, mais remplacer un existant, il faudra encore qu'ils savent interpréter le contenu du fichier autorun.inf déjà existant pour ajouter le shell code SANS retirer l'icône. Ainsi quand je monte mes clé USB sous windows et que mon icône est toujours là, j'ai déjà en partie vérifié que mon autorun.inf n'a pas été réécrit.

          ce commentaire est sous licence cc by 4 et précédentes

          • [^] # Re: ouin

            Posté par  . Évalué à 2.

            Oui c'est possible mais aucun interet, je connais peu de gens qui mette un autorun.inf sur tout leur périph usb...

            • [^] # Re: ouin

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

              c'est au contraire d'un très grand intérêt pour les créateurs de virus de mettre un autorun.inf sur le maximum de périph usb possible… c'est bien de cela qu'on parle non ?

              ce commentaire est sous licence cc by 4 et précédentes

  • # Actualité: Microsoft désactive l'autorun par défaut sous XP !

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

    C'est juste indiqué comme une mise à jour importante, mais pas de sécurité.

    - allo, le support technique de TrucSoft ?
    - oui, bonjour, que puis-j pour vous ?
    - ça marche plus. Quand je met le CD dans le lecteur, le programme ne démarre plus.

    ... des années de mauvaises habitudes à corriger ...


    Source: http://www.itnews.com.au/News/247616,microsoft-says-rip-wind(...)
    via : http://it.slashdot.org/story/11/02/09/2331218/Microsoft-Kill(...)

    Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

  • # Clé USB vu comme lecteur CD

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

    Sur la page d'un correctif plus ancien à installer soi-même cité par zdnet [http://support.microsoft.com/kb/971029], il est indiqué que « Certains lecteurs flash USB possèdent des microprogrammes qui présentent ces lecteurs flash USB comme des lecteurs CD lorsque vous les insérez dans un ordinateur. Ces lecteurs flash USB ne sont pas affectés par cette mise à jour. » comprendre : l'autorun fonctionne toujours.

    De fait j'ai déjà vu des cochonceté de clé USB qui apparaissent en plusieurs volumes, au moins un vu comme un disque pour les données, et un autre vu comme un CD et bardé d'un autorun et de crapwares infects, et l'insertion de ce genre de clé dans une bécane sous windows provoque l'exécution de code arbitraire et la modification du windows installé. Ce comportement est prévu par le constructeur de la clé USB ! beurk, à fuir.

    ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: Clé USB vu comme lecteur CD

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

      après recherche, je crois que ce sont les [[Clé_USB_U3]]
      C'est intéressant, on lit sur la page wikipedia qu'il existe un « utilitaire […], u3-tool . Ce logiciel libre permet de manipuler le CD virtuel (en le supprimant ou en le réecrivant). »,

      ce qui signifie qu'il est tout à fait possible pour un virus de modifier une clé U3-capable pour la rendre visible comme un CD, et donc de réactiver l'autorun. (ok ce n'est qu'un sous ensemble des clé USB, mais c'est faisable).

      ce commentaire est sous licence cc by 4 et précédentes

Suivre le flux des commentaires

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