Discussion :

[Stéphane le calme]

Une vulnérabilité permettant des élévations de privilèges sur Linux est restée sous les radars pendant 9 ans,
« la plus grande jamais répertoriée sur Linux », selon un chercheur

Une situation de compétition a été trouvée dans la façon dont la mémoire du noyau du sous-système Linux géré la rupture de la copie sur écriture (COW) de mappings de mémoire en lecture seule. Pour rappel, une situation de compétition fait référence à un dysfonctionnement dû à un bogue, qui fait que dans un même logiciel deux automatismes qui travaillent simultanément donnent des résultats différents suivant l'automatisme qui termine avant l'autre.

Répertoriée comme étant CVE-2016-5195, cette faille critique est passée inaperçue pendant neuf ans et permet d’obtenir une élévation de privilèges. Des experts en sécurité, qui ont découvert un code d’attaque indiquant que la vulnérabilité a été largement exploitée, recommandent aux utilisateurs d’installer le correctif aussi vite que possible.

Dan Rosenberg, un chercheur senior pour le compte d’Azimuth Security, a estimé « qu’il s’agit la probablement de la plus grande élévation de privilèges jamais répertoriée sur Linux ». « La nature de la vulnérabilité se prête à une exploitation extrêmement fiable. Cette vulnérabilité est présente depuis neuf ans, ce qui est une très longue période de temps ».

La faille a été colmatée cette semaine par les responsables du noyau Linux. Les distributeurs downstream préparent une mise à jour qui embarque ce correctif. À ce propos, Linus Torvald a déclaré hier : « il s’agit là d’un ancien bogue que j’ai moi-même tenté une fois (mal) de corriger il y a 11 ans dans le commit 4ceb5db9757a ("Fix get_user_pages() race for write access") mais ça n’a pas été fait à cause du problème s390 soulevé par le commit f33ea7f404e5 ("fix get_user_pages bug"). Entre temps, le problème s390 a été corrigé depuis un moment déjà et nous pouvons corriger ce problème en vérifiant convenablement l’octet pte_dirty() (et le faire mieux) ».

Les vulnérabilités qui permettent une élévation des privilèges sont dangereuses parce qu’elles peuvent servir par exemple contre les hébergeurs web et permettre au pirate d’attaquer ses clients, voire même leurs propres services. Combinés avec d’autres attaques, ces exploits peuvent permettre de faire encore plus de dégât.

La découverte des attaques exploitant ces vulnérabilités est le fait de Phil Oester, un développeur Linux. Il explique que « n’importe quel utilisateur peut passer accéder à la racine en moins de 5 secondes d’après mes tests. La vulnérabilité est plus facile à exploiter avec un accès local à un système tel que les comptes shell. Même si cela fonctionne, elle est moins évidente à exploiter lorsqu’il faut passer par une vulnérabilité serveur web / application qui permet à l'attaquant de faire un upload de fichier sur le système touché et l’exécuter » .

Oester a trouvé un exploit en analysant le trafic de ses serveurs web : « l'exploit en particulier qui a été téléchargé sur mon système a été compilé avec GCC 4.8.5 released 20150623, bien que cela ne devrait pas impliquer que la vulnérabilité n’était pas disponible avant cette date compte tenu de sa longévité. Quant à savoir qui est ciblé, toute personne exécutant Linux sur un serveur Web est vulnérable ».

Source : Linus Torvalds, RedHat, Canonical, Phil Oester

[Max Lothaire]

J'aime bien les jeux de mots employés pour nommer ces failles

Sinon, j'ai essayé de regarder le code de l’exploit donné en exemple : https://github.com/dirtycow/dirtycow...b.io/wiki/PoCs, mais pas moyen de charger github.

[Aeson]

mais pas moyen de charger github.

un petit DDOS : https://www.hackread.com/ddos-attack...suffer-outage/


Sinon concernant la faille de 9 ans qui n'a pas ete trouvée dévoilée par la communautée... ca va encore partir en troll ce post...

[FatAgnus]

Sinon, j'ai essayé de regarder le code de l’exploit donné en exemple : https://github.com/dirtycow/dirtycow...b.io/wiki/PoCs, mais pas moyen de charger github.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
wget https://gist.githubusercontent.com/scumjr/17d91f20f73157c722ba2aea702985d2/raw/a37178567ca7b816a5c6f891080770feca5c74d7/dirtycow-mem.c
gcc -Wall -o dirtycow-mem dirtycow-mem.c -ldl -lpthread
./dirtycow-mem

Sur mon Ubuntu 16.04 (Linux 4.4.0-43) ça passe bien sous l'utilisateur root, mais mon système gèle au bout de quelques secondes, qui m'a obligé à le redémarrer électriquement.

[Aeson]

Je dis ca je dis rien... http://www.developpez.net/forums/d16...s/#post8775401

Rendre un soft OpenSource a mit down internet au US...

[marsupial]

un petit DDOS : https://www.hackread.com/ddos-attack...suffer-outage/


Sinon concernant la faille de 9 ans qui n'a pas ete trouvée dévoilée par la communautée... ca va encore partir en troll ce post...


//


Rendre un soft OpenSource a mit down internet au US...

C'est celui qui dit qu'y est comme on dit dans les cours de maternelle.


Pour la faille en elle même, je suis pour le minimaliste afin d'optimiser les ressources exploitées à condition de ne pas rogner sur la sécurité.

[Squisqui]

Pour la faille en elle même, je suis pour le minimaliste afin d'optimiser les ressources exploitées à condition de ne pas rogner sur la sécurité.

