Architechture du noyau - kernel

On vient de découvrir une faille de sécurité dans le kernel 2.6.32-RC8 de linux , et qui s’avère très dangereuse . On peut provoquer des failles dans ip_dfrag() de  la pile de TCP/IPV4  (net/ipv4/ip_fragment.c), ce qui peut provoquer des dé-référencements du pointeur, et par la suite le système se plante.

Cette faille peut être exploité par des utilisateurs qui sont enregistré dans le même système et qui son moins privilégiés pour exécuté du code malicieux au niveau du noyau. pour résoudre le problème dans la version Linux 2.6.32-RC8 il suffit de passer à la version finale du kernel, ce qui est déjà fait par les distributions connus, mais cela n’empêche que la plupart des systèmes ne son pas encore mis à jour.

En même temps les distributions profitent de cette mise à jour pour intégrer la résolution du problème de gestion du système de fichiers Ext4, ce dernier a connu un bug qui se manifeste dans l’insuffisante de vérification des privilèges lors d’utilisation de la commande pvmove « move extents », un bug qui peut être exploité pour écraser des fichiers système arbitrairement ce qui peut paralyser le système ou encore changer les privilèges d’un utilisateur pour gagner les privilèges du « root ».

Le système de fichiers Ext4 est inclut par défaut dans quelques distributions (OpenSUSE 11.2, Ubuntu 9.10 (Karmic Koala), Fedora Core) ce qui les rend vulnérables. De nouveaux paquets d’installations pour résoudre le problème seront de plus en plus disponible.

L'éléphant symbole du langage PHP

Une faille découverte récemment permet de mettre le serveur en DOS (Denial Of Service) empêchant toute réponse à d’éventuelles requêtes, la faille consiste à envoyer des fichiers sur le serveur, en upload simultanément. Les différents systèmes ont agit chacun d’une manière différente, certains ne pouvaient lister le répertoire /tmp/php où ces fichiers étaient uploadés avant d’être déplacés dans le répertoire de destination, d’autres listaient le répertoire avec des millions de fichiers, mais ne répondaient pas à la requête. Le gagnant si j’ose dire est OpenBSD qui lui répond tout de même aux requêtes et sa charge CPU commençait à descendre après la fin de l’attaque, contrairement à Windows ou Ubuntu ou encore FreeBSD.

Les solutions possibles pour patcher le problème  :

Soit de changer le paramètre file_uploads = Off dans le fichier php.ini rendant tout upload impossible, si vous en avez pas besoin.

Soit de mettre à jour PHP vers 5.3.1 ou supérieure et là toujours dans le fichier php.ini un nouvel paramètre a été pris en charge celui de max_file_uploads = 20, qui est par défaut 20 même si le paramètre n’est pas présent dans le fichier de configuration.

Pour plus d’informations lisez ce petit rapport qui est accompagné de tests sur différents OS, et avec une petite analyse pour mieux comprendre ce qui se passe.