Une version de Windows s'est-elle déjà comportée de cette façon?

36

Inspiré de l'article DailyWTF d' aujourd'hui .

L'auteur affirme qu'un fichier C:\Program.exeserait exécuté en cliquant sur un raccourci vers, par exemple C:\Program Files\Doom 2\doom2.exe -nomusic,.

Soi-disant, Windows tente d'abord d'appeler C:\Programavec les arguments Files\Doom 2/doom2.exe -nomusic.

S'il n'y en a pas C:\Program.exe, il essaie ensuite C:\Program Files\Doomavec les arguments 2/doom2.exe -nomusic.

Et s’il n’y en a pas C:\Program Files\Doom.exe\, il essaie finalement C:\Program Files\Doom 2\doom2.exe -nomusicet réussit.

Cela ressemble à un non-sens pour moi. Je ne peux pas croire que cela a déjà fonctionné de cette façon. Un commentateur le dit bien :

J'ai du mal à croire que n'importe quelle version publiée de Windows ait jamais appliqué l'approche essais et erreurs décrite par OP.

Je suis absolument convaincu qu'une version publiée de Windows avait par défaut un comportement mortel. J'en ai fait l'expérience maintes fois.

Ce que je ne crois pas, c'est qu'une version publiée de Windows avait ce comportement de mort cérébrale, comme décrit dans l'article. C'est une faille de sécurité trop importante pour être passée inaperçue jusqu'à ce qu'une soumission aléatoire du WTF le découvre, au moins une décennie plus tard, car il aurait fallu que ce soit une version de Windows antérieure à XP.

Modifier pour plus de clarté: Voici comment j'ai moi-même testé cela.

  1. Copier notepad.exe dans C: \ program.exe
  2. Exécutez C: \ program files \ Internet Explorer \ iexplore.exe
  3. Le bloc-notes s'ouvre. Ceci est attendu car il trouve quelque chose appelé C: \ programme
  4. Déplacez progam.exe dans C: \ program files \ Internet.exe
  5. Exécutez C: \ program files \ Internet Explorer \ iexplore.exe

Selon l'auteur de l'article ( et cet article de Microsoft ), le bloc-notes devrait toujours être ouvert. Mais ce n'est pas le cas, la commande échoue avec ce message:

C:\program is not recognized as an internal or external command, operable program or batch file.

Encore une fois, je ne discute pas l'affirmation de l'article selon laquelle le programme C: \ serait invoqué. Je suis en train de débattre du fait que Windows essaie de manière récursive tous les répertoires jusqu'à ce qu'ils correspondent.

Alors, est-ce qu'une version de Windows a déjà fonctionné de cette façon?

dépêche
la source
1
Oui ! Voir la réponse de @ grawity ici: superuser.com/a/373756/100787
iglvzx
2
Vous devriez avoir vérifié tous les commentaires;) msdn.microsoft.com/en-us/library/windows/desktop/…
Baarn
Il semble qu'il y ait deux (ou plus) questions distinctes ici: Windows vous permettrait-il de créer un raccourci vers C:\Program Files\..., et Windows interprétera-t-il un tel raccourci (ou une commande Exécuter, ou une commande d'invite de commande, ou une autre méthode) "C:\Program" Files\...? La première partie semble improbable, mais la seconde me semble probable et attendue.
mwfearnley
Une troisième question, je suppose, est la suivante: une méthode d’exécution de commande de Windows donnée interpréterait-elle C:\Program Filescomme "C:\Program Files"? Après un peu de lecture, il semble que la réponse dans certains cas puisse être "oui", ce qui est le seul domaine vraiment inattendu.
mwfearnley

Réponses:

32

Chaque version de Windows depuis les noms de fichiers longs où l’on ajoute des noms fonctionne de cette manière à partir de Windows 95 et jusqu’à Windows 7 inclus.

Ce comportement est documenté :

Le paramètre lpApplicationName peut être NULL . Dans ce cas, le nom du module doit être le premier jeton délimité par des blancs dans la chaîne lpCommandLine . Si vous utilisez un nom de fichier long contenant un espace, utilisez des chaînes entre guillemets pour indiquer la fin du nom de fichier et le début des arguments; sinon, le nom du fichier est ambigu. Par exemple, considérons la chaîne "c: \ programmes \ sous-répertoire \ nom de programme". Cette chaîne peut être interprétée de différentes manières. Le système tente d'interpréter les possibilités dans l'ordre suivant:

c:\program.exe files\sub dir\program name
c:\program files\sub.exe dir\program name
c:\program files\sub dir\program.exe name
c:\program files\sub dir\program name.exe

Quant à savoir pourquoi il demande cette façon - afin qu'il ne se casse pas des programmes qui ne peuvent pas gérer les espaces dans les noms de fichiers correctement .

Edit Il semble que la commande "Exécuter" ne se comporte pas comme ceci - il doit y avoir une logique supplémentaire ajoutée pour gérer ce cas précis. Cependant, essayer de fonctionner de n'importe où, y compris en utilisant CreateProcessdirectement la fonction utilisée par la plupart des applications pour exécuter une commande.

