17 janv. 2011

Vérifications de permissions - suite

Introduction : les astuces de ce billet sont extraites du document Guide to the Secure Configuration of Red Hat Enterprise Linux 5 édité par la NSA. Vous pouvez télécharger le document au format PDF dans son intégralité sur leur site. Cette introduction me permet d'être en conformité avec leur notice de Copyright.

Après les droits des répertoires et le sticky bit, amusons-nous un peu avec SUID et SGID : un fichier possédant l'attribut SUID ou SGID permet d'être lancé avec les droits de l'utilisateur ou du groupe qui a été placé, généralement root. Ainsi, le programme at, permettant de lancer une tâche à un moment donné, est accessible aux utilisateurs classiques alors que son fonctionnement nécessite des droits plus élevés. Ceci peut s'avérer risqué car si un programme SUID root possède une faille, celle-ci peut être exploitée avec les droits de root, même si l'attaquant n'a pas les droits.

Comme pour le sticky bit, commençons par vérifier notre environnement :

root@orgrimmar:~# whoami
root
root@orgrimmar:~# cat /etc/redhat-release 
CentOS release 5.5 (Final)

Recherchons maintenant tous les fichiers possédant un SUID ou un SGID :

root@orgrimmar:~# find / \( -perm -4000 -o -perm -2000 \) -type f -print
/bin/ping6
/bin/umount
/bin/ping
/bin/mount
/bin/su
/lib64/dbus-1/dbus-daemon-launch-helper
/usr/bin/wall
/usr/bin/chfn
/usr/bin/newgrp
/usr/bin/sudoedit
/usr/bin/chsh
/usr/bin/write
/usr/bin/at
/usr/bin/chage
/usr/bin/crontab
/usr/bin/ssh-agent
/usr/bin/passwd
/usr/bin/sudo
/usr/bin/gpasswd
/usr/bin/locate
/usr/bin/screen
/usr/libexec/openssh/ssh-keysign
/usr/libexec/libvirt_proxy
/usr/libexec/utempter/utempter
/usr/kerberos/bin/ksu
/usr/sbin/userhelper
/usr/sbin/postqueue
/usr/sbin/postdrop
/usr/sbin/usernetctl
/usr/sbin/ccreds_validate
/sbin/netreport
/sbin/mount.nfs4
/sbin/umount.nfs4
/sbin/umount.nfs
/sbin/mount.nfs
/sbin/unix_chkpwd
/sbin/pam_timestamp_check
find: /proc/9859/task/9859/fd/4: Aucun fichier ou répertoire de ce type
find: /proc/9859/task/9859/fd/4: Aucun fichier ou répertoire de ce type
find: /proc/9859/fd/4: Aucun fichier ou répertoire de ce type
find: /proc/9859/fd/4: Aucun fichier ou répertoire de ce type
root@orgrimmar:~# 

Sur le coup, voir autant de lignes peut paraître effrayant, mais si on y regarde de plus près, on peut comprendre que 99% des fichiers indiqués aient besoin du SUID. Le seul qui m'inquiète, c'est screen. Je vais donc regarder sur une autre machine, bien différente cette fois-ci :

nils@tomb:~$ uname -sr
NetBSD 5.0.2
nils@tomb:~$ ls -hl /usr/pkg/bin/scree*
lrwxr-xr-x  1 root  wheel   12B Jul 11 11:23 /usr/pkg/bin/screen@ -> screen-4.0.3
-r-s--x--x  1 root  wheel  279K Jul 11 11:23 /usr/pkg/bin/screen-4.0.3*

On voit que screen sur ma machine NetBSD a aussi un bit SUID. C'est bon, je peux aller me coucher l'esprit tranquille :) Mais avant, revenons à notre serveur CentOS, et comme pour l'affaire du sticky bit, simulons un programme dont le SUID a été ajouté inutilement :

root@orgrimmar:~# cat > testbin
#!/bin/bash
echo -n "Je suis un programme SUID de test"
exit 0
root@orgrimmar:~# chmod -v +x testbin 
Le mode d'accès de `testbin' a été modifié à 0755 (rwxr-xr-x).
root@orgrimmar:~# ls -hl testbin 
-rwxr-xr-x 1 root root 63 déc 31 00:44 testbin*
root@orgrimmar:~# chmod -v +s testbin 
Le mode d'accès de `testbin' a été modifié à 6755 (rwsr-sr-x).
root@orgrimmar:~# ls -hl testbin 
-rwsr-sr-x 1 root root 63 déc 31 00:44 testbin*

Relançons notre recherche :

root@orgrimmar:~# find /root \( -perm -4000 -o -perm -2000 \) -type f -print
/root/testbin

Supprimons maintenant le SUID et relançons la recherche :

root@orgrimmar:~# chmod -v -s testbin 
Le mode d'accès de `testbin' a été modifié à 0755 (rwxr-xr-x).
root@orgrimmar:~# find /root \( -perm -4000 -o -perm -2000 \) -type f -print
root@orgrimmar:~# 

Et voilà, nous sommes tranquille :)

