Mes camarades de NBS System ont repéré une faille de D.O.S sur Magento qui est en cour de traitement chez Varien et qui ne sera donc rendu publique que lorsqu’elle sera patchée. Nous allons ici nous intéresser à Os commerce et Memcached.

Faille OS-commerce

Pour ceux qui tournent encore en OS-commerce, Milworm reporte une méchante faille de sécurité sur le célèbre framework. L’auteur (Flyh4t) propose un exploit effectif sur les version 2.2 RC2a au moins. Il est probable que d’autres versions soient vulnérables. Ca date du 31/08 mais bon, vu la vitesse à laquelle se patch le parc Français quand il y a une vulnérabilité… (cf la vulnérabilité sur le DNS de Kaminsky ou on a encore 8% du parc en non patché). Plus d’info ici.

Faille Memcached

On continue en musique avec un bon gros trou de sécurité qui fait mal, sur Memcached. Alors là, c’est plus critique car nombreuses, très nombreuses, sont les plateformes qui utilisent Memcached, sur Magento comme ailleurs, ce système de cache est populaire.

Et pan le memcached :  http://www.securityfocus.com/bid/35989

C’est goutu, frais, long en bouche et fruité, mais non ce n’est pas un bourgogne, c’est memcached qui a un bon overflow… Wahouuu le pire du pire, l’overflow et pas qu’un seul. La faille date du 7/08 à l’origine mais elle a été mise en jour le 14/12 pour être beaucoup plus générique.

Ça ne touche cependant « officiellement » que les distribution Linux suivantes (à ce jour) : les suze, redhat, parus, mandrake et danga. En général, un overflow dans un code en C, ce n’est pas fondamentalement lié à la distribution mais plus au code que la distribution a compilé pour son usage. Cela signifie globalement que le code source de memcached est susceptible de contenir des overflows et donc qu’avoir son propre système au dessus pour protéger votre infrastructure, ca ne fera pas de mal.

Les personnes sérieuses en infogérance installent GRsec & Pax quand ils mettent des serveurs Linux en visibilité sur Internet, notamment parceque PHP contient pas mal d’overflow et que tout démon est susceptible d’en connaitre, comme une fois de plus le montre cette faille de Memcached.

Grsecurity, l’anti Overflow

Je ne serai donc trop vous recommander d’utiliser GRsec sur vos environnement de production puisque c’est la seule façon de se protéger à 99% contre les heap & stack overflow, off by one et autres « boundary check errors ».

Rappelons que quelqu’un qui réussit une attaque par overflow va prendre le contrôle de la zone d’exécution  du programme ainsi que ses droits pour ouvrir un shell à distance. Une fois cela fait, même si le démon tournait en www-user ou avec un autre utilisateur non privilégié, l’escalade vers le compte root prend 90% du temps moins de 5 minutes. Les overflows sont donc l’une des plus grande menace possible sur un système si ce n’est la plus grande puisqu’ils mènent quasi tout le temps à une compromission totale du serveur.

Pour ceux qui découvrent GRsec : vous pouvez voir un (très) vieux howto que j’avais écris il y a 5 ans ici mais qui vous expliquera déjà au moins la base. Sinon le site de Grsecurity.net vous donnera de l’info aussi.

Sincèrement, exposer un serveur linux sur le net sans le protéger contre les overflows c’est un peu comme aller se faire une partie échangiste « thaïlando-congolaise » sans capote, disons qu’il existe un risque…