Le blog de Xarli

La version pour le noyau Linux 2.6.7 de GrSecurity [EN] est enfin sorti (et en place chez moi depuis quelques minutes soit dit en passant). De plus, le développeur s'est bien remis de ses déboires financiers, et le site Web officiel a adopté un style très business, très pro, je pense que celà peut donner de la crédibilité au projet (qui l'est déjà très quant au professionnalisme du code et aux fonctionnalités proposées), s'il en avait besoin. A suivre, bien sûr, et à installer en production, ne serait-ce que pour les fonctionnalité d'amélioration de l'entropie de la couche TCP/IP et pour le durcissement de l'obtention d'informations système (processus, modules noyau, informations relatives à la couche réseau, audit des évènement divers, durcissement des prisons de type chroot, etc...). Je vous invite à vous référer à mes billets précédant sur GrSecurity pour plus d'info, grâce à la petite boîte recherche de ce blog.

Si si, c'est dans cette alerte de sécurité [EN] de l'US-CERT. A noter que tous les logiciels se basant sur les bibliothèques d'Internet Explorer sont bien entendu affectés (OutLook, OutLook Express, les surcouches IE, ...). Une bonne occasion de plus de migrer vers FireFox [EN].

Source : DLFP [FR].

Suite à mon billet d'hier sur la sécurisation de mon noyau, je me suis dit qu'expliquer un peu ce qu'est GrSecurity (GrSec pour les intimes) ne serait pas forcément néfaste pour les lecteurs se demandant ce que c'est. C'est un patch permettant d'augmenter la sécurité d'un noyau Linux de manière significative. Et pourquoi en aurait-on besoin, les systèmes GNU/Linux ne sont-ils pas déjà sécurisés? Oui, ils le sont, mais de base un utilisateur non privilégié mais possédant un compte sur une machine peut accumuler une certaine somme d'informations pouvant aider à compromettre ce système. Ce patch permet donc de rendre plus difficile cette récolte d'informations, effectuée par un éventuel pirate cherchant la compromission de votre machine (ainsi, il ne pourra pas obtenir la liste des processus de votre machine, les adresses IP et interfaces de votre machine, etc...). L'ensemble de possibilités offertes par celui-ci est loin d'être négligeable, donc il serait dommage de s'en priver, surtout sur une machine faisant office de serveur ou sur laquelle différentes personnes sont potentiellement amenées à s'y connecter, ou bien en ont au moins la possibilité. Mais il n'y a pas que des restrictions pour l'obtention d'informations, il y a aussi des correctifs divers, tels l'amélioration de l'entropie lors du choix des ports TCP sources (cf faille récente dans le protocole TCP, rendue plus difficile par cette rustine), la modification du protocole ICMP pour rendre plus ardue la détection des systèmes d'exploitation selon leur couche TCP/IP, une protection accrue des espaces d'adressage, une possibilité de logguer différents évènements systèmes (exécution d'une application, création d'un répertoire, ...), la gestion d'ACL système, ou encore sécurisation des prisons systèmes (chroot). Une fois le noyau compilé, on peut modifier les différents comportements via sysctl, ou le système de fichier /proc.

Vous trouverez plus d'information sur l'application du patch et sa configuration dans cet excellent article [FR] (un peu de Google Bombing ne fait pas de mal ).

Pour récupérer automatiquement le patch GrSecurity Debian [EN] (la récente version 2 est vieille de seulement 10 jours à l'heure où j'écris ce billet) et l'outil associé de gestion des listes d'accès (gradm [EN]), si vous disposez d'une Debian et que vous êtes disposé à recompiler Linux, et que vous utilisiez un noyau 2.4 ou 2.6 vous pouvez utiliser :

14:42 xarli@iguzki ~% sudo apt-get install kernel-patch-grsecurity2 gradm

Les sources se trouvent alors sous forme d'archives pour les différents noyaux concernés dans /usr/src/kernel-patches

Site officiel de GrSec [EN]

Site officiel de Pax [EN], composant inclu dans GrSec

Autres rustines de sécurité pour le noyau Linux [EN], issues du projet OpenWall et utiles si vous avez un noyau non concerné par GrSec (2.0 ou 2.2 par exemple).

<pub>Mon mémoire de fin d'étude sur la sécurisation des systèmes GNU/Linux [FR]</pub>

Gulp... Le protocole TCP [EN] est l'un des fondements des réseaux actuels. Datant de queqlues dizaines d'années maintenant, il est robuste et sert de base à la plupart des communications numériques.

Une alerte de sécurité [EN] vient de paraitre. Ca fait froid dans le dos, cela permet de créer un DOS [FR] sur des sessions TCP, et la possibilité d'injecter des données arbitraires dans une connexion TCP n'est pas exclue. Les principaux protocoles applicatifs concernés sont le BGP, et dans une moindre mesure DNS et SSL.

La faille vient de la possibilité de forger des packets TCP de fin de connexion (SYN+RST), possibilité connue depuis très longtemps, mais rendu très ardue par les numéros de séquence TCP, donnant une chance sur 2 à la puissance 32 de trouver le bon numéro. Mais le fait que la machine de destination d'un paquet attende non pas un numéro précis mais un numéro compris entre deux limites augmente considérablement les chance de trouver un numéro acceptable par la machine de destination.

Pourquoi cette faille d'implémentation? Parce que quand TCP a été pensé, les réseaux n'avaient pas de gros besoins sécuritaires.

Toutefois, il faut relativiser, les conditions à remplir sont nombreuses pour pouvoir utiliser cette vulnérabilité pour une attaque. Mais les connexion TCP persistantes sont potentiellement fortement vulnérables, et si BGP tombe sur tous les routeurs de bordure de votre FAI par exemple, vous perdez Internet.

De plus, une faille locale de sécurité permettant d'obtenir des droits super utilisateur par une excalade des privilège vient d'être publiée sur le noyau Linux. Plus de détail sur DLFP [FR]. Solution : passer en 2.4.26 ou en 2.6.5 dans la mesure du possible, ils ne sont pas affectés. Du coup, les machines Debian sont partiellement inaccessibles, le temps de patcher les noyaux (chat échaudé craint l'eau froide?).

Soirée de merde, je vous le dis.

Le ver Slammer (aussi appellé Sapphire) a commencé à se répandre le 25 janvier 2003. Il a causé énormément de dégats, et est même le virus le plus efficace jamais créé à ce jour (mais gageons que d'aucuns arriverons à le surpasser, malheureusement). Voici un article [EN] très intéressant sur son mode de diffusion et comment une telle chose a pu se produire, juste par l'inconscience des administrateurs systèmes possesseurs d'un serveur Windows équipé de SQL Server et non protégé. Son mode de propagation en mode non connecté (par UDP) lui a permis de toucher des machines non-firewallée et non routable par exemple, ce qui justifie le petit bout de méthodologie que je donne <réclame>dans mon document sur la sécurité des systèmes Gnu/Linux, en étudiant vraiment tous les risques relatifs à un service bien particulier</réclame>.