134 liens privés
Un bug dans la bibliothèque glibc. Ça affecte une tonne de choses, sur des centaines de milliers de machines. Ça craint...
C'est corrigé et les mises à jours sont disponibles, mettez à jour.
"The widely used ssh, sudo, and curl utilities are all known to be vulnerable (...)"
Il y a un POC là : https://github.com/fjserna/CVE-2015-7547/blob/master/CVE-2015-7547-poc.py
(Je n'ai pas testé!)
Loin de moi l'idée de défendre Apple, je trouve que ce classement n'a pas beaucoup de sens ! On fait un classement des OS les plus vulnérables en fonction des vulnérabilités signalées... Et toutes celles qu'on ne trouve pas ?
Je suis un peu sceptique aussi avec le fait de séparer toutes les versions de Windows tout en rassemblant la multitude de systèmes GNU/Linux sous la banière "Linux kernel"...
J'ai survolé, ça semble intéressant.
(via http://lien.shazen.fr/?YLkVew , http://dooby.fr/links/?pQcSkQ , https://shaarli.e-loquens.fr/shaarli/?CUK76g et d'autres sur shaarli.fr )
Encore une vulnérabilité critique dans un programme de base utilisé sur GNU/Linux. Est-ce que les différentes failles plus ou moins récentes (Heartbleed, Shellshock, ..) ont poussé les experts en sécurité à faire plus d'audit ? C'est en tout cas une bonne chose que ces failles soient rendues publiques et corrigées, nos systèmes deviennent de plus en plus sûrs.
Je suis tout de même assez épaté qu'il reste des failles dans des logiciels tels que WGET qui sont utilisés depuis des années et des années.
J'ai testé chez moi :
| ========
| simon@ordi:~$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
| vulnerable
| this is a test
| ========
J'ai ensuite fait un "$ sudo aptitude update" , suivi d'un "$ sudo aptitude upgrade" et c'est apparemment corrigé. Ouf!
| ========
| simon@ordi:~$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
| bash: warning: x: ignoring function definition attempt
| bash: error importing function definition for `x'
| this is a test
| ========
J'ai installé logwatch et j'ai vu quelque chose qui m'a semblé suspect dans les logs :
| ========
| --------------------- httpd Begin ------------------------
| Requests with error response codes
| 400 Bad Request
| /w00tw00t.at.ISC.SANS.DFind:): 1 Time(s)
| ========
| J'ai cherché un peu et j'ai vu que ça correspondait à une requête d'un scanner de vulnérabilités ( DFind ). Pour le bloquer et jeter les paquets, on peut rajouter une règle iptables. Dans la foulée on rajoute une autre règle qui bloque les requêtes HTTP qui utilisent l'IP au lieu du nom de domaine : | ======== | simon@ordi:~$ sudo nano /etc/init.d/firewall | #Bloquer w00tw00t.at.ISC.SANS. | iptables -I INPUT -d xx.xx.xx.xx -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /w00tw00t.at.ISC.SANS.' -j DROP |
|---|---|---|---|---|
| #Bloquer toutes les requêtes HTTP qui utilisent l'IP au lieu du domaine | ||||
| iptables -I INPUT -d xx.xx.xx.xx -p tcp --dport 80 -m string --to 700 --algo bm --string 'Host: xx.xx.xx.xx' -j DROP | ||||
| ======== |
(xx.xx.xx.xx est à remplacer par l'IP du serveur.)
On actualise iptables :
| ========
| simon@ordi:~$ sudo /etc/init.d/firewall
| ========
On peut vérifier que les deux règles sont bien prises en compte :
| ========
| simon@ordi:~$ sudo iptables -L INPUT -nvx
| Chain INPUT (policy DROP 15 packets, 1188 bytes)
| pkts bytes target prot opt in out source destination
| 7 2912 DROP tcp -- 0.0.0.0/0 xx.xx.xx.xx tcp dpt:80 STRING match "Host: xx.xx.xx.xx" ALGO name bm TO 700
| 0 0 DROP tcp -- 0.0.0.0/0 xx.xx.xx.xx tcp dpt:80 STRING match "GET /w00tw00t.at.ISC.SANS." ALGO name bm TO 70
| ========
J'ai testé en tapant http://xx.xx.xx.xx dans firefox, j'ai eu une erreur (timeout) et je vois que 7 paquets ont été rejetés. :-)