/proc/sysrq-trigger est un point d'entrée en écriture seule vers le gestionnaire magic-sysrq du noyau. Un seul caractère qui y est écrit exécute la commande sysrq correspondante contre le noyau de l'hôte : s synchronise les disques, e envoie SIGTERM à tous les processus sauf init, i envoie SIGKILL à tous, f invoque le tueur de manque de mémoire, c fait planter le noyau, et b redémarre immédiatement sans démonter. Ces actions agissent sur l'hôte car sysrq est global, de sorte qu'un conteneur dont le procfs de l'hôte est monté en écriture peut atteindre des effets à l'échelle de l'hôte.
Confirmez l'accès et que sysrq est activé :
[ -w /proc/sysrq-trigger ] && echo writable
cat /proc/sys/kernel/sysrq # bitmask of allowed sysrq functions; 1 = all
Actions disponibles#
echo s > /proc/sysrq-trigger # sync all mounted filesystems
echo e > /proc/sysrq-trigger # SIGTERM to all user processes (mass kill)
echo i > /proc/sysrq-trigger # SIGKILL to all user processes
echo c > /proc/sysrq-trigger # crash the host (kernel panic)
echo b > /proc/sysrq-trigger # immediate reboot, no clean unmount
Notes d'exploitation#
- Il s'agit principalement d'une primitive de déni de service et de perturbation, et non d'une évasion par exécution de code directe : elle ne peut pas exécuter un programme de l'attaquant comme le peuvent core_pattern ou uevent_helper.
- Les actions de suppression massive (
e,i) peuvent être enchaînées : tuer un processus de l'hôte peut forcer un superviseur à le redémarrer d'une manière que l'attaquant influence, ou libérer un verrou dont l'attaquant a besoin, mais à soi seul cela ne fait que détruire la disponibilité. - Le masque de bits
sysrqdans/proc/sys/kernel/sysrqpeut restreindre les fonctions autorisées ;0désactive entièrement sysrq et met la technique en échec. - Y parvenir nécessite que le procfs de l'hôte soit monté en écriture, généralement un conteneur privilégié.