Firefox - faille sérieuse - conseils?

eeried · Le 11/08/2015, à 12:24

Bonjour,

J'ai vu sur Linuxfr que Firefox a eu une jolie faille, vue le 6 août. C'est corrigé, bien sûr mais rien n'est très clair.
Et voici le billet de mozilla: https://blog.mozilla.org/security/2015/ … -the-wild/
J'utilise les backports de Debian et la version beta d'Iceweasel (40.0~b3-1~bpo80+1 0) mais personne ne sait si la faille existe depuis longtemps ni si elle a été exploitée car elle ne laisse aucune trace.

J'ai cru comprendre qu'il vaut mieux révoquer toutes ses clés et changer ses mots de passe. Mais les clés de Debian.mozilla par exemple ne sont pas modifiées et elles sont sur mon disque dur, évidemment. Ce n'est qu'un example. Aucune idée si ce genre de clés peut poser un problème de sécurité.

Changer ses mots de passe: ce n'est pas juste celui de Root ou de votre user, mais si je comprends bien tous ceux contenus dans votre KeepassX par exemple, si le fichier de config ou la base de données a comme nom une expression contenant le mot "pass" ou "access". Ouf, ce n'est pas mon cas. Sauf que dans le fichier ./.config/keepassx/config.ini, il y a le chemin vers le fichier de la base de données.
En tous cas: "I saw if the keepass file name has a .txt extension it would be stolen."

La seule consolation, c'est que je pense qu'avec NoScript, uBlockOrigin et Request Policy, on devrait avoir été protégé. Mais si on a autorisé Firefox PDF.js sur tel ou tel site?

Qu'en pensez-vous?

Caribou22 · Le 11/08/2015, à 12:55

Je suis la discussion. Je ne me suis jamais inquiété des failles sinon. J'espère qu'il n'y a pas plus de risques que d'habitude.

eeried · Le 11/08/2015, à 13:06

Bonjour Caribou22,

J'ai l'impression que cette faille est vraiment grave. Mais c'est un peu comme un troupeau de gnous traversant une rivière: certains vont se faire attraper par les crocodiles, les autres passeront indemmes.

