Articles précédents : Code
- [13] Darwin OS disponible sur Intel x86
- [103] Un autre compilateur Java générant du code natif x86
- [89] Un script pour récupérer son XP
- [5] Un script pour detecter un scan de Nimda
- [18] Loki annonce un concours "Jeu SDL" !
- [6] Nouvelle release de GnomeMeeting
- [23] Sondage de Sony : Linux sur PS2
- [10] Art et Python
- [4] Le Defi'Con version 2.0 !
- [15] Développement driver Linux pour modem ECI USB
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 ;
}
> Lire la dépêche (29 commentaires, moyenne: 3,5).
Linux aussi
Ce programme ne plante pas sous Windows 98.
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 () le 29/10/2001 à 09:14. (lien). Évalué à 13.ça ne fait pas directement planter la machine, mais elle est inutilisable et il ne reste plus qu'à redémarer sauvagement.
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 () le 29/10/2001 à 09:36. (lien). Évalué à 1.Et contre le while(malloc(42)); tu fais quoi ? :p
-
[^]Re: Linux aussi
Posté par gle () le 29/10/2001 à 09:48. (lien). Évalué à 10.1/ while(malloc(42)) s'arrêtera de lui-même quand malloc retournera NULL.
2/ ulimit permet aussi de limiter la consommation de mémoire.-
[^]Re: Linux aussi
Posté par kadreg () le 29/10/2001 à 10:24. (lien). Évalué à 4.1/ while(malloc(42)) s'arrêtera de lui-même quand malloc retournera NULL.
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 Etienne () le 29/10/2001 à 12:37. (lien). Évalué à 5.En fait, tu peux allouer beaucoup plus de mémoire que tu n'en a (swap comprise) si tu ne l'utilise pas tout de suite, comme dans ce cas là.
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
-
-
-
[^]Re: Linux aussi
Posté par Benoît Sibaud (Jabber id, page perso, ) le 29/10/2001 à 10:27. (lien). Évalué à 5.Ceci dit, il faut aussi contrôler les sémaphores (semget, cf ipcs), la mémoire partagée (shmget, cf ipcs), les ports ouverts (tu peux ouvrir tous ceux au-dessus de 1024 si ça t'amuse), les inodes des systèmes de fichiers, l'espace disque des systèmes de fichier, le nombre de sockets... (en gros éviter de saturer les tables de taille fixe du noyau ou du système)
-
[^]Re: Linux aussi
-
-
[^]Re: Linux aussi
Posté par Jerome Demeyer () le 29/10/2001 à 12:12. (lien). Évalué à 16.contre les "trucalacon" genre while(fork()) ou while(malloc(42)) et contre toute autre pollution des ressources du systeme, il éxiste un fichier de limites soft et hard qui permet d'eviter toute saturation : /etc/security/limits.conf
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 (page perso, ) le 29/10/2001 à 12:24. (lien). Évalué à 1.C'est sur quelle distribution ?
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 () le 29/10/2001 à 13:28. (lien). Évalué à 4.>C'est sur quelle distribution ?
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 () le 29/10/2001 à 09:15. (lien). Évalué à 2.Tu peux limiter le nombre de process pour les users (avec ulimit) et donc ça ne fait pas forcément planter linux.
-
[^]Re: Linux aussi
Posté par Gilles Cuesta () le 29/10/2001 à 10:27. (lien). Évalué à 7.Dans man bash, on trouve:
<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 () le 29/10/2001 à 12:29. (lien). Évalué à 0.Alors en voila un qui est pas prévu par ulimit :
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 (page perso, ) le 30/10/2001 à 14:40. (lien). Évalué à 1.Sous mandrake (>=8.0) (je sais pas pour les autres mais tu peut toujours le faire à la main) tu peut la configurer pour vider automatiquement /tmp au démarrage.
Et hop problème envolé.
-
-
-
-
[^]Re: Linux aussi
Posté par Gaël Le Mignot (page perso, ) le 29/10/2001 à 14:22. (lien). Évalué à 4.Pour que ça marche, il faut combiner les deux:
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 !
Oui, je confirme, ça plante bien sous win2k pro sans aucun "service pack" d'installé !
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 !
Ben ça s'ammeliore
Oui, sous win98 3 octets suffisent:
c:\>debug
-a
cli
jmp 100
-g
-
[^]Re: Ben ça s'ammeliore
Posté par kadreg () le 29/10/2001 à 11:10. (lien). Évalué à 2.Je suis pris d'un gros doute (encore un). C'est pas l'appel à reboot () qui se fait comme ça normalement ?
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 (page perso, ) le 29/10/2001 à 14:11. (lien). Évalué à 2.C'est pas l'appel à reboot () qui se fait comme ça normalement ?
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...)
sans ulimit, ca peut faire mal:
#!/bin/bash
while ((1)); do
$0 &
done
wait and see
$ echo "< tt ><? print system($crackme) ?>< /tt >" \
| tee public_html/index.php \
| mailx -s "U LAMERZ" warlordz@ccc.nl
--
# strings /proc/kcore | grep CCC >> /var/log/warlords
XP aussi ;-)
Petit bonus de ce matin (source BugTraq), ça marche aussi sur Windows XP ;-)
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 (page perso, ) le 29/10/2001 à 19:55. (lien). Évalué à 1.sinon y'a toujours le classique c:\con\con
--
"On obtient plus de chose en étant poli et armé qu'en étant juste poli" Al Capone
-
[^]Re: XP aussi ;-)
Posté par Fabien Penso (Jabber id, page perso, ) le 30/01/2002 à 10:37. (lien). Évalué à 1.Pas mal du tout, je viens de tester sur le windows de mon collegue, bah ça marche :) (enfin ça plante quoi).
Cette page a été générée par Templeet en 0.1048s (dont 0.0101 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.