C'est un idéal plutôt difficile à atteindre. OpenBSD ne rogne jamais sur la sécurité, mais ça fait de lui un OS lent. Au risque de surprendre les experts en sécurité, il faut savoir faire des choix entre sécurité et performance. Par exemple, il est inutile d'avoir un système en béton armé si c'est pour le trouer en installant Xorg.
La vision de Linus Torvald consiste à tout mélanger et considérer les failles comme de simples bogues. En même temps, les bogues finissent toujours par être détourné un jour ou l'autre pour attaquer un système alors ça revient à peu près au même.

[yann2]

[B][SIZE=4]
Une situation de compétition a été trouvée dans la façon dont la mémoire du noyau du sous-système Linux géré la rupture de la copie sur écriture (COW) de mappings de mémoire en lecture seule.

Voilà ce qui se passe quand on traduit sans même essayer de comprendre....

[CaptainDangeax]

C'est léger comme faille. Pour être exploitée, elle nécessite d'avoir déjà un compte sur la machine concernée, avec la possibilité de compiler et d'exécuter. Dans cette situation, on peut aussi faire appel à John the ripper pour cracker le mot de passe root, hein ? La sécurité informatique commence par l'accès au bâtiment, la suite étant de savoir à qui et comment on file un accès.

[BufferBob]

C'est léger comme faille. Pour être exploitée, elle nécessite d'avoir déjà un compte sur la machine concernée, avec la possibilité de compiler et d'exécuter.

pas vraiment non, elle nécessite d'avoir un shell uniquement, lequel shell s'acquiert en général par le biais d'une autre vulnérabilité, on peut alors uploader sur la machine un binaire compilé pour l'occasion, en static, et pour l'architecture concernée
le propos de celle-ci est de gagner des privilèges root/administrateur, c'est un vrai problème d'autant plus qu'elle est facilement reproductible, exploitable et stable

Dans cette situation, on peut aussi faire appel à John the ripper pour cracker le mot de passe root, hein ?

ben non, si tu es en user TOTO t'auras du mal à cracker quoique ce soit, le hash du mot de passe root est en général dans un fichier /etc/shadow qui n'est lisible que par root, mauvais exemple donc

[Stéphane le calme]

Il est possible de rooter des téléphones Android en se basant sur la faille Dirty Cow,
qui a affecté Linux pendant 9 ans

Une nouvelle méthode pour rooter des appareils Android est susceptible de fonctionner de façon fiable sur toutes les versions du système d'exploitation mobile ainsi qu’un large éventail de matériel. Les particuliers peuvent l'utiliser pour contourner les limitations imposées par les constructeurs ou les opérateurs. La technique s’appuie sur la faille d’élévation de privilège sur Linux découverte il y a quelques jours et qui a été sous les radars pendant 9 ans. Baptisée Dirty Cow, qui tire son nom de l'abréviation des fonctionnalités Copy-On-Write du noyau, la faille CVE-2016-5195 a déjà été colmatée sur Linux (le 18 octobre 2016) ainsi que sur certaines distributions comme Red Hat, Ubuntu, Debian et SUSE.

Une liste de PoC est disponible sur GitHub et il suffit de rajouter quelques lignes de code pour rooter les dispositifs Android de façon persistante. C’est en tout cas ce qu’a expliqué le chercheur en sécurité David Manouchehri qui a testé son code sur cinq dispositifs. Parlant de l’exploit, il explique qu’il est accessible à « quelqu’un qui est quelque peu familier au système de fichiers Android ». « De ce que je peux dire, en théorie, cela devrait suffir à rooter tous les dispositifs depuis Android 1.0. Android 1.0 a débuté sur la version 2.6.25 du noyau Linux, et cet exploit existe depuis la version 2.6.22 ».

Un autre chercheur a expliqué que ses collègues et lui ont pu développer un exploit séparer pour rooter les dispositifs Android, encore une fois en se basant sur le PoC disponible sur GitHub. Ils ont été en mesure d’ajouter des fonctionnalités au système d’exploitation mobile. « Nous avons préféré utiliser un chemin unique que nous pourrons également utiliser ailleurs à l’avenir ». La vidéo ci-dessous montre le chercheur utiliser son application pour rooter un HTC tournant sur Android qui est relié à un ordinateur par un câble USB.

Les deux exploits permettent aux utilisateurs finaux de rooter des téléphones Android pour avoir accès à des fonctionnalités qui sont parfois limitées par les constructeurs ou les opérateurs téléphoniques comme le tethering (une technique qui permet de partager la connexion Internet d'un appareil mobile avec d'autres périphériques comme les ordinateurs portables : le téléphone est alors utilisé comme un modem). Le revers de la médaille est que le rootage est parfois fait subrepticement de telle sorte que les applications malveillantes peuvent espionner les utilisateurs en contournant le sandboxing des applications et d'autres mesures de sécurité intégrées à Android.

Source : GitHub (liste des PoC sur Dirty Cow)

[marsupial]

Préconisations :

* bannir les langages de scripts web ==> html5
* utiliser un add-on bloquant les scripts ==> de préférence en web assembly
* compartimenter les apps type sandbox/container
* géolocalisation à l'authentification
* stop consommer les ressources avec des applis useless ( surcouche logicielle constructeur )
* merci de coder vos apps en C/C++/Objective-C optimisé intelligemment
* recoder en normes françaises au pire, au mieux une spécifique pour les cas "urgents"

edit : * merci de toujours penser hack

Valable tout smartphone grand public.

Ou pas. Surtout.


A 7 milliards et quelques de smartphones dans le monde dont l'accès admin se protège par une séquence... je relève les copies l'été prochain.