Pourquoi diable NTFS autorise-t-il les exécutables invisibles?

Vous pouvez masquer n'importe quel fichier à l'intérieur d'un autre fichier simplement en tapant:

type sol.exe > container.txt:sol.exe

et pour exécuter le fichier fichier caché, utilisez simplement:

start c:\hide\container.txt:sol.exe

Mais la partie folle à ce sujet est que cela n’augmente pas la taille du fichier (donc, il est totalement caché).

Et si vous supprimez le fichier contenant les éléments cachés, ceux-ci ne sont pas supprimés. Il suffit d'utiliser:

more <  container.txt:sol.exe > sol.exe

Pourquoi NTFS autorise-t-il cela? Cela semble être le meilleur moyen de cacher un virus.

Il y a deux côtés à cette question. La première est pourquoi cette fonctionnalité existe et la seconde est pourquoi l'interface graphique (ou l'invite de commande) ne facilite pas la visualisation et la gestion de la fonctionnalité.

Cela existe parce que c'est utile. Plusieurs autres plates-formes prennent en charge plusieurs flux de données par fichier. Sur le Mac, on les appelait des fourchettes , par exemple. Je suis raisonnablement sûr que des choses similaires existaient dans le monde du mainframe, mais je ne peux pas mettre la main sur des exemples explicites aujourd'hui.

Sous Windows moderne, il est utilisé pour conserver des attributs supplémentaires pour un fichier. Vous remarquerez peut-être que la boîte de dialogue Propriétés disponible dans l'Explorateur Windows contient un onglet Résumé qui, dans la vue Simple (je suis sous Windows XP, votre kilométrage variera selon les variantes), comprend une série de champs utiles tels que Titre, Objet, Auteur et etc. Ces données sont stockées dans un autre flux, plutôt que de créer une sorte de base de données side-car pour stocker toutes les informations qui seraient trop facilement séparées du fichier.

Un autre flux est également utilisé pour contenir le marqueur indiquant que le fichier provient d'une source réseau non approuvée appliquée à la fois par Internet Explorer et Firefox lors des téléchargements.

La question difficile est de savoir pourquoi il n’existe pas de meilleure interface utilisateur pour constater l’existence des flux, et pourquoi il est possible d’y insérer du contenu exécutable et, pire, de l’exécuter ultérieurement. S'il y a un bug et un risque de sécurité ici, c'est ça.

Modifier:

Inspiré par un commentaire à une autre réponse, voici un moyen de savoir si votre protection anti-virus et / ou anti-programme malveillant prend en compte des flux alternatifs.

Obtenez une copie du fichier de test EICAR . Ce sont 68 octets de texte ASCII qui sont également des exécutables x86 valides. Bien que totalement inoffensif, le secteur des antivirus a décidé de le détecter comme s'il s'agissait d'un véritable virus. Les concepteurs pensaient que tester un logiciel antivirus avec un vrai virus ressemblerait un peu trop à tester l’alarme incendie en allumant la corbeille à papier ...

Le fichier EICAR est:

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

Enregistrez-le avec l'extension .COMet il s'exécutera (à moins que votre AV ne prête attention) et affichera un message d'accueil.

Il serait utile de l'enregistrer dans un autre flux de données et de lancer une analyse ...

Cette fonctionnalité est requise pour une fonctionnalité multiplate-forme de Windows Server: services pour mac.

Cela permet à un serveur Windows fonctionnant sur un partage NTFS de partager des macs via AFP. Pour que cette fonctionnalité fonctionne, le système de fichiers NTFS doit prendre en charge les fourches depuis le premier jour.

Et avant de vous demander, cette fonctionnalité est-elle toujours utilisée? Oui, je le fais tourner et je l'utilise quotidiennement sur un serveur d'un client que je supporte.

Le principal problème de sécurité survient lorsque les utilisateurs et les applications oublient ou ne réalisent pas qu’il existe.

Il devrait probablement y avoir une option permettant d’inclure les forks dans la taille totale du fichier ou de les afficher dans l’explorateur Windows.

J'imagine qu'une des utilisations principales (peut-être même l'utilisation envisagée) serait de permettre de manière transparente l'ajout de n'importe quel type de métadonnées dans un fichier. La raison pour laquelle la taille du fichier ne change pas est que, dans ce scénario, vous ne souhaitez pas que le fichier apparaisse ou se comporte différemment, car l'application d'origine s'appuie sur un aspect de l'apparence du fichier.

Je pourrais imaginer des utilisations intéressantes dans les IDE, par exemple, où plusieurs fichiers sont impliqués pour former une seule unité (fichier de code / fichier de formulaire, etc.), qui pourraient être attachés au fichier d'origine de cette manière afin d'éviter toute séparation accidentelle.

Je pense également qu’il existe une commande permettant de rechercher toutes ces "pièces jointes" dans une arborescence de répertoires donnée, afin qu’elles ne soient pas complètement masquées. Cela me surprendrait également si les meilleurs scanneurs de virus ne sont pas conscients de cela et vérifient ces zones "cachées", mais vous pouvez le vérifier en attachant volontairement un fichier exécutable infecté à un fichier texte et en vérifiant si celui-ci est détecté.

Voici un bon article sur la faille de sécurité potentielle posée par les autres flux de données .

Bonne question, je ne connaissais pas bien ADS jusqu'à l'année dernière et je suis développeur Windows depuis de nombreuses années. Je peux vous garantir que je ne suis pas seul à ce sujet.

En ce qui concerne la possibilité de rechercher d’autres données sur des fichiers, j’ai trouvé le petit outil utile appelé Lads, disponible dans le logiciel Frank Heyne. Il peut répertorier les ADS sur tous les fichiers d'un répertoire donné, même sur des fichiers cryptés (et également dans des sous-répertoires).