Comment planter NT et W2K avec 5 malheureuses lignes de code ?

Posté par  . Modéré par Pascal Terjan.
Étiquettes :
0
20
mar.
2002
Humour
Grace à ces quelques petites lignes de code parfaitement valides (une boucle avec un affichage de texte à l'ecran), NT et W2000 donnent leur pleine mesure avec le fameux blue screen of death (BSOD pour les intimes, et ils sont nombreux).
Voici le code incriminé :
#include <stdio.h>
int main( void )
{
    for(;;)
    {
        printf( "Hung up\t\b\b\b\b\b\b" );
    }
    return 0;
}
Ce programme est tellement simple que planter un OS avec ça, c'est vraiment stupéfiant !

Aller plus loin

  • # vieux

    Posté par  (site web personnel) . Évalué à 10.

    C'et deja vieux cette news, plus de 6 mois.
    ca ne marche pas toujours mais ca fait rebooter la machine aussi.
    Pareil pour une fenetre cmd.exe avec dedans des actions réseaux (style un ping ) et un bourrinage de la touche F7

    bref ca montre que la segmentation memoire c'est toujours pas ca dans ce systeme

    • [^] # Re: vieux

      Posté par  . Évalué à 4.

      Ces bugs n'ont RIEN a voir avec la segmentation memoire.

      Ils font appel a une fonction en mode kernel, qui elle a un bug, d'ou le crash.

      • [^] # Re: vieux

        Posté par  . Évalué à 3.

        Laquelle ? Sur la lien de la dépêche ils prétendent que MS n'a ni confirmé ni posté de rapport de bug/rustine ou quoi que ce soit à ce sujet. Tu peux nous éclairer là-dessus ?

        Quelle fonction du noyau ça pourrait être ?
        À part write et exit il n'y a pas beaucoup d'appels noyau apparents (à part le fork/exec implicite au lancement du programme et les inits de bibliothèques). Je dis ça, je ne dis rien, je ne suis pas familier de l'environnement d'exécution NT.

        • [^] # Re: vieux

          Posté par  . Évalué à 3.

          Ben je suis pas sense parler des raisons et causes de trucs [non/pas encore] releases, donc je dirais simplement:
          - Entre l'appel a printf, et l'affichage des caracteres a l'ecran tu passes par plein de couches
          - Pour afficher un pixel a l'ecran, faut que tu passes par le kernel a un moment ou un autre
          - Quand certaines fonctions du kernel sont appelees par des fonctions jugees "sures", elles ne verifient pas les parametres et ecrivent ou on leur dit d'ecrire, car c'est a la fonction appelante de faire le boulot de verif(ca fait moins de boulot cote kernel).

          • [^] # Re: vieux

            Posté par  . Évalué à 10.

            Tiens, j'ai dit une grosse connerie(certains diront: comme d'hab).

            La fonction qui ecrit dans les choux, elle fait partie du sous-systeme Win32, vu que le kernel n'apprecie pas cette chose(en fait la partie verif est dans Win32, la fctn d'ecriture est dans Win32(celle qui crash) et l'AV est la aussi), il kill Win32, et comble de malchance, le kernel n'a rien a faire quand Win32 est kille, donc le kernel affiche un ecran bleu et s'arrete ou reboot selon la config qu'on a.

            Je me suis laisse emporter en voyant que le fichier etait dans les repertoires habituellement reserves au kernel, mais ce qui crashe ne tourne pas en mode kernel, simplement le kernel fait un BSOD car il n'a plus rien a faire(sans Win32, le kernel ne sert a rien)

            En gros le fautif c'est Win32, pas le kernel(j'esperes que le kernel me pardonnera cette diffamation involontaire).

            • [^] # Re: vieux

              Posté par  (site web personnel) . Évalué à 2.

              C'est quoi Win32 ? Un processus genre init ?

              • [^] # Re: vieux

                Posté par  . Évalué à 10.

                C'est un sous-systeme, une sorte de mini-OS, rien a voir avec init.

                Sous NT t'as les sous-systemes :
                - Win32
                - Posix
                - OS2

                par defaut.

                Win32 t'apporte l'API win32, les fenetres Windows, blabla...
                Posix t'apporte.... Posix :+)
                OS2 te permet de faire tourner les softs OS2(16bit only je crois)

                Une app tourne dans un et un seul sous-systeme, tu peux pas avoir une API Posix qui joue avec l'API Win32 par exemple.

                En gros, en theorie tu pourrais faire tourner un tas de systemes differents par dessus le kernel NT(que j'appelerais personnellement un micro-kernel hybride, car il en a certains traits, mais pas tous).

                • [^] # Re: vieux

                  Posté par  . Évalué à 6.

                  En fait windows 2000, c'est un peu comme le Hurd.

                  Il y a un microkernel, et des sous-systèmes qui tournent autour. Sauf que les sous-systèmes tournent dans un ring privilégié au lieu d'un ring user.

                  J'ai bon pBpG ?

                  • [^] # Re: vieux

                    Posté par  . Évalué à 3.

                    Je connais pas Hurd assez bien pour faire une comparaison, mais le truc principal selon moi qui fait que c'est pas un micro-kernel au sens puriste du terme est que dans winNT/2000/XP, les drivers tournent en mode privilegie, par contre les sous-systemes eux ne tournent pas en mode kernel.

                    Le process Win32 n'a pas ecrit n'importe ou dans la memoire et fait crasher l'OS, il s'est fait killer par le kernel car il a essaye d'ecrire n'importe ou, et apres le kernel qui continuait a tourner sans prob, s'est rendu compte que sans Win32, ben il n'y a plus rien de faisable --> reboot ou ecran bleu.

                    • [^] # Re: vieux

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

                      Si il ne peut rien faire sans Win32, pourquoi pouvoir le killer et ne pas plutot killer le processus qui l'utilise mal ?

                      • [^] # Re: vieux

                        Posté par  . Évalué à 1.

                        Parce que le kernel a aucune idee de qui a demande quoi a Win32, il sait juste que Win32 a fait une grosse connerie(acces illegal dans ce cas), ca dit pas si cette connerie etait tellement grosse qu'elle a corrompu des donnees vitales dans Win32 auquel cas il vaut mieux killer le process plutot que risquer d'avoir une perte ou corruption de donnees plus grave, et le kernel peut pas deviner non plus si le bug en question est du a l'application ou si c'est un bug interne a Win32.

                        En gros, la solution la plus sure pour eviter de foutre le merdier dans les donnees de l'utilisateur c'est de killer un process qui fait une grosse connerie, quel que soit le process.

                    • [^] # Re: vieux

                      Posté par  . Évalué à 4.

                      Donc, si je pige, le kernel est tjs debout, donc pourquoi il ne pourrait pas relancer un win32 après l'avoir killer ???

                      (ou alors, y a un truc que j'ai pas piger...).

                      <mode optimiste>
                      c'est tellement mieux d'avoir une discussion calme !-)
                      </mode optimiste>

                      • [^] # Re: vieux

                        Posté par  . Évalué à 0.

                        Ben j'imagines que c'est du au fait que nombre de choses initialisees au depart ne peuvent plus l'etre a ce moment, ou autres trucs du genre qui font qu'il n'est pas possible de revenir a un etat utilisable apres avoir kille Win32, mais ce n'est qu'une supposition, Dave Cutler sait ca surement mieux que moi :+)

                        Sinon, c'est vrai que ca serait tellement mieux si toutes les discussions etaient de ce type.

                  • [^] # Re: vieux

                    Posté par  . Évalué à 1.

                    "En fait windows 2000, c'est un peu comme le Hurd"

                    <troll>
                    Tu veux dire que windows 2000 peut pas gérer les partitions de plus de 2 GO, ou juste que ca su><0r ? ;)
                    </troll>

                    [jesors]

                • [^] # Re: vieux

                  Posté par  . Évalué à 0.

                  donc pour résumer dans ces trois sous-systèmes, c'est toujours le même qui merde.
                  Personne n'a songé à refaire propre win32 pour éviter les problèmes ?

                  Mais c'est quand même interessant ce que tu dis. (pour une fois)

                  J'aime bien savoir d'où viennent les écrans bleus.

                  • [^] # Re: vieux

                    Posté par  . Évalué à 2.

                    Win32 est de tres tres loin le plus utilise, le plus complexe et le plus gros, c'est pour ca qu'il y a plus de bugs la que dans les autres.

                    Notes que dans ce cas la ca vient de Win32, d'autres fois ca peut etre autre chose(bug driver, bug kernel,..).

                    Lire les ecrans bleus ca donne souvent pas mal d'infos sur la raison du crash.

                    • [^] # screenshot

                      Posté par  (site web personnel) . Évalué à 2.

                      D'ailleurs, est-ce qu'il y a moyen de faire des captures d'ecrans ou quelque chose d'approchant pour les BSOD,
                      parce que c'est long a recopier ^_^

                      • [^] # Re: screenshot

                        Posté par  . Évalué à 1.

                        Par defaut Win2k sauve le dump(ce que tu vois a l'ecran et d'autres infos).

                        Control Panel -> System -> Advanced -> Startup and recovery

          • [^] # Re: vieux

            Posté par  . Évalué à 5.

            >Ben je suis pas sense parler des raisons et >causes de trucs [non/pas encore] releases,

            Bon je veux pas etre méchant, je suppose que vous avez des trucs importants a faire chez crosoft, mais ce bug ca fait des tas de mois qu'il est connu et que microsoft est prevenu alors
            COMMENT CA SE FAIT QU'IL N'Y AIT TOUJOURS PAS DE PATCH BORDEL!

            Tu vas pas me dire que c'est si dur a patcher que ca prend plus de six mois a corriger, d'autant qu'entre temps microsoft a corrigé des bugs découvert après.

            Serieuxement y'a une raison particulière qui explique qu'un bug qui a plus de six mois n'a toujours pas de patch ?

            • [^] # Re: vieux

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

              Ce n'est peut-être tout bêtement pas prioritaire dans la liste des bugs à corriger ?

            • [^] # Re: vieux

              Posté par  . Évalué à 0.

              Chez MS on sort des patchs pour des problemes qualifies d'importants.

              Question: est-ce que ce bug est important ?

              - Il peut-etre declenche en remote ? Non
              - Il arrive frequemment ? Non, il faut le faire explicitement, 99.9999% des softs ne font pas ca.
              - Elevation de privilege en local ? Non
              ...

              Bref, ce bug est un petit DoS en local, pas tres utile car le coupable est trouve dans les 30 secondes et se fera empaler sur un pieu.

              Resultat: ca merite pas qu'on sorte un hotfix, ca veut pas dire qu'on ne le corrigera pas dans un SP ou SRP cependant.

              • [^] # Re: vieux

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

                Ca permettrait aussi de foutre le souk sur tout un réseau, un petit exe placé de le menu de démarrage (ou si on a le droit dans la base de registre). Ca doit etre joli

                • [^] # Re: vieux

                  Posté par  . Évalué à 1.

                  Comment tu veux mettre le souk sur un reseau ?
                  Pour ca faut le lancer sur la machine distante, et qu'il ouvre une console.
                  Si t'as pas les droits necessaires, tu peux te gratter pour faire ca. De meme, pour mettre un truc dans le menu demarrer, faut avoir les droits, tu peux le mettre dans ton propre menu demarrer a toi, mais ca t'avance pas beaucoup.

                  • [^] # Re: vieux

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

                    Certains réseaux sont géré par des porcs.

                    Celui de mon école est un bon exemple, il n'y a aucune sécurité, la plupart des disques sont en fat et quand il y a du ntfs, on n'a plus aucun droit d'écriture du tout. Sur certaines machines, il n'y a pas de mots de passe administrateurs, certaines tombent sans raison et quand on perd des données, on nous dit qu'il fallait le mettre sur le serveur ou tout le monde a accés en ecriture, et je ne fait pas trop confiance a cette méthode.

                    Chaque année, les profs doivent réinstaller les ordis mais ils nous engueulent parce que bien sûr, c'est de notre faute si tout le monde installe des jeux.

                    • [^] # Re: vieux

                      Posté par  . Évalué à 0.

                      Oui bon evidemment, dans ces cas la il reste plus qu'a prier :+)

                      Faudrait peut-etre leur acheter "administration pour les nuls", ca pourrait leur servir si ils arrivent a comprendre ce qui est ecrit dedans...

  • # Optimisons le code quand meme :-)

    Posté par  (site web personnel) . Évalué à 9.

    Bon on va faire un truc moins gros, on optimise :-)

    1 - for(;;) { } peut etre remplacé par while(1) c'est plus lisible

    2 - le return(0) n'etant jamais atteint... on peut l'oublier :-))

    3 - puis ca serait pas mal d'inclure <stdio.h> car un #include rien j'ai jamais vu moi

    Au final du code avec un warning (manque le return) ca donne :

    #include <stdio.h>

    int main()
    {
    while(1)
    printf("\t\b\b\b\b\b\b");

    }

    Il parait meme qu'on peut se passer du while(1)...

    --
    Edouard Gomez

    Savez vous plantez des Windows, a la modeeeee, a la modeeee... de chez noussssss ?

  • # encore plus simple pour planter Windows mais que les versions 9x

    Posté par  (site web personnel) . Évalué à 2.

    Pour les versions 9x de Windows (sous NT ca marche pas, heureusement)

    cliquez sur Démarrer / Executer
    puis entrez dans la boite de dialogue :

    c:\con\con

    et hop à tous les coups windows 9x affiche un bel écran bleu, reboot garantie :)
    c'est con, mais c'est comme ca ...

    (c'est pas une blague, ca fonctionne réellement, c'est connu depuis longtemps)

  • # Marche pas avec cygwin

    Posté par  . Évalué à 10.

    Sur le site, ils disent que ce bug est indépendant du compilo... mais n'ayant pas VC++, je l'ai compilé avec cygwin et ça plante pas !!!

    Certainement dans ce cas là, que l'appel fautif est géré par la dll cygwin et non plus par une bibliothèque système !

    • [^] # Re: Marche pas avec cygwin

      Posté par  . Évalué à 10.

      Petite question, as-tu compilé ton application avec cygwin en mode natif (donc avec l'option -mno-cygwin [1]) ? Si ce n'est pas le cas, c'est effectivement la DLL de cygwin qui aura géré cet appel fautif, donc plus d'erreur apparente.

      Il serait intéressant de refaire le test en compilant avec l'option que je mentionne ci-dessus. Malheureusement n'ayant pas installé cygwin sur ce poste, je ne peux pas faire ce test moi-même.

      [1] L'option -mno-cygwin indique au compilateur de cygwin d'utiliser les librairies de mingw pour les appels systèmes, en lieu et place des librairies de cygwin. Ainsi, on obtient des applications qui peuvent se passer de la DLL de cygwin, mais qui ne peuvent rien faire de plus que ce qui est mis à disposition par Win32.

      Zeiram

  • # Planter linux n'est pas non plus très dur...

    Posté par  . Évalué à 3.

    Laisser tourner le programme suivant pendant quelques secondes suffit:

    #include <stdio.h>
    #include <unistd.h>

    int main(){
    while(1) fork();
    }

    A l'epoque ou j'avais trouve ca, j'avais cherche une solution equivalente a ULIMIT pour le nombre de process qu'un utilisateur peut lancer pour eviter ce genre de gags. J'avais rien trouve, mais si quelqu'un a une idee...

  • # News déjà passé !

    Posté par  (site web personnel) . Évalué à 2.

    http://linuxfr.org/section/Code/5647,0,0,0,1.php3(...)

    "La première sécurité est la liberté"

Suivre le flux des commentaires

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