Petite "info pratique" concernant l'origine du bug de connexion de Diablo 3, le "coupable" est un responsable sécurité de Canonical avec son module de sécurité batpisé [b]YAMA[/b] :
Après plus d'un an et demi d'hésitations et de débats, le module de sécurité YAMA a finalement été intégré dans le noyau Linux 3.4.
Cet ajout est une bonne occasion pour évoquer les controverses qui
persistent entre les développeurs au sujet de la sécurité de Linux. Il a
toujours été difficile de trouver un équilibre entre la sécurité à tout
prix, au détriment même de la propreté du code et de sa maintenabilité,
ou bien une approche plus pragmatique et mesurée.
Tout commence le 16 juin 2010 avec un mail de Kees Cook sur la liste de diffusion du noyau. Kees, qui était alors responsable sécurité chez Canonical, soutient que l'appel système ptrace est potentiellement dangereux et il propose un patch pour bloquer cette faille.
La commande ptrace est souvent utilisée pour les phases de
déboguage car elle permet à un processus d'éditer l'espace mémoire d'un
autre processus. D'après Kees Cook, un attaquant peut exploiter cette capacité afin d'élargir la surface d'attaque d'une compromission initiale :
Une faiblesse particulièrement troublante de l'interface des
processus sous Linux est qu'un simple utilisateur peut examiner le
statut et la mémoire de chacun de ses processus.
Par
exemple, si une application (par exemple Pidgin) est compromise, alors
il est possible pour un attaquant de s'attacher à un autre processus
(par exemple Firefox, une session SSH, un agent GPG, etc.) afin
d'extraire des informations sensibles additionnelles et continuer son
attaque.
Le patch de Kees est simple puisqu'il se contente d'ajouter un sysctl (une interface de paramétrage) contrôlant le comportement de ptrace. Ce nouveau paramètre, nommé ptrace_scope,
peut prendre les valeurs « 0 » ou « 1 ». Par défaut, c'est « 0 » qui
est utilisé (mode « classic ») et cela signifie que le comportement de ptrace ne change pas par rapport à la situation actuelle. En revanche, quand ptrace_scope est à « 1 » (mode « restricted »), alors un processus ne peut lancer ptrace que sur ses processus fils et toute tentative d'examiner la mémoire des autres processus échouera.
On notera que le travail de Kees Cook s'inspire largement d'une fonction qui existe déjà dans Grsecurity. L'option CONFIG_GRKERNSEC_HARDEN_PTRACE interdit en effet de lancer ptrace sur des processus arbitraires et limite le choix aux processus fils.
Il est cependant bon de noté que, avec la sortie du noyau 3.4, ce module est intégré au noyau et il faudra probablement prévoir de le désactivé pour tout OS utilisant le kernel 3.4 et supérieur.
Un [i]problème[/i] avec lequel il faudra composer a l'avenir pour les utilisateurs de wine.
EDIT : voila la source pour ceux qui veulent lire l'article complet : http://linuxfr.org/news/sortie-officielle-du-noyau-linux-3-4#toc_12
Edited by GNU_Raziel