En tous cas, je pense que pour GNU/Linux, on devrait avoir un fork de Firefox débarrassé de beaucoup de trucs superflus et potentiellement dangereux. Plus sérieux que Abrowser (Trisquel) ou Icecat. En général, les gens qui ont GNU/Linux mettent leur OS à jour et ne devrait pas avoir un vieil Adobe tout troué (ouais, enfin, on peut avoir un flash archaïque, gentiment bloqué par Firefox si j'ai bien compris).

Bon, je continue à lire (par ex. https://news.ycombinator.com/item?id=10021376 ) et on attend les avis des pros d'Ubuntu-fr :-)

serged · Le 11/08/2015, à 13:49

A priori la mise à jour Firefox 39.03 corrige le problème. Il a été mis à jour "d'urgence" dans les dépôts.

Sinon, un bloqueur de pub (j'utilise ublock, mais AdblokPlus devrait suffir) limite grandement les dégâts !

Caribou22 · Le 11/08/2015, à 13:52

J'ai aussi Ublock Origin et je boycotte de plus en plus Flash Player. Je pense que ça doit aussi limiter les risques.

N'oublions pas que pendant ce temps, d'autres utilisent encore Windows XP et Internet Explorer pour consulter leur compte bancaire...

eeried · Le 11/08/2015, à 14:09

@ serged: le problème n'est pas tant que ça vient d'être corrigé mais qu'on ne sait pas de quand ça date et depuis quand des données sensibles sont dans la nature.
Et en plus, pour la version Firefox beta, Mozilla ne dit pas si elle a été touchée ou non.

Non le bloqueur de pub n'a rien fait en l'occurrence. Il fallait au moins bloquer les iframes des sites tiers.

À toute fin utile voici ce qu'écrit le type, fukusa, qui a découvert la faille par hasard:

The exploit basically uploaded the contents of a bunch of sensitive files to some server. Besides uploading the full list of files in the User directory (not the contents of the files) it uploaded the contents of the following files:
Linux: /etc/passwd, /etc/hosts, /etc/hostname, /etc/issue, .bash_history, .mysql_history, .pgsql_history, .ssh/known_hosts, .ssh/authorized_keys, .ssh/id_sa, .remmina/.remmina, .remmina/.pref, .config/filezilla/.xml, .filezilla/.xml, pass.txt, access.txt, .sh, .config/psi+/profiles/default/accounts.xml

https://news.ycombinator.com/item?id=10021894

In this case, it was disguised as an advertisement but it was not running on an advertisement server. My adblocker did not catch it. It was injected into the page as an iframe twice. Once disguised as an ad ([IP-address]/ad.php), another time with just the IP-address of the server. I guess it was included a second time in case and adblocker catched the first one. Because it doesn't make sense to include the same exploit twice, unless I am missing something?
hokkos 3 days ago
How did you detected it ?

fukusa 3 days ago
The script triggered a file dialog showing it was trying to access a local file. I opened the Developer Tools and saw all kinds of other files being accessed, including my private and public keys. I nearly got a heart attack. I quickly revoked all SSH keys and started monitoring the requests to narrow it down before I submitted the bug ticket with all the information I had, including the exploit script that was executed.
fukusa 2 days ago
Update: I played around with the exploit some more to find out what exactly triggered the file dialog. Turns out my OS (Ubuntu 15.04) actually saved me.
When you try to open a file with Firefox it will first try to map the file to a mimetype using the ExternalHelperAppService (https://developer.mozilla.org/en-US/docs/How_Mozilla_determi...). In case a mimetype is found, a file dialog is shown so you can open the file with the right application, in case it is not, the contents of the file will be displayed in the browser. In this case my OS provided the ExternalHelperAppService with a mimetype for one of my public keys with the .pub file extension: application/vnd.ms-publisher. Of course that's not the correct mimetype for the public key file, but that's basically what saved me by showing a file dialog because it found a mimetype. All other files had no file extension so no mimetype was found.
I also discovered that my private keys were all encrypted with a passphrase so even though they have been compromised it was not as bad as I initially believed.

Bonne lecture :-)

vv221 · Le 11/08/2015, à 16:30

eeried a écrit :

Non le bloqueur de pub n'a rien fait en l'occurrence. Il fallait au moins bloquer les iframes des sites tiers.

Si je comprends bien, une extension comme RequestPolicy est une protection efficace contre ce type d’attaque ?

eeried · Le 11/08/2015, à 18:35

Plutôt NoScript qui bloque tous les scripts et uBlock Origin (que j'utilise au minimum, plutôt comme bloqueur de pub car NoScript fait du bon boulot) — mais bien vérifier la liste blanche de NoScript, j'ai tout largué et mis juste qqs sites au fur et à mesure. Ainsi, de nombreux sites s'affichent en vieux HTLM, mais ça me va. RequestPolicy est un bon complément. Les deux vont bien ensemble et se complètent.
Mais je me souviens d'avoir ouvert des PDF avec Firefox PDF.js mais je ne sais plus sur quel site et je ne sais plus quand. Donc, j'ai dû autoriser un peu de JS?

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 11/08/2015, à 12:24

Firefox - faille sérieuse - conseils?

#2 Le 11/08/2015, à 12:55

Re : Firefox - faille sérieuse - conseils?

#3 Le 11/08/2015, à 13:06

Re : Firefox - faille sérieuse - conseils?

#4 Le 11/08/2015, à 13:49

Re : Firefox - faille sérieuse - conseils?

#5 Le 11/08/2015, à 13:52

Re : Firefox - faille sérieuse - conseils?

#6 Le 11/08/2015, à 14:09

Re : Firefox - faille sérieuse - conseils?

#7 Le 11/08/2015, à 16:30

Re : Firefox - faille sérieuse - conseils?

#8 Le 11/08/2015, à 18:35

Re : Firefox - faille sérieuse - conseils?

Pied de page des forums