La Fibre
Télécom => Réseau => 
Attaques informatiques => Discussion démarrée par: BadMax le 21 octobre 2016 à 08:34:25
-
Celle-là, elle va faire mal.
http://arstechnica.com/security/2016/10/most-serious-linux-privilege-escalation-bug-ever-is-under-active-exploit/
Any user can become root in < 5 seconds in my testing, very reliably. Scary stuff.
The vulnerability is easiest exploited with local access to a system such as shell accounts. Less trivially, any web server/application vulnerability which allows the attacker to upload a file to the impacted system and execute it also works.
The particular exploit which was uploaded to my system was compiled with GCC 4.8.5 released 20150623, though this should not imply that the vulnerability was not available earlier than that date given its longevity. As to who is being targeted, anyone running Linux on a web facing server is vulnerable.
For the past few years, I have been capturing all inbound traffic to my webservers for forensic analysis. This practice has proved invaluable on numerous occasions, and I would recommend it to all admins. In this case, I was able to extract the uploaded binary from those captures to analyze its behavior, and escalate to the appropriate Linux kernel maintainers.
-
L'exploit circule:
https://raw.githubusercontent.com/dirtycow/dirtycow.github.io/master/dirtyc0w.c
-
m'enfin la 'surface d'attaque' est quand meme limitée.
-
Celle-là, elle va faire mal.
http://arstechnica.com/security/2016/10/most-serious-linux-privilege-escalation-bug-ever-is-under-active-exploit/
Any user can become root in < 5 seconds in my testing, very reliably. Scary stuff.
The vulnerability is easiest exploited with local access to a system such as shell accounts. Less trivially, any web server/application vulnerability which allows the attacker to upload a file to the impacted system and execute it also works.
The particular exploit which was uploaded to my system was compiled with GCC 4.8.5 released 20150623, though this should not imply that the vulnerability was not available earlier than that date given its longevity. As to who is being targeted, anyone running Linux on a web facing server is vulnerable.
For the past few years, I have been capturing all inbound traffic to my webservers for forensic analysis. This practice has proved invaluable on numerous occasions, and I would recommend it to all admins. In this case, I was able to extract the uploaded binary from those captures to analyze its behavior, and escalate to the appropriate Linux kernel maintainers.
C'est un peu exagéré,dans le code :
int f=open("/proc/self/mem",O_RDWR);
Il faut déjà pouvoir y accéder.
-
En environnement chrooté, tu ne devrais pas pouvoir.
Mais pour tout le reste, ça passe. J'ai testé la faille, elle marche partout sauf sur ma Slack en kern 2.6.37.6
-
IL y a un site internet dédié à la faille : http://dirtycow.ninja/
A noter que les PC sous Ubuntu qui téléchargent automatiquement les mises-à-jour sont déjà corrigés, sous réserve d'avoir été redémarrées.
(Le correctif a été poussé le 19 octobre)
Le noyaux qui intègrent le correctif sont :
- 4.8.0.26 (Ubuntu 16.10)
- 4.4.0.45 (Ubuntu 16.04 LTS)
- 3.13.0-100 (Ubuntu 14.04 LTS)
- 3.2.0-113 (Ubuntu 12.04 LTS)
Les autres versions d'Ubuntu ne sont plus maintenues.
Pour filtrer les log d'un serveur miroir : grep -E "/linux/linux-image-4.8.0.26|/linux/linux-image-4.4.0.45|/linux/linux-image-3.13.0-100|/linux/linux-image-3.2.0-113" access.log
-
IL y a un site internet dédié à la faille : http://dirtycow.ninja/
J'adore le nom.
-
"plus importante faille Linux jamais découverte" <- euh c'est pas un poil racoleur et exagéré ?
-
"plus importante faille Linux jamais découverte" <- euh c'est pas un poil racoleur et exagéré ?
Ce journaliste cite un 'expert' qui travaille pour une boite de sécurité... boites dont le CA augmente chaque fois que la presse parle de ce genre de chose.
Ca me rappelle l’excitation qu'il y a eu en aout concernant la faille Stagefright et Android ... ce qu'on a pu lire a l'époque dans la presse s'approchait de la fin du monde tellement c'était "grave", bien pire que celle ci... sauf que quelques jours plus tard plus personne en parlais. Et comme par hasard la boite qui a rendu cela public l'a fait 1 jour avant la conférence ou elle présentait un nouveau produit pour Android...
Il y a un petit jeu entre les médias et les boites de sécurité car chacun y trouve son compte et au royaume des aveugles les borgnes gagnent de l'argent.
Il commence a y avoir un tel business autour de la sécurité, business basé sur la peur et la comm, que les dérives sont déjà la et ne font que s'accentuer de plus en plus.
-
Ce journaliste cite un 'expert' qui travaille pour une boite de sécurité... boites dont le CA augmente chaque fois que la presse parle de ce genre de chose.
Ca me rappelle l’excitation qu'il y a eu en aout concernant la faille Stagefright et Android ...
Qui invente les noms des faille? Des publicitaires?
Il y a des experts pour ça?
-
"plus importante faille Linux jamais découverte" <- euh c'est pas un poil racoleur et exagéré ?
Quand même, une faille
- qui fait passer root
- qui est dans du code de base (pas dans un module optionnel)
c'est pas rien.
Enfin bref, ces choses sont passablement subtiles, l'histoire "tout le monde peut lire le code" est une plaisanterie.
Rien que la taille du bouzin....
-
On a déjà connu ptrace dans le passé qui a fait bien des dégâts à une époque où les gens étaient moins sensibilisés à la sécurité.
Je sais bien que le sensationnel c'est alléchant, mais bon. On n'a même pas le recul des impacts encore...
-
On a déjà connu ptrace dans le passé qui a fait bien des dégâts ()
Tu peux préciser?
-
Tu peux préciser?
https://www.google.fr/?gws_rd=ssl#q=ptrace+exploit
https://linuxfr.org/news/faille-de-s%C3%A9curit%C3%A9-dans-le-noyau-linux
https://www.giac.org/paper/gcih/467/tracing-ptrace-case-study-internal-root-compromise-incident-handling/105271
Couplé à l'époque dans un timing assez proche à une faille de sécurité PHP qui permettait de lancer des commandes systèmes avec le user web, le combo a permis à des gens de prendre le contrôle en remote de serveurs et d'y exécuter ptrace pour en devenir root.
-
J'ai vu passé une information à ce sujet de Linus Torvald, (il me semble que la faille provenait de l'intégration de matériel IBM S90 ,et que c'était un contournement pour la gestion de la mémoire )
La modification a été prise en compte pour le noyau le 20161013
-
J'ai vu passé une information à ce sujet de Linus Torvald, (il me semble que la faille provenait de l'intégration de matériel IBM S90 ,et que c'était un contournement pour la gestion de la mémoire )
En fait la faille n'est pas liée à S390, mais une tentative de correction du bug il y a 11 ans avait été retirée car elle posait problème sous S390 :
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619 (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619).
Chose intéressante, personne n'a su mesurer la conséquence de ce bug pourtant identifié et la faille de sécurité que cela pourrait représenter quelques années plus tard :
Also, the VM has become more scalable, and what used a purely theoretical race back then has become easier to trigger.
Une partie non négligeable des distributions (RHEL5/6 et dérivés), bien que vulnérable, n'a pas d'exploit public :
> The in the wild exploit we are aware of doesn't work on Red Hat Enterprise
> Linux 5 and 6 out of the box because on one side of the race it writes to
> /proc/self/mem, but /proc/self/mem is not writable on Red Hat Enterprise
> Linux 5 and 6.
EDIT : en fait, si : il y a une autre exploit qui fonctionne sans /proc/self/mem (avec ptrace) :
https://github.com/dirtycow/dirtycow.github.io/blob/master/pokemon.c (https://github.com/dirtycow/dirtycow.github.io/blob/master/pokemon.c)
-
Ce journaliste cite un 'expert' qui travaille pour une boite de sécurité... boites dont le CA augmente chaque fois que la presse parle de ce genre de chose.
...Mouais ! Ça me rappelle un certain article "Samsung veut écraser le Raspberry Pi 3 avec Artik 10 (https://lafibre.info/nas/sortie-nouveau-rpi-3/msg333327/#msg333327)" et la réponse que tu avais faite à l'époque (https://lafibre.info/nas/sortie-nouveau-rpi-3/msg333611/#msg333611) !!! (https://lafibre.info/images/smileys/@GregLand/ao.gif)
-
"plus importante faille Linux jamais découverte" <- euh c'est pas un poil racoleur et exagéré ?
Ouais c'est pas la première, puis elle a été corrigée, c'est pas un Zero Day.
-
Ouais c'est pas la première, puis elle a été corrigée, c'est pas un Zero Day.
Définis "Zero Day"!
Ou alors, n'utilise pas une notion aussi mal définie!
Et oserais-je dire merdique?
Oui, j'ose.
-
Ou alors, n'utilise pas une notion aussi mal définie!
lol?
A zero-day (also known as zero-hour or 0-day or day zero) vulnerability is an undisclosed computer-software vulnerability that hackers can exploit to adversely affect computer programs, data, additional computers or a network. It is known as a "zero-day" because it is not publicly reported or announced before becoming active, leaving the software's author with zero days in which to create patches or advise workarounds to mitigate against its actions.
https://en.wikipedia.org/wiki/Zero-day_(computing)
-
Voilà, c'est donc absolument indéfinissable.
CQFD
-
Voilà, c'est donc absolument indéfinissable.
CQFD
Effectivement, qu'est-ce que tu as bien démontré !
-
Si tu en entends parler, c'est que la vulnérabilité n'est pas inconnue.
Donc, une vuln donnée n'est pas une 0 day.
-
Si tu en entends parler, c'est que la vulnérabilité n'est pas inconnue.
Donc, une vuln donnée n'est pas une 0 day.
Tu peux en parler sans en avoir les détails. Tu peux aussi avoir les informations sans qu'elles soient publiques.
Dans le cas de CVE-2016-5195 la vulnerabilité a été corrigée 1 jour avant la notification.
-
Dans le cas de CVE-2016-5195 la vulnerabilité a été corrigée 1 jour avant la notification.
Corrigée, ça dépend de quelle source on parle.
Certains distributeurs majeurs comme RedHat ne l'ont toujours pas fait alors que les exploits sont disponibles.
-
Tu es sur que RedHat n'a pas distribué le correctif ?
Cela m'étonne fortement.
Pour Ubuntu, il est disponible depuis le 20 octobre à 5h45 du matin, sur le serveur de mise à jour utilisé par défaut en France (http://fr.archive.ubuntu.com)
Comme je gère ce serveur, j'ai réalisé quelques stats. J'ai bien nettoyé les log de tout ce qui est script et j'ai également par mégarde supprimé les mises à jour réalisées depuis un mobile (le serveur reçois le code 304 - Document non modifié depuis la dernière requête, car il est en cache coté FAI).
Nombre de mises à jour du noyau correctif par heure :
(https://lafibre.info/testdebit/ubuntu/201610_stats_ubuntu_repartition_horaire.png)
Le nombre de machines non patchées dois être encore très important.
Nombre de mises à jour du noyau correctif par heure et par distribution :
(https://lafibre.info/testdebit/ubuntu/201610_stats_ubuntu_repartition_horaire_par_distribution.png)
Je rappelle que les autres version d'Ubuntu ne sont plus maintenues.
Nombre de mises à jour du noyau correctif par heure par architecture : (i386 = 32bits / AMD64 = 64bits)
(https://lafibre.info/testdebit/ubuntu/201610_stats_ubuntu_repartition_horaire_par_architecture.png)
Voici un fichier Calc avec les données sources, si vous pensez qu'il y a d'autres graphes à faire : 201610_stats_ubuntu.ods (https://lafibre.info/testdebit/ubuntu/201610_stats_ubuntu.ods)
(lisible avec Libre office Calc et Microsoft Excel)
-
D'autres statistiques, sur les 3 premiers jours et demi de mise à disposition du correctif :
Répartition par distribution :
(https://lafibre.info/testdebit/ubuntu/201610_stats_ubuntu_repartition_par_distribution.png)
Répartition par distribution et par architecture : (i386 = 32bits / AMD64 = 64bits)
(https://lafibre.info/testdebit/ubuntu/201610_stats_ubuntu_repartition_par_architecture.png)
-
Kernel utilisés pour Ubuntu 16.04 LTS :
(https://lafibre.info/testdebit/ubuntu/201610_stats_kernel_pour_ubuntu_1604.png)
Kernel utilisés pour Ubuntu 14.04 LTS : (les autres kernels d'Ubuntu 14.04 ne sont plus maintenus depuis août 2016, il est demandé à ceux qui ont un kernel autre de migrer vers le 4.4 pour avoir la mise à jour de sécurité)
(https://lafibre.info/testdebit/ubuntu/201610_stats_kernel_pour_ubuntu_1404.png)
Kernel utilisés pour Ubuntu 12.04 LTS : (les autres kernels d'Ubuntu 12.04 ne sont plus maintenus depuis août 2014)
(https://lafibre.info/testdebit/ubuntu/201610_stats_kernel_pour_ubuntu_1204.png)
-
Statistiques sur l'architecture utilisée pour les Kernel low-latency (seuls Ubuntu 14.04 / 16.04 / 16.10 sont concernés)
(https://lafibre.info/testdebit/ubuntu/201610_stats_kernel_low-latency.png)
Statistiques sur l'architecture utilisée pour les Kernel génériques avec Ubuntu 14.04 / 16.04 / 16.10 :
(https://lafibre.info/testdebit/ubuntu/201610_stats_kernel_generic.png)
Ubuntu 12.04 à un kernel PAE et non PAE pour le 32bits, voici la répartition des kernel 3.2 :
(https://lafibre.info/testdebit/ubuntu/201610_stats_kernel_32.png)
PAE permet de dépasser 4Go de ram avec un kernel 32bits, mais il n'est pas pris en charge par tous les processeurs (pour Intel c'est depuis le Pentium Pro, mais des intels compatibles l'ont mis en place bien plus tard)
Note : 3.2.0-113-virtuel-i386 existe bien mais il est très peu utilisé.
-
Tu es sur que RedHat n'a pas distribué le correctif ?
Cela m'étonne fortement.
Oui certain c'est toujours en statut pending et ça commence à sérieusement râler chez les clients...
https://access.redhat.com/security/vulnerabilities/2706661 (https://access.redhat.com/security/vulnerabilities/2706661)
-
Effectivement... c'est toujours en pending.
On sait pourquoi l'info a fuitée ?
Normalement une faille n'est pas détaillée avant que la majorité des clients ait patché la chose...
(https://lafibre.info/testdebit/ubuntu/201610_CVE20165195_Kernel_Local_Privilege_Escalation.png)
-
Effectivement... c'est toujours en pending.
On sait pourquoi l'info a fuitée ?
Normalement une faille n'est pas détaillée avant que la majorité des clients ait patché la chose...
Fuitée ?
Y'a un bug, il est corrigé, fin de l'histoire
-
Effectivement... c'est toujours en pending.
On sait pourquoi l'info a fuitée ?
Normalement une faille n'est pas détaillée avant que la majorité des clients ait patché la chose...
En fait, RedHat ne la considère pas comme critique, mais "importante", donc sans urgence de corriger. Il n'y a pas d'exécution à distance.
-
Le correctif a été publié par RedHat. Il faut attendre maintenant qu'il soit mis à disposition dans les distributions dérivées, CentOS, Scientific Linux...., mais cela devrait être rapide.
https://rhn.redhat.com/errata/RHSA-2016-2098.html
-
Le correctif a été publié par RedHat.
Uniquement pour RH7, donc pas la majorité des RHEL, loin de là.
Ceci dit Oracle fait encore pire : ils ne référencent même pas le CVE alors que tous les Oracle Linux, Oracle VM sont probablement vulnérables...
-
A priori, de ce que j'ai lu, RHEL 6 et 5 n'étaient pas vulnérables.
P. S :
From what I have read and test, the exploit is working only on Centos 7/ RHEL7 / Cloudlinux 7 distros .
https://gryzli.info/2016/10/21/protect-cve-2016-5195-dirtycow-centos-7rhel7cpanelcloudlinux/
-
A priori, de ce que j'ai lu, RHEL 6 et 5 n'étaient pas vulnérables.
Tu as mal compris :-)
Ils sont bien vulnérables mais l'exploit initiale qui circulait ne fonctionnait pas sur ces versions car basée sur /proc/self/mem qui n'est accessible qu'en lecture sous RH5/6.
Mais d'autres exploit circulent basées sur ptrace et fonctionnent bien sous RH5/6
-
La réponse officiel de RedHat sur RHEL5 et RHEL6 :
RHEL5 and RHEL6 are vulnerable. However, the in the wild exploit we are aware of doesn't work on RHEL5 and RHEL6 out of the box, see Bugzilla bug (https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c16) for details.
-
Fuitée ?
Y'a un bug, il est corrigé, fin de l'histoire
Les bug, il y en a tous les jours et quel que soit le produit (os, navigateur web, ...), ils attendent toujours que le bug soit corrigé et largement distribué avant de donner les détails permettant de réaliser un exploit.
Là tout a été révélé le lendemain de la sortie du correctif, donc je me pose des questions.
Pour rappel, là j'imagine que la publication n'a pas été réalisée suite à une expiration de délai comme c'est de temps en temps le cas avec les failles Microsoft et Apple.
Microsoft se fâche contre Google après la publication de failles zero-day dans Windows
Le géant du Web a publié par deux fois sur le web des failles de Windows 8 dans le cadre de son programme « Projet Zero ». Mais la méthode suscite des critiques de la part de Microsoft.
C’est une lettre au ton mesuré, mais qui transpire le mécontentement. Elle est signée Chris Bentz, patron du Microsoft Security Response Center, et fait suite à la publication de deux failles zero-day dans Windows 8.1 par les équipes du Projet Zero de Google.
Cette « unité d’élite » de hackers, en croisade contre les failles de sécurité, a des méthodes expéditives. Lorsqu’elle découvre une faille, le Projet Zero prévient l’éditeur concerné et lui laisse 90 jours pour la réparer. S’il ne corrige pas le problème, la faille est alors publiée sur le Web et est donc accessible à tous, y compris à de potentiels cybercriminels.
C’est exactement ce qui est arrivé par deux fois à Microsoft, qui n’a pas comblé les failles de Windows 8 avant le délai des 90 jours. Et de voir des millions de ses clients Windows 8 exposés à une faille de sécurité par Google ne plait pas du tout, du côté de Redmond. « Google a publié des informations sur une vulnérabilité dans un produit Microsoft deux jours avant la publication de notre correctif dans le cadre de notre fameux Patch Tuesday, alors que nous leur avions demandé de ne pas le faire » écrit Bentz. Qui précise : « nous avions demandé à Google de travailler avec nous afin de protéger nos clients en ne révélant pas de détails avant mardi 13 janvier, au moment où nous publierons le correctif. »
« Ce qui est bon pour Google ne l’est pas forcèment pour les clients »
Alors que Google estime que ses « coups de pression » vont forcer les éditeurs à corriger les failles plus vite, Microsoft préfère ce qu’il appelle « la divulgation coordonnée de vulnérabilités ». Autrement dit : celui qui découvre la faille prévient discrètement l’éditeur visé, qui la corrige avant que des informations ne soient publiées sur la Toile. Selon Bentz, la décision de Google « tient moins de principes que du ‘je t’ai eu !’ […] Ce qui est bon pour Google ne l’est pas forcèment pour les clients. Et nous exhortons Google de faire de la protection des consommateurs notre but collectif premier ».
Une défense louable, mais qui vient peut-être un peu tard. Car Microsoft a une longue histoire de vulnérabilités qu’il a tardé à corriger, comme le rappelle Robert Graham, hacker et patron d’Errata Security. Sur son blog, ce vieux brisard de la sécurité informatique décrit comment les vulnérabilités étaient gérées par l’éditeur de Windows il y a une dizaine d’années. « Microsoft dictait à l’époque la manière dont les vulnérabilités étaient reportées. Les chercheurs qui découvraient de tels bugs devaient informer les éditeurs en secret et leur donner tout le temps nécessaire pour les corriger. Microsoft a parfois attendu des années avant d’en corriger certains et profitait du fait qu’il était en mesure de blacklister des chercheurs pour les faire taire. » Visiblement, les temps ont changé…
Source : Microsoft (https://blogs.technet.microsoft.com/msrc/2015/01/11/a-call-for-better-coordinated-vulnerability-disclosure/), le 11 janvier 2015 traduction 01net
-
Le catalogue des exploits : ceux basés sur ptrace fonctionnent sous RH5/6 :
https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs (https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs)
Il me semble que celui qui a redécouvert le bug a annoncé qu'il avait tracé un exploit à l'occasion d'une analyse d'attaque, donc cet exploit circulait depuis un moment...
Expliqué ici : http://www.v3.co.uk/v3-uk/news/2474845/linux-users-urged-to-protect-against-dirty-cow-security-flaw (http://www.v3.co.uk/v3-uk/news/2474845/linux-users-urged-to-protect-against-dirty-cow-security-flaw)
-
En fait, RedHat ne la considère pas comme critique, mais "importante", donc sans urgence de corriger. Il n'y a pas d'exécution à distance.
Ah ah MDR lol
-
Effectivement... c'est toujours en pending.
On sait pourquoi l'info a fuitée ?
Normalement une faille n'est pas détaillée avant que la majorité des clients ait patché la chose...
Heu... n'importe quoi!
Déjà il faut bien expliquer le problème aux gens. Est-ce que tu penses que "logiciel libre" rime avec "un petit cercle de oins du seigneurs qui s'échangent et conservent des informations confidentielles critiques ce qui leur donne un avantage énorme sur la populace"?
Ensuite :
"The exploit in the wild is trivial to execute, never fails and has probably been around for years - the version I obtained was compiled with gcc 4.8," he said.
"As Linus [Torvalds] notes in his commit, this is an ancient bug and impacts kernels going back many years. All Linux users need to take this bug very seriously, and patch their systems ASAP."
http://www.v3.co.uk/v3-uk/news/2474845/linux-users-urged-to-protect-against-dirty-cow-security-flaw
-
Les bug, il y en a tous les jours et quel que soit le produit (os, navigateur web, ...), ils attendent toujours que le bug soit corrigé et largement distribué avant de donner les détails permettant de réaliser un exploit.
Là tout a été révélé le lendemain de la sortie du correctif, donc je me pose des questions.
Pour rappel, là j'imagine que la publication n'a pas été réalisée suite à une expiration de délai comme c'est de temps en temps le cas avec les failles Microsoft et Apple.
Beuhh, tu vis dans un triste monde
On parle d'un monde ouvert, le code est disponible, les corrections sont disponibles, toute personne intelligente et culturé peut se renseigner sur les implications d'un bug, et en déduire une exploitation éventuelle
-
Beuhh, tu vis dans un triste monde
On parle d'un monde ouvert, le code est disponible, les corrections sont disponibles, toute personne intelligente et culturée peut se renseigner sur les implications d'un bug, et en déduire une exploitation éventuelle.
(https://lafibre.info/images/smileys/@GregLand/ap.gif)
-
At last :
errata-xmlrpc 2016-10-26 07:42:50 EDT
This issue has been addressed in the following products:
Red Hat Enterprise Linux 6
Via RHSA-2016:2105 https://rhn.redhat.com/errata/RHSA-2016-2105.html
Manque plus que RH5, encore un effort...