Ce matin, en lisant mes mails, je suis tombé sur le plus petit programme en "user-space" (espace d'exécution pour utilisateurs normaux pour ceux qui ne parlent pas le langage technico-technique) qui fait planter Windows (versions NT 4 et 2000).
L'idée m'est donc venu d'essayer de faire la même chose sous GNU/Linux, et je n'ai pas trouvé.
Alors et vous, avez-vous une idée ?
Voici le code pré-cité :
#include <stdio.h>
int main (void) {
while (1)
printf("\t\b\b\b ") ;
return EXIT_SUCCESS ;
}
Concours de plantage
29
oct.
2001
# Linux aussi
Posté par G. R. (site web personnel) . Évalué à 8.
De plus, c'est un bug dans la console (hum) par défaut de Windows NT, puisque si le programme est lancé dans une autre console, ça ne plante plus.
Sous linux, un
while(fork()) ;
devrait faire l'affaire non ?
ça ne fait pas directement planter la machine, mais elle est inutilisable et il ne reste plus qu'à redémarer sauvagement.
[^] # Re: Linux aussi
Posté par kadreg . Évalué à 10.
Quand on administre une machine ou ce genre de chose est possible (je pense notamment aux écoles ou, a chaque cours sur le fork, ca arrive :) ), on commence par mettre un ulimit pour limiter le nombre de process par utilisateur. Ensuite, garder dans un coin une console root bien nice permet généralement de rattrapper le coup, a grand coup de killall.
[^] # Re: Linux aussi
Posté par Anonyme . Évalué à 1.
[^] # Re: Linux aussi
Posté par gle . Évalué à 10.
2/ ulimit permet aussi de limiter la consommation de mémoire.
[^] # Re: Linux aussi
Posté par kadreg . Évalué à 4.
J'ai un doute sur le fonctionnement de linux. Il me semble que la mémoire s'alloue par page, et que le mémoire n'est pas réellement allouée tant qu'il n'y a pas eut d'accès en écriture. C'est vrai ou j'ai révé ?
[^] # Re: Linux aussi
Posté par Étienne . Évalué à 5.
C'est pourquoi il est recommandé de n'allouer de la mémoire que lorsqu'on en a besoin et seulement la quantité requise.
Donc cette boucle ne devrait pas faire grand chose de méchant, au bout d'un moment, malloc retournera quand même NULL mais je pense que, n'étant pas utilisée, reste de la mémoire pour les autres processus.
Etienne
PS: il me semble que ce sujet était abordé dans le livre de Christophe Blaise la programmaion système en C sous Linux (désolé pour la pub mais c'est un très bon livre)
[^] # Re: Linux aussi
Posté par Étienne . Évalué à 1.
abracadabra *-1*
[^] # Re: Linux aussi
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
[^] # Re: Linux aussi
Posté par Anonyme . Évalué à 1.
[^] # Re: Linux aussi
Posté par Jerome Demeyer . Évalué à 10.
exemple, en ayant vos utilisateurs font partie d'un groupe "users" et qques personnes dans le groupe "src" (compilations de source)
ca vous donne un fichier :
# /etc/security/limits.conf
# <domain> <type> <items> <value>
# ne deboggant pas les soft, on va éviter les coredumps pour tout le monde
* soft core 0
#j'ai 10 users en parallele, 1Go de RAM, donc pas plus de...
#on va dire 64MB sur 12 process par user (3 par connexion),
#sauf ceux qui compilent : 256MB sur un max de 32 :)
@staff hard rss 65536
@staff soft nproc 10
@staff hard nproc 20
@src hard rss 262144
@src soft nproc 16
@src hard nproc 32
#ce n'est pas un serveur de calcul, donc pas de process durant plus d'une heure (3600 secondes):
@staff hard cpu 3600
#les connections : 4 simultanée pour les users, 0 pour les daemons
@staff - maxlogins 4
@daemon - maxlogins 0
ftp - maxlogins 0
#EOF
Eet voilà... bon bien sûr ça se fignole, mais je vous laisse lire le man.
Sinon, il est possible de tuner ces limites directement dans le kernel comme le nombre de threads par user, limité à (d'après mes souvenirs) 256 en dur.
[^] # Re: Linux aussi
Posté par Manu (site web personnel) . Évalué à 1.
Parce que le noyau ne permet pas de gérer les ulimit par user (pas encore et pas en standard).
Je pense que c'est un mécanisme d'une distribution qui lui permet de gérer ça pour le lancement des daemon.
Me trompe-je ?
[^] # Re: Linux aussi
Posté par Jerome Demeyer . Évalué à 4.
C'est indépendant de la distribution. Sous linux, c'est PAM qui semble gérer ces limites.
Cette possibilité existe aussi sur d'autres unix, moi meme je l'ai découvert sur AIX.
Si vous avez vraiment envie/besoin de securiser votre serveur, je vous conseille cet excellent bouquin de G.Morani :
- C'est orienté RedHat, mais appliquable partout : http://www.linuxdoc.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edi(...)
- paragraphe su les limites en particulier : http://www.linuxdoc.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edi(...)
C'est dans ce bouquin que j'avais vu comment limiter le nombre de processes par user, et le nb de processes réservés à root, un peu comme des slots vides, directement dans le kernel :
"To increase the number of tasks allowed the maximum number of processes per user, you may need to edit the /usr/src/linux/include/linux/tasks.h file and change the following parameters. Edit the tasks.h file, vi +14 /usr/src/linux/include/linux/tasks.h and change the following parameters: NR_TASKS from 512 to 3072 and MIN_TASKS_LEFT_FOR_ROOT from 4 to 24"
[^] # Re: Linux aussi
Posté par Jean-Sébastien Samson . Évalué à 2.
[^] # Re: Linux aussi
Posté par Gilles Cuesta . Évalué à 7.
<CITATION>
ulimit [-SHacdfmstpnuv [limit]]
Ulimit provides control over the resources available to the shell and to processes started by it, on systems that allow such control.
The value of limit can be a number in the unit specified for the resource, or the value unlimited. The H and S options specify that
the hard or soft limit is set for the given resource. A hard limit cannot be increased once it is set; a soft limit may be increased
up to the value of the hard limit. If neither H nor S is specified, the command applies to the soft limit. If limit is omitted, the
current value of the soft limit of the resource is printed, unless the H option is given. When more than one resource is specified,
the limit name and unit is printed before the value. Other options are interpreted as follows:
-a all current limits are reported
-c the maximum size of core files created
-d the maximum size of a process's data segment
-f the maximum size of files created by the shell
-m the maximum resident set size
-s the maximum stack size
-t the maximum amount of cpu time in seconds
-p the pipe size in 512-byte blocks (this may not be set)
-n the maximum number of open file descriptors (most systems do not allow this value to be set, only displayed)
-u the maximum number of processes available to a single user
-v The maximum amount of virtual memory available to the shell
An argument of -- disables option checking for the rest of the arguments. If limit is given, it is the new value of the specified
resource (the -a option is display only). If no option is given, then -f is assumed. Values are in 1024-byte increments, except for
-t, which is in seconds, -p, which is in units of 512-byte blocks, and -n and -u, which are unscaled values. The return status is 0
unless an illegal option is encountered, a non-numeric argument other than unlimited is supplied as limit, or an error occurs while
setting a new limit.
</CITATION>
Comme quoi, grace a ulimit, on peut vraiment restreindre les possibilités des utilisateurs.
<PUB>
Pour peu qu'ils soient chrootés ... (voir schroot sur sourceforge)
</PUB>
[^] # Re: Linux aussi
Posté par Anonyme . Évalué à 0.
sursaturation de /tmp. Meme un reboot sauvage
ne rêgle pas le pb.
#include <stdio.h>
int main () {
unsigned long n;
char nz[1024], *n0="/tmp/.%ul";
while (1) {
sprintf (nz,n0,n); fclose(fopen(nz,"w+"));
}
en quelques secondes, plus un inode dispo dans /tmp. Merci qui?
[^] # Re: Linux aussi
Posté par wismerhill . Évalué à 1.
Et hop problème envolé.
[^] # Re: Linux aussi
Posté par bmc . Évalué à -1.
-1, mais ceci n'est pas un troll
[^] # Re: Linux aussi
Posté par Gaël Le Mignot . Évalué à 4.
while (42) { fork();malloc(420); }
Vu que la limite de mémoire s'applique par process, pour peu que la limite de process ne soit pas trop draconnienne, on peut ainsi bouffer toutes la mémoire dispo, swap comprise, ce qui fait bien un DoS. Par contre ça se rattrape à coup de SysRq, donc on est pas obliger de rebooter.
# Effectivement !
Posté par Sylvain Rampacek (site web personnel) . Évalué à 6.
Exécuter une fois le printf, ça passe...
Mais dès qu'on le fait plus qu'une fois, et ben un bel écran bleu arrive !
[^] # Re: Effectivement !
Posté par Anonyme . Évalué à 1.
# Ben ça s'ammeliore
Posté par Francois Revol (site web personnel) . Évalué à 0.
c:\>debug
-a
cli
jmp 100
-g
[^] # Re: Ben ça s'ammeliore
Posté par kadreg . Évalué à 2.
Dans ce cas, c'est pas un bug, c'est une fonctions.
Et puis le monsieur, il demande un progrtamme en userland. Sous 98, il n'y a pas de userland :)
[^] # Re: Ben ça s'ammeliore
Posté par gwenn cumunel (site web personnel) . Évalué à 2.
nan :
cli -> bloque les interruptions soft
jmp 100 -> retourne sur le cli
ça reboot pas, ça bloque juste le multi-tâche qui utilise une interruption soft (il me semble, quelqu'un peut confirmer ?)
sinon effectivement le concours ne peut pas se faire sous w98.
(-1 pasque un peu hors-sujet là :)
# (si vous n'avez rien d'autre a faire...)
Posté par niclone (site web personnel) . Évalué à -1.
#!/bin/bash
while ((1)); do
$0 &
done
# wait and see
Posté par cornofulgur . Évalué à 1.
| tee public_html/index.php \
| mailx -s "U LAMERZ" warlordz@ccc.nl
--
# strings /proc/kcore | grep CCC >> /var/log/warlords
# XP aussi ;-)
Posté par Alexis B. . Évalué à 5.
Sinon, un autre feu d'artifice pour Win2k (source BugTraq aussi, fin juillet 2001) :
- lancez une invite de commande
- ping une_ip
- pendant que ping affiche des données,
appuyez sur F7 puis Enter
- oh la belle bleue ;-)
Amusez-vous bien,
-- Alexis
[^] # Re: XP aussi ;-)
Posté par Rin Jin (site web personnel) . Évalué à 1.
[^] # Re: XP aussi ;-)
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 1.
# Désolé, mon code est plus petit :
Posté par Anonyme . Évalué à 1.
{
printf("\t\b\b ");
}
Pas besoin du while(1) !!!!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.