Article qui contient pas mal d'infos sur la faille :
http://arstechnica.com/security/2014/05/linux-gets-fix-for-code-execution-flaw-that-went-unpatched-since-2009/
Le correctif dans la future version Linux 3.15 :
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4291086b1f081b869c6d79e5b7441633dc3ace00
Il s'agit un vieux bug dans le code qui gère les terminaux (TTY).
Reprise de l'article Arstechnica sur LWN :
http://lwn.net/Articles/598372/#Comments
Une mise à jour est disponible pour Debian et Ubuntu. Red Hat Enterprise Linux 5 n'est pas vulnerable. Un correctifs pour Red Hat > 5 et Debian est en préparation.
J'ai testé deux exploits sur Fedora 20. L'un n'a rien fait (mais un commentaire dans le code dit qu'il peut corrompre la mémoire du noyau). Le second a freezé mon ordinateur. Un exploit plus stable pourrait être développé plus tard (toujours selon les commentaires des exploits). Bref, il est temps d'upgrader !
Un bug dans le code de TTY, ça me rappelle différentes critiques du code : le code est vieux et n'est plus trop maintenu.
http://lwn.net/Articles/343828/
TTY est une des dernières parties du code qui avait encore le "Big Kernel Lock" :
Alan, you are a true wizard :-) The tty layer is one of the very few pieces of kernel code that scares the hell out of me :-) -- Ingo Molnar, July, 2007
- https://linuxfr.org/news/nouvelle-version-2634-du-noyau-linux#pour_la_suite ("Big Kernel Lock")
- https://linuxfr.org/news/le-noyau-linux-2636-est-disponible ("Un noyau sans BKL ?")
- http://kernelnewbies.org/BigKernelLock (allez voir le joli schéma "TTY layer")
- http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/char/tty_mutex.c?id=b07471fa51358ce64cc25e1501544502362e4404 (Arnd Bergmann: tty: implement BTM as mutex instead of BKL)
Ou encore :
https://linuxfr.org/users/finss/journaux/alan-cox-jette-l%C3%A9ponge
"Suite à une embrouille avec Linus, Alan Cox a décidé de stopper sa participation au développement de tty et donc aussi au noyau de linux."
# Hardened !
Posté par Damien Thébault . Évalué à 6.
Chez moi le proof-of-concept ne fonctionne pas:
C'est efficace les kernel hardened avec PaX+Grsec :)
[^] # Re: Hardened !
Posté par claudex . Évalué à 6.
Ça ne veut rien dire, ce sont des PoC, qui ne sont donc pas étudiée pour s'adapter à toutes les situations mais juste pou montrer que la faille est exploitable. Peut-être qu'effectivement ces patchs protègent de la faille mais peut-être qu'elle est exploitable avec un contournement dans le patch.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Hardened !
Posté par Victor STINNER (site web personnel) . Évalué à 6.
Un Tweet semble confirmer que GRsecurity protège de cette vulnérabilité :
"No fewer than four grsec features (UDEREF/KERNEXEC/RANDSTRUCT/HIDESYM) prevent this exploit for the pty vuln: No fewer than four grsec features (UDEREF/KERNEXEC/RANDSTRUCT/HIDESYM) prevent this exploit for the pty vuln: http://bugfuzz.com/stuff/cve-2014-0196-md.c"
https://twitter.com/grsecurity/status/465815357299896321
[^] # Re: Hardened !
Posté par reno . Évalué à 2.
Hum, le tweet dit, empêche l'exploit de cette vulnérabilité.
Tout les exploits ou celui là en particulier?
Là est la question..
[^] # Re: Hardened !
Posté par JGO . Évalué à 5.
Les noyaux grsec sont vulnérables, mais le patch corrigeant la faille a été intégré plus tôt (il y une semaine ; nécessairement plus tôt vu que mainline n'est pas encore patché ; source : commentaires sur lwn).
[^] # Re: Hardened !
Posté par pepp . Évalué à 3.
Les commentaires LWN indiquent certes que les patchs ont été mergé il y a une semaine, mais aussi que cet exploit (la version publiée en tout cas) ne fonctionnait pas sur un noyau grsecurity.
cf :
et la réponse :
# Le bug chez Red Hat
Posté par Nils Ratusznik (site web personnel, Mastodon) . Évalué à 2.
Pour les intéressés : https://bugzilla.redhat.com/show_bug.cgi?id=1094232
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.