Que faire si j'ai un doute sur un programme ? Plusieurs possibilités : s'il s'agit d'un programme qui est fourni par les paquets de votre distribution, on peut toujours aller vérifier sur d'autres machines, dont l'OS ou la distribution peut différer (comme je l'ai fait avec screen); un même programme nécessitant le SUID sur 2 OS différents peut légèrement rassurer. Si le logiciel est libre (exemple : GNU screen :D), on peut aussi aller chercher dans les fichiers de création du paquet binaire, pour les RPM il suffit de chercher le SRPM du logiciel et de l'installer sur une machine de test. Ensuite, on regarde le contenu du fichier .spec qui sert à la création de ce paquet : en effet, ces fichiers contiennent la liste et les droits des fichiers et répertoires du paquet que l'on veut compiler :) Si un .spec n'indique pas que le programme est SUID, alors il est temps de s'inquiéter !

3 janv. 2011

Vérifications de permissions

Introduction : les astuces de ce billet sont extraites du document Guide to the Secure Configuration of Red Hat Enterprise Linux 5 édité par la NSA. Vous pouvez télécharger le document au format PDF dans son intégralité sur leur site. Cette introduction me permet d'être en conformité avec leur notice de Copyright.

Je vous propose de vérifier les permissions de certains de vos fichiers sur votre serveur ou poste fonctionnant sur un système Linux. Le but est de limiter les possibilités de tentatives d'intrusion en recherchant les moyens d'entrée possibles. Commençons par vérifier notre environnement :

root@orgrimmar:~# whoami
root
root@orgrimmar:~# cat /etc/redhat-release 
CentOS release 5.5 (Final)

Recherchons maintenant tous les répertoires dont les droits permettent à n'importe quel utilisateur d'écrire dedans, et dont le sticky bit n'est pas positionné :

root@orgrimmar:~# find / -type d \( -perm -0002 -a ! -perm -1000 \) -print

Si jamais votre machine possède de nombreuses partitions, et qu'elles sont du genre bien remplies, il est possible de limiter la recherche de find à une partition à la fois :

root@orgrimmar:~# find / -xdev -type d \( -perm -0002 -a ! -perm -1000 \) -print
root@orgrimmar:~# find /home -xdev -type d \( -perm -0002 -a ! -perm -1000 \) -print
root@orgrimmar:~# find /var -xdev -type d \( -perm -0002 -a ! -perm -1000 \) -print

Idéalement (et c'est le cas sur ma machine, ouf !), cette commande ne devrait occasionner aucun affichage. Maintenant, amusons-nous un peu :

root@orgrimmar:/tmp# mkdir insecure
root@orgrimmar:/tmp# chmod -v 777 insecure
Le mode d'accès de `insecure' a été modifié à 0777 (rwxrwxrwx).
root@orgrimmar:/tmp# find /tmp/ -type d \( -perm -0002 -a ! -perm -1000 \) -print
/tmp/insecure

Positionnons maintenant le sticky bit :

root@orgrimmar:/tmp# ls -hl /tmp/ | grep insecure
drwxrwxrwx 2 root root 4,0K déc 30 23:54 insecure/
root@orgrimmar:/tmp# chmod -v +t /tmp/insecure/
Le mode d'accès de `/tmp/insecure/' a été modifié à 1777 (rwxrwxrwt).
root@orgrimmar:/tmp# ls -hl /tmp/ | grep insecure
drwxrwxrwt 2 root root 4,0K déc 30 23:54 insecure/
root@orgrimmar:/tmp# find /tmp/ -type d \( -perm -0002 -a ! -perm -1000 \) -print
root@orgrimmar:/tmp# 

Qu'est-ce que le sticky bit ? Extrait de la page de manuel de chmod (man chmod) :

t (sticky-bit) conserver le code du programme sur le périphérique de swap après exécution. Il s’agit du comportement original, mais de nos jours il sert uniquement pour les répertoires. Il indique que seuls le propriétaire du répertoire, et le propriétaire d’un fichier qui s’y trouve ont le droit de supprimer ce fichier. C’est typiquement utilisé pour les répertoires comme /tmp ayant une autorisation d’écriture générale.

Vérifions cela :

root@orgrimmar:/tmp# cd /
root@orgrimmar:/# ls -hl | grep tmp
drwxrwxrwt   5 root root 4,0K déc 30 23:59 tmp/

Le sticky bit est positionné. Je suis rassuré. Néanmoins, il ne fait pas tout. Regardons donc quels répertoires sont accessibles à tous les utilisateurs, sans chercher à savoir si le sticky bit est positionné :

root@orgrimmar:/# find / -type d \( -perm -0002 \) -print
/var/tmp
/var/lib/xenstored
/dev/shm
/tmp
/tmp/insecure
/tmp/.ICE-unix

Cela fait déjà un peu plus de monde... pas très rassurant mais à part notre répertoire insecure, pas de quoi s'affoler : /var/tmp et /tmp sont des répertoires destinés aux fichiers temporaires des programmes en fonctionnement, /var/shm désigne la mémoire partagée et le xenstored sert au bon fonctionnement de l'hyperviseur Xen.

Pour finir, nous pouvons nettoyer notre petite expérience :

root@orgrimmar:/# rmdir -v /tmp/insecure/
rmdir: destruction du répertoire /tmp/insecure/
root@orgrimmar:/# ls -hal /tmp/ | grep secu

Propulsé par Dotclear