Le voir ce comportement en action:

  1. Ouvrir une invite de commande administrative
  2. Courir: copy c:\Windows\System32\notepad.exe c:\program.exe
  3. Courir: c:\Program Files\Internet Explorer\iexplore.exe
  4. Le Bloc-notes s'ouvrira pour vous dire qu'il ne trouve pas Files\Internet Explorer\iexplore.exe
  5. Tapez c:\Program Files\Internet Explorer\iexplore.exedans l'option Exécuter et IE s'ouvrira correctement.

Éditer 2 Dans le cas de votre C:\program files\internet.exeexemple; Je crois que c’est l’interprète de ligne de commande qui gêne. Il tente de traiter et de segmenter la ligne de commande en paramètres séparés par des espaces. Donc, il prend C:\programcomme premier jeton et interprète cela comme nom de programme comme reste comme paramètres.

Pour un test, j'ai créé une petite application qui appelle CreateProcessdirectement et qui se comporte exactement comme indiqué. Votre C:\program files\internet.exeexemple va se lancer C:\program files\internet.exe. Il semble donc que le comportement dépend de la manière dont la commande est exécutée - il se peut que la ligne de commande soit en cours de traitement avant de la transmettre CreateProcess.

Exemple de programme:

#include <Windows.h>

void main()
{
    STARTUPINFO si = {0};
    si.cb= sizeof(si);
    PROCESS_INFORMATION pi = {0};

    CreateProcess(NULL, "c:\\program files\\internet explorer\\iexplore.exe",
            NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi);
}
shf301
la source
1
Voir mon édition pour savoir pourquoi cela ne répond pas à ma question. Vous n’avez testé que la première chose dans l’ordre donné, je parle de la seconde.
Dpatchery
J'ai moi-même fait un peu plus de recherches et je suis d'accord avec votre dernière modification. Il semble que la différence se situe entre cmd.exe et la fonction CreateProcess. Colore moi convaincu!
dépêche
Cette partie ne semble pas correcte: votre exemple C: \ program files \ internet.exe lancera C: \ program files \ internet.exe
Daniel Beck
Selon la CreateProcesspage sur MSDN, cela ne se produit que si le paramètre lpApplicationName est NULL . Sinon, le système utilisera ce paramètre comme programme à lancer et ne cherchera pas à le trouver. Je suppose que la commande "Exécuter" ne fournit PAS de paramètre NULL ici. Par conséquent, elle ne rechercherait pas le programme de cette manière.
Kevin Panko
1
@ shf301 Il utilise réellement ShellExecuteExet appelleCreateProcess
Kevin Panko
5

Je veux juste ajouter quelque chose aux réponses précédentes.

Bien qu'il soit possible de forcer ce comportement par le biais d'efforts, d'une mauvaise programmation (pas de RTFM) ou de la tempête parfaite invérifiable provoquée par ce programme antivirus particulier, rien n'aurait provoqué le comportement décrit dans l'article. En aucun cas un raccourci créé correctement, par exemple un raccourci qui cible "C: \ Program Files \ Microsoft \ Office \ Word.exe", avec les guillemets, n’exécute C: \ Program.exe. Même avec Firefox. Enfer, il est fondamentalement impossible de créer un raccourci qui ne serait pas échappé correctement, car cela est fait intelligemment.

Si vous créez un raccourci sur votre bureau pointant vers Firefox, il sera échappé correctement. Si vous faites un clic droit -> propriétés et essayez de supprimer les guillemets, il les insérera automatiquement lorsque vous cliquerez sur appliquer, même si C: \ Program.exe existe. Quand il analyse cela, je suppose que c'est soit donner la préférence au dossier, soit tout traiter avant le dernier '\' comme faisant partie du chemin. Ce n’est que si vous insérez deux espaces entre Programme et Fichiers qu’il sera analysé comme pointant vers C: \ Program.exe avec des arguments. Si vous pouvez modifier le raccourci dans un éditeur de texte (ce n'est pas du texte en clair), cela peut fonctionner.

Tout comme les raccourcis, la boîte de dialogue Exécuter analyse correctement la chaîne. C’est uniquement dans la console de commande de niveau relativement bas que C: \ Program.exe sera appelé de manière incorrecte, mais les différentes possibilités ne seront pas essayées. C'est-à-dire qu'il essaiera incorrectement d'appeler "C: \ Program.exe" mais n'essaiera pas d'appeler "C: \ Program Files \ Internet.exe" ou quoi que ce soit d'autre, même si ces possibilités existent. Il renverra une erreur indiquant qu'il ne trouve pas C: \ Program.exe.

Et en plus de tout cela, quand il y a un Program.exe dans le dossier C: \, il vous avertira au démarrage et vous demandera si vous voulez le renommer. Cela a été vérifié pour XP, Vista, Windows 7 et je peux maintenant vérifier Windows 8 ( http://goo.gl/eeNCp ). Peut - être que cela était possible dans Windows 9x, mais je doute.

En bout de ligne, cela est évident et aucun programmeur Windows ne commettrait cette erreur.

lordcheeto
la source