Comment corriger la dernière faille 0-day de Linux et Android
Sécurité : Si la faille affectant Android et Linux n'est pas aussi critique qu'il y paraît, les administrateurs Linux doivent malgré tout s'y attaquer.
La société israélienne spécialisée dans la sécurité, Perception Point, a divulgué une vulnérabilité dans Linux et Android. La société décrit cette zero-day comme une "vulnérabilité d'élévation locale de privilèges dans le noyau Linux". C'est effectivement ce qu'elle est, mais ce n'est pas toute l'histoire.
Ce que Perception Point n'a pas dit, c'est qu'après la découverte de la faille, leur découverte (CVE-2016-0728) a été envoyée en amont pour correction aux développeurs du noyau Linux. La seule raison pour laquelle c'était une "zero-day", c'est parce que Perception Point a lui-même mis à disposition un exploit alors que le patch était déjà en cours de développement.
Pourquoi feraient-ils cela ? "Il s'agit de promouvoir des entreprises dont personne n'a entendu parler jusqu'à preuve du contraire. De cette façon, ils font les gros titres et nous héritons des maux de tête en matière de sécurité" commente un développeur sécurité sur Linux.
Ce qui, selon un autre programmeur travaillant sur la résolution du problème, est loin d'être un cas isolé. "Les entreprises de sécurité font toujours une grosse histoire de petits problèmes pour leur propre bénéfice."
Dans le cas présent, la faille de sécurité pourrait exploiter le keyring de Linux, une fonctionnalité utilisée pour mettre en cache différents types de données liées à la sécurité telles que des clefs de chiffrement. En soi, ce n'est pas trop grave. Les problèmes surviennent quand le champ utilisé pour stocker le nom d'un objet est exploité pour causer un débordement. Un attaquant va pouvoir écraser la mémoire et provoquer un exploit en escalade de privilèges. En résumé, oui un utilisateur ordinaire peut obtenir les droits d'un "super-utilisateur".
Ce n'est pas une bonne nouvelle, mais pas autant qu'il semble. D'abord, vous avez besoin d'un compte utilisateur. Au minimum, un attaquant aurait besoin de disposer sur le système cible d'un login et d'un compte shell.
En outre, pour une fois, ce problème n'affecte pas les anciens systèmes. Seules les distributions Linux utilisant les versions 3.10 ou suivantes du noyau Linux peuvent être attaquées. Linux 3.10 est disponible depuis août 2013.
Plus spécifiquement, les distributions suivantes sont théoriquement vulnérables :
- CentOS Linux 7
- Debian Linux stable 8.x (jessie)
- Debian Linux testing 9.x (stretch)
- Fedora 21 et suivantes
- Scientific Linux 7
- openSUSE Linux LEAP 42.x et version 13.x
- Oracle Linux 7
- Red Hat Enterprise Linux (RHEL) 7
- SUSE Linux Enterprise Desktop 12
- SUSE Linux Enterprise Server (SLES) 12
- Ubuntu Linux 14.04 LTS (Trusty Tahr)
- Ubuntu Linux 15.04 (Vivid Vervet)
- Ubuntu Linux 15.10 (Wily Werewolf)
Même sur ces systèmes, l'exploit mis en ligne ne fonctionne pas. J'ai essayé moi-même sur un système Fedora 23 avec 8 Go de RAM. Cela a finalement verrouillé le PC une fois la mémoire libre épuisée. D'autres rapportent que cette attaque a échoué en raison de l'épuisement de la mémoire.
Si cette méthode peut être exploitée pour attaquer des terminaux Android 4.4 et versions suivantes, une telle attaque n'a cependant pas de sens. D'abord, il faut avoir le terminal en main. Ensuite, il faudrait plus de mémoire que je n'en ai jamais vue sur un terminal Android. Enfin, comme Perception Point le reconnaît, "l'exploit complet nécessite 30 minutes pour s'exécuter sur un Intel Core i7-5500 CPU." Sur un appareil Android, il faudrait plus d'une journée. En clair, il y a des manières plus simples de s'attaquer à un smartphone ou une tablette Android.
De plus, beaucoup, sinon la plupart, des noyaux Linux ont SMEP (Supervisor Mode Execution Protection) et/ou SMAP (Supervisor mode access prevention) activés. Si ces deux mesures de sécurité peuvent être contournées, elles ajoutent une couche de complexité à l'exploitation réussie de la faille.
Pourtant, le problème a besoin d'une solution. Le patch est déjà disponible sous forme de code source. La plupart des distributions Linux ont déjà mis à disposition le patch. Une exception : Red Hat (le 20 janvier).
Une solution qui ne fonctionnera pas, c'est d'utiliser la commande suivante :
# echo 1 > /proc/sys/kernel/keys/maxkeys
Cela ne fonctionne que pour les clés créées par l'utilisateur et non les clés root. Ce n'est donc pas un remède.
A la place, selon votre distribution, vous devriez lancer les commandes suivantes depuis le shell :
Debian/Mint/Ubuntu
$ sudo apt-get update && sudo apt-get upgrade && sudo apt-get dist-upgrade
$ sudo reboot
Fedora/CentOS/RHEL (une fois disponible)
$ sudo yum update $ reboot
openSUSE ou SLES
En tant qu'utilisateur root :
# zypper patch # reboot
Même si vous devriez le faire dès que possible, n'angoissez pas trop. Ceci est un exploit où il y a eu beaucoup de bruit pour presque rien.
Réagissez à l'article
-
oui donc une faille complètement mineure voir inexistante au final, puis n'importe quelle machine à des faille quand on a un accès physique donc c'est un peu stupide de parler de vulnérabilité à ce niveau là (mais il ne faut pas pour autant en renier l'existance)
takethispie
Répondre
-
On pourra aussi encourager l'utilisation des nouvelles commandes apt full-upgrade à la place de apt-get dist-upgrade, à partir de la debian 8, avec une nouvelle présentation de la mise à jour sous forme d'une barre de progression (beaucoup plus sympa).
Hansi
Répondre
-
HAAA OUAAAAIS !!!! J'adore la mauvaise foi et la partialité. Les failles de sécurité sous linux n'en sont pas ! xd ptdr mdr et lol.
décepticon
Répondre
-
Une faille est une faille. Tout système en possède. Linux n'échappe pas à cette dure réalité de l'informatique.
tintouin
Répondre
-
moi, je comprends bien, tous les commentaires et je suis majoritairement d'accord...
Helios
Répondre
-
@hansi son propos:
louplyonnais
Répondre
apt-get dist-upgrade -> ça fait trop peur à certain sysadmin pourris donc y aura toujours des systèmes sensible face à cette pseudo-vulnérabilité mais heureusement ce n'est qu'une minorité xD
Quoi qu'il en soit, la règle reste la même : un OS à jour, c'est des problèmes en moins. Et que ce soit pour la Ubuntu Mate LTS ou la Debian stable, force est de constater que sous GNU/Linux, les mises à jour ne plantent pas la bécane (sauf évidemment si on arrête violemment la machine en cours d'installation - mais là, le véritable bug est bien entre la chaise et le clavier !).
-
T'as lu quelqu'un dire ça ? Pas moi. J'ai lu une estimation de la criticité de la faille. Tu saisis la nuance ? Vu le ton et l'intérêt de ton commentaire on peut douter du fait que tu sois là pour ça.
cyrilou76
Répondre
La criticité d'une faille est estimée suivant des critères précis:
1) Le temps entre le patch et la PUBLICATION de la faille (ici 24h)
2) La faille est-elle exploitable à distance ? (ici c'est non, il faut un accès physique)
3) La faille nécessite t-elle des droits existants sur la machine à attaquer (ici il faut déjà un compte utilisateur sur la machine)
4) L'exploit de la faille est-il rapide et furtif ? (ici il faut monopoliser le CPU de façon intensive c'est à dire 24h sur un tél android et plus de 8Go de RAM).
5) La diffusion de l'exploitation de la faille (jusqu'à aujourd'hui elle est nulle).
Ca ce sont les faits qui font que cette faille ne représente pas de danger pour un admin système Linux. D'ailleurs, le patch est déjà appliqué sur les machines et aucun témoignage de son utilisation n'a été pour l'instant rapporté (et je suis prêt à parier qu'on en aura jamais). Quand vous verrez un témoignage de son exploitation à des fins malveillantes, vous pourrez me dire que je me suis trompé.
Bonne journée à vous.
-
cet article liste aussi les distribs vulnérables, à savoir :
shooby
Répondre
- CentOS Linux 7
- Debian Linux stable 8.x (jessie)
- Debian Linux testing 9.x (stretch)
- Fedora 21 et suivantes
- Scientific Linux 7
- openSUSE Linux LEAP 42.x et version 13.x
- Oracle Linux 7
- Red Hat Enterprise Linux (RHEL) 7
- SUSE Linux Enterprise Desktop 12
- SUSE Linux Enterprise Server (SLES) 12
- Ubuntu Linux 14.04 LTS (Trusty Tahr)
- Ubuntu Linux 15.04 (Vivid Vervet)
- Ubuntu Linux 15.10 (Wily Werewolf)
Mais de ça, tu ne préférera pas parlé, préférant l’échappatoire que tu nous sort là, qui passe dés lors pour une plaisanterie : en gros vous n'admettrez jamais que votre messie puisse être faillible ... même si cet article dit pourtant le contraire. Megalol
Mais quand je vois les solutions écrites en chinois a la fin de l'article, je comprends bien pourquoi Windows continue et continuera à dominer!
-
Y a pas besoin d'écrire en chinois. Sur toutes les distributions t'as un gestionnaire de mises à jour graphique. Il suffit de cliquer sur la notification de mise à jour et se laisser guider. C'est vrai que je vois pas trop l'intérêt de l'article sur cet aspect-là ...
arelate
Répondre
-
Pour Helios:
cyrilou76
Répondre
Si tu veux tu peux le faire à la souris (tu cliques sur le bouton "mettre à jour")
Chez moi j'ai un raccourci en ligne de commande et je tape juste: ajour
Toute ma machine (tous les programmes, absolument tous, seront mis à jour)
Sinon si tu aimes apprendre:
sudo
force est de constater que sous GNU/Linux, les mises à jour ne plantent pas la bécane (sauf évidemment si on arrête violemment la machine en cours d'installation - mais là, le véritable bug est bien entre la chaise et le clavier !).
Ah mais il faut pas aussi qu'il y ai une coupure de courant que dans ce cas n'importe quel OS est crashé.
J'admet que GNU/linux met a jour tout en bloc donc moins de risque que "antivirus redémarre suite a MAJ" tandis que W7 met a jour.
Si son OS est crashé; linux, on a de quoi sauvegarder, dépanner, réinstaller. windows, partir chez son SAV.
-
comme si sous windows les majs plantait la machine à 100% ds cas. Encore un phatasme de linuxien pour prétendre que leur messie, c'est la perfection incarnée (dans le même genre, cyrilou nous a bien fait croire que linux était capable de réfléchir par lui-même et de se réparer tout seul en cas de problème de hardware, c'est dire)
shooby
Répondre