Journal Faille critique sous Firefox: faut-il changer ses mots de passe?

Posté par  . Licence CC By‑SA.
Étiquettes :
21
7
août
2015

Une faille critique a été repéré par un utilisateur (Cody Crews ?): certaines publicités de sites web slaves essayaient d’exploiter une vulnérabilité dans le lecteur PDF intégré de Firefox. Donne javascript serait injecté pour accéder à certains fichiers.

On Linux the exploit goes after the usual global configuration files like /etc/passwd, and then in all the user directories it can access it looks for .bash_history, .mysql_history, .pgsql_history, .ssh configuration files and keys, configuration files for remina, Filezilla, and Psi+, text files with “pass” and “access” in the names, and any shell scripts.

https://blog.mozilla.org/security/2015/08/06/firefox-exploit-found-in-the-wild/
https://www.mozilla.org/en-US/security/advisories/mfsa2015-78/

Pour un simple utilisateur qui ne stocke pas de site web sur son ordinateur (c'est l'utilisation de /etc/passwd, non ?) le risque est nul, non ??

  • # Potentiellement très sérieux

    Posté par  . Évalué à 6.

    Je cite le communiqué :

    The exploit leaves no trace it has been run on the local machine. If you use Firefox on Windows or Linux it would be prudent to change any passwords and keys found in the above-mentioned files if you use the associated programs.

    En gros, si vous utilisez SSH, il se peut que vos clés privées soient maintenant dans la nature, avec les known_hosts associés! Autrement dit, non seulement un potentiel attaquant a pu recevoir vos clés, mais aussi la liste des serveurs sur lesquels ces dernières marchent!

    C'est extrêmement grave pour n'importe qui qui utilise SSH…

    Dans le thread de HackerNews associé (https://news.ycombinator.com/item?id=10021376), le gars qui a découvert le problème indique comment il s'en est aperçu et que Mozilla a réagi en moins de 16 heures. Ceci étant, ça reste très problématique parce que 1) on ne sait pas vraiment depuis quand ce bug était présent et 2) cette faille était déjà exploitée…

    Je pense que je vais passer ma soirée à révoquer mes clés moi…

    • [^] # Re: Potentiellement très sérieux

      Posté par  . Évalué à 2.

      Si tu as un mot de passe sur ta clé privée, elle est chiffrée.

      Donc si ton mot de passe est suffisamment fort, et si ta clé respecte les standards de sécurité actuels, il semble peu probable qu'elle soit utilisable par un attaquant.

      • [^] # Re: Potentiellement très sérieux

        Posté par  . Évalué à 6.

        Si on veut être puriste et respecter les standards de sécurité actuels, une clé privée doit être secrète, même avec une phrase de passe de furieux. Donc pour une sécurité maximale, il faudrait révoquer la clé privée et en regénérer une.

      • [^] # Re: Potentiellement très sérieux

        Posté par  . Évalué à 2.

        C'est vrai. Sauf que… parfois il y a les bonnes pratiques, et les pratiques pratiques…

        Le but de se logger par clé SSH est d'éviter de taper un mot de passe (et donc devoir taper sans cesse le mot de passe SSH n'est pas vraiment intéressant). Avec le recul, j'aurais dû mettre en place un ssh-agent mais bon… c'est facile de dire ça par après. En attendant je suis bon pour une petite leçon, et je n'ai que moi à blâmer là-dessus (bon, un peu Mozilla aussi, quand même) ;-)

        • [^] # Re: Potentiellement très sérieux

          Posté par  . Évalué à 7.

          Surtout que ssh-agent, avec gnome-keyring par dessus pour avoir un peu plus de facilité, c’est deux lignes dans un ~/.xsession :

          eval $(ssh-agent -s)
          eval $(gnome-keyring-daemon -d -s --components=pkcs11,secrets,ssh)

          Aller, tu n’as plus d’excuse :P

      • [^] # Re: Potentiellement très sérieux

        Posté par  . Évalué à 10.

        Donc si ton mot de passe est suffisamment fort, et si ta clé respecte les standards de sécurité actuels, il semble peu probable qu'elle soit utilisable par un attaquant.

        Par défaut avec OpenSSH, la clef AES avec laquelle la clef privée est chiffrée est dérivée de la phrase de passe par une seule itération de la fonction MD5. Il y a intérêt à ce que la phrase de passe soit vraiment forte pour que ça arrête un attaquant…

        OpenSSH 6.5 a introduit un nouveau format de stockage des clefs privées, avec lequel la clef de chiffrement est dérivée de la phrase de passe par 16 itérations (par défaut) de bcrypt, ce qui bloque plus efficacement les attaques par force brute.

        Donc, si vous utilisez OpenSSH 6.5 au moins, assurez-vous de générer vos clefs dans ce nouveau format, avec l’option -o de ssh-keygen :

        $ ssh-keygen -o -b 2048 -t rsa -f ma_nouvelle_clef

        ou convertissez vos anciennes clefs vers ce nouveau format :

        $ ssh-keygen -o -p -f mon_ancienne_clef

        (Ce changement n’affecte que la clef privée et ne concerne donc que le côté client. Une clef stockée dans ce format peut toujours être utilisée pour se connecter à un serveur OpenSSH antérieur à la version 6.5.)

        • [^] # Re: Potentiellement très sérieux

          Posté par  . Évalué à 3.

          Malheureusement, il semblerait que gnome-keyring n'aime pas ce nouveau format :'(

          $ ssh remote
Agent admitted failure to sign using the key.
Permission denied (publickey).

          Il faut donc le désactiver (pour l'instant je n'ai pas trouvé d'autre moyen que de ne pas "charger les services GNOME" dans xfce) et utiliser le ssh-agent normal, qui malheureusement est quand même moins user-friendly.

          Mais bon, vu que gnome-keyring ne supporte pas les autres formats que RSA et DSA c'est peut-être pas plus mal.

          J'aimerais un agent unique pour ssh, gpg, etc. qui gère bien les clés elliptiques, smartcard et autres nitro/yubikeys, mais je ne crois pas que ça existe à l'heure actuelle.

  • # Iceweasel sur Debian Stable

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

    Ca sent l'update de 31.8 à 38.1.1

    L'embêtant, c'est que ca risque de prendre quelques jours.
    En attendant, il faut mettre pdfjs.disabled à true dans about:config

  • # /etc/passwd

    Posté par  . Évalué à 5.

    Pour un simple utilisateur qui ne stocke pas de site web sur son ordinateur (c'est l'utilisation de /etc/passwd, non ?) le risque est nul, non ??

    Non, c'est un fichier qui contient des renseignements sur les comptes utilisateurs : nom, id, home, shell… Fût un temps ou ce fichier contenait aussi les mots de passe. Mais ça, c'était avant. Un petit coup de man passwd pourra te donner plus de renseignements.

    • [^] # Re: /etc/passwd

      Posté par  . Évalué à 3.

      Comme il y a aussi une commande passwd, il vaut mieux regarder man 5 passwd pour avoir les infos sur le fichier.

      • [^] # Re: /etc/passwd

        Posté par  . Évalué à 3.

        Je dirais plutôt man 5 shadow, fichier qui normalement n'est lisible que par root. Donc à moins qu'il y ait escalade de privilège, c'est normalement sans danger de ce côté-là.

        • [^] # Re: /etc/passwd

          Posté par  . Évalué à 1.

          Merci pour vos éclairages techniques.

  • # javascript ?

    Posté par  (site web personnel, Mastodon) . Évalué à 5.

    Je n'ai pas trop lu toutes les explications, mais comment un lecteur javascript peut avoir accès à ces fichiers ? C'est pas sensé être isolé ? Si quelqu'un peut expliquer je suis preneur.

    Ah, sur le lien pointé plus haut on peut lire:
    « Tech lead of pdf.js here: All of the above exploits were issues with extension code in firefox, i.e. other extensions could have these issues too. If you were to use the web only version of pdf.js none of these exploits would apply. »

    Il y a donc des extensions possibles au lecteur pdf ? C'est via les extensions classiques ? Bon moi de toute façon je l'ai désactivé immédiatement, je préfère nettement okular.

    • [^] # Re: javascript ?

      Posté par  . Évalué à 1.

      Enfin méfie toi quand même, c'est pas parce que dans les préférences de Firefox tu as désactivé l'ouverture de pdf dans le navigateur que la faille ne peut pas avoir lieu, c'est sûrement un peu plus compliqué (par exemple, peut-être que Firefox autorise quand même le lecteur web s'il y a une balise spéciale, ou si c'est à l'intérieur de la page, ou autre chose).

  • # Protection

    Posté par  . Évalué à 7.

    On en vient à souhaiter que Firefox tourne dans un environnement confiné (avec seulement accès au répertoire privé de Firefox - $HOME/.firefox), et que tout autre accès au système de fichiers, notamment, pour uploader un fichier, doive passer par un démon séparé qui ouvre une boîte de dialogue à chaque fois.

  • # avec les bonnes extensions

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

    certaines publicités de sites web slaves essayaient d’exploiter une vulnérabilité dans le lecteur PDF intégré de Firefox.

    D’où l’intérêt de toujours avoir adblock*, no script et google disconnect ?
    De même que de toujours lire les pdf avec un vrai lecteur ainsi que de ne pas traîner sur des sites louches ? (fail, je traîne sur la tribune /o)

  • # Conteneur

    Posté par  . Évalué à 5.

    Domage qu'il ne soit pas plus simple d'isoler des applis dans des conteneurs linux.

    Surtout des applis qui sont devenues des usines a gaz comme les navigateur : lecteur multimédia, pdf, machine virtuelle, …

    D'autant plus que pour être user friendly toutes ces fonctions sont actives par défaut sans intervention de l'utilisateur.

    • [^] # Re: Conteneur

      Posté par  . Évalué à 1.

      D'autant plus que pour être user friendly toutes ces fonctions sont actives par défaut sans intervention de l'utilisateur.

      Tu imagines si on devait questionner l'utilisateur sur des détails techniques lui qui est souvent ignorant de tout?

      • [^] # Re: Conteneur

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

        C'est technique, mais c'est malheureusement pas des détails, c'est bien le problème…

        La lumière pense voyager plus vite que quoi que ce soit d'autre, mais c'est faux. Peu importe à quelle vitesse voyage la lumière, l'obscurité arrive toujours la première, et elle l'attend.

Suivre le flux des commentaires

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