Pourquoi un programme nommé «C: \ Program» peut-il influencer d'autres programmes?


16

Aujourd'hui, à l'improviste, un fichier appelé Programest apparu à la racine de C:\, et lors de la connexion au système, une fenêtre contextuelle affiche un message:

Avertissement de nom de fichier

Il existe un fichier ou un dossier sur votre ordinateur appelé "C: \ Program" qui pourrait empêcher certaines applications de fonctionner correctement. Le renommer en "C: \ Program1" résoudrait le problème. Voulez-vous le renommer maintenant?

Alors que le message s'explique de lui-même, je me demande pourquoi ce fichier pourrait avoir une si grande influence? En effet, certains des programmes (peut-être tous, je n'ai pas vérifié) situés dans C:\Program Files...ne démarraient pas du tout. Je peux comprendre comment un tel fichier peut être créé (par exemple, en essayant d'écrire dans un dossier C:\Program Files\Something...mais sans guillemets), mais je comprends à peine comment cela peut-il avoir un impact sur d'autres programmes.


1
Vous êtes sûr que c'était un message généré par Windows?
Ramhound

1
Oui, revérifié à partir de Process Exploer, c'était une boîte de dialogue d'explorer.exe
Konrad Kokosa

2
Cela semble sommaire, aucun programme (en dehors de quelques-uns) ne doit être installé ailleurs que Program Files* pour le consommateur type. Mais je pense que c'est parce qu'un mauvais appariement pour une recherche pourrait trouver cela au lieu de Program Files.
nerdwaller le

Réponses:


27

Il a une telle influence en raison d'une faiblesse connue de longue date dans l'API Win32.

Les programmes sont générés dans Win32 via l' CreateProcess()appel système. Il peut être utilisé de plusieurs manières. Les personnes venant d'horizons Unix, Linux ou OS / 2 penseront généralement que cela prend deux arguments distincts pour que le programme (fichier image) apparaisse et la queue de commande pour passer au nouveau processus, parce que les noms de fichiers et les arguments vecteurs / queues de commande sont deux choses distinctes dans les API de ces systèmes d'exploitation. Mais en fait, l'appel système peut être appelé sous une forme alternative avec le nom du programme et les arguments écrasés dans une seule grande chaîne. CreateProcess()va essayer de séparer le nom de fichier du programme de la queue de commande.

Le problème est qu'il le fait en divisant progressivement la chaîne en deux à chaque caractère d'espace successif, jusqu'à ce que la partie gauche corresponde à un fichier ou un répertoire. De nombreux programmes Win32 essaient de passer des chaînes comme C:\Program Files\Contoso\TakeOver.exe StackExchange.comà l'appel système. Cela exécutera le bon programme - C:\Program Files\Contoso\TakeOver.exe- avec la bonne queue de commande - StackExchange.com- jusqu'à ce qu'une personne manifestement dangereuse arrive et crée un C:\Programfichier comme vous l'avez fait.

À ce stade, l'appel système finit par essayer d'exécuter le fichier image du programme C:\Programavec la queue de commande Files\Contoso\TakeOver.exe StackExchange.com. Heaven vous aide s'il C:\Programs'agit en fait d'une image de programme exécutable.

Il s'agit d'une faiblesse générale et elle s'applique à tout nom de fichier de programme contenant des espaces en combinaison avec tout programme qui utilise One Big String pour générer d'autres programmes. Mais le cas le plus courant qui est touché par cela est tous les programmes qui vivent sous C:\Program Files\et un grand nombre de programmes Win32 qui utilisent l'approche One Big String.

Il est beaucoup trop tard pour changer l'API Win32. Il était trop tard il y a dix ans. Et Microsoft ne peut pas modifier tous les programmes écrits par d'autres personnes qui passent une grosse chaîne au lieu de deux CreateProcess(). Microsoft vérifie donc, à l'ouverture de session de l'utilisateur, l'existence C:\Programet affiche l'avertissement que vous voyez.

Et, comme vous pouvez le voir, il y a un gros avertissement "Sécurité" dans le doco Win32 de Microsoft disant aux développeurs de ne pas écrire de programmes en utilisant l'approche One Big String, qui existe depuis quelques années maintenant.

Lectures complémentaires


6
Excellente réponse! En tant que développeur, la prochaine chose que je ferai sera évidemment de créer un mannequin C:\Program.exequi enregistre tous ses paramètres de ligne de commande. Nous verrons qui l'utilise!
Konrad Kokosa

1
Donc , c'est la raison pour laquelle les paramètres de sécurité par défaut depuis XP ne permettent pas de créer des fichiers dans la racine par des non-admins.
kinokijuf
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.