Parfois, on découvre une vulnérabilité sans la chercher. Et parfois, comme ici, c’est finalement une simple fausse alerte. Plus de 70 % des vulnérabilités que j’ai trouvées dans ma vie n’avaient rien à voir avec une recherche de sécurité : je suis simplement tombé dessus par hasard, en faisant de l’administration système par exemple.
Ce jour-là, pour un client dont le site reçoit des millions de hits à cause d’un jeu organisé pendant les vacances, je décide de mettre le contenu du site directement en mémoire afin de ne plus avoir de problème d’IOPS. Pour ça, j’utilise simplement un ramdisk et je synchronise chaque minute, avec rsync, le disque où se trouve le code vers ce ramdisk.
Ce client est dans un conteneur LXC avec 8 Go de RAM, relié à un serveur MySQL séparé par un réseau privé. Le serveur web utilise moins de 1 Go de RAM et les applications occupent moins de 500 Mo sur le disque.
Je crée donc simplement un ramdisk comme ceci :
mkdir /home/ramdisk
echo "shm /home/ramdisk tmpfs nodev,nosuid,noexec 0 0" >> /etc/fstab
mount /home/ramdisk
rsync -avz --stats --delete /home/xxxx /home/ramdisk/
Ensuite, je vérifie avec un simple df -h et là, grosse surprise :
~# df -h
Filesystem Size Used Avail Use% Mounted on
zfstore/zfs-containers/subvol-9202234-disk-1 32G 1.4G 31G 5% /
none 492K 0 492K 0% /dev
tmpfs 26G 68K 26G 1% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 1.7G 0 1.7G 0% /run/shm
shm 126G 410M 126G 1% /home/ramdisk
Mon /home/ramdisk affiche une taille de 126 Go. Je vérifie aussitôt, avec et sans le ramdisk, si ça consomme de la RAM, mais son utilisation reste exactement la même. Très enthousiaste à l’idée d’avoir probablement trouvé une nouvelle vulnérabilité, je fais le test dans un nouveau conteneur, sur un autre cluster, et je reproduis le problème. En parallèle, j’envoie un email à une personne que je connais et qui travaille sur une implémentation de ce produit. Finalement, c’est simplement un problème d’affichage : les conteneurs privilégiés échouent uniquement à *afficher* la mémoire utilisée. C’est un problème de comptabilisation. Une fois les limites fixées atteintes, les écritures passent dans le swap, puis l’OOM killer du noyau tue le conteneur avant qu’il ne commence à utiliser plus de RAM que ce qui lui a été attribué. Il faut bien que les deux limites, RAM et swap, soient atteintes. Fin de l’histoire :)
Christophe Casalegno
Vous pouvez me suivre sur : Twitter | Facebook | Linkedin | Telegram | Youtube
Laisser un commentaire
Ajouter un commentaire