Why the heck does NTFS allow invisible executables?

You can hide any file inside of another file just by typing:

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

and to run the file hidden file just use:

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

But the crazy part about this is it doesn't increase the size of the file (so it's totally hidden).

And if you delete the file with the hidden stuff inside, the hidden stuff doesn't get deleted. Just use:

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

Why does NTFS allow this? It seems like the best way to hide a virus.

Solution 1:

There are two sides to this question. The first is why does this feature exist at all, and the second is why doesn't the GUI (or the command prompt) make it easier to see and manage the feature.

It exists because it's useful. Several other platforms support multiple data streams per file. On the Mac, they were called forks, for example. I'm reasonably sure that similar things existed in the mainframe world, but can't put my fingers on any explicit examples today.

On modern Windows, it is used to hold extra attributes for a file. You might notice that the Properties box available from Windows Explorer has a Summary tab that in Simple view (I'm on Windows XP, your mileage will differ on the other flavors) includes a bunch of useful fields like Title, Subject, Author, and so forth. That data is stored in an alternate stream, rather than creating some kind of side-car database to hold it all that would get separated from the file too easily.

An alternate stream is also used to hold the marker that says the file came from an untrusted network source that is applied by both Internet Explorer and Firefox on downloads.

The hard question is why there isn't a better user interface for noticing that the streams exist at all, and why it is possible to put executable content in them and worse, execute it later. If there is a bug and security risk here, this is it.

Edit:

Inspired by a comment to another answer, here is one way to find out if your anti-virus and/or anti-malware protection is aware of alternate streams.

Get a copy of the EICAR test file. It is 68 bytes of ASCII text that happens to also be a valid x86 executable. Although completely harmless, it has been agreed by the anti-virus industry to be detected as if it were a real virus. The originators thought that testing AV software with a real virus would be a little too much like testing the fire alarm by lighting the wastebasket on fire...

The EICAR file is:

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

Save it with the extension .COM and it will execute (unless your AV is paying attention) and print a greeting.

It would be informative to save it in an alternate data stream and run a scan...

Solution 2:

This feature is required for a cross platform feature of Windows Server: services for mac.

This allows a windows server running on NTFS share to macs via AFP. For this feature to work, the NTFS file system has to support forks, and it has from day one.

And before you ask, is this feature still used? Yes it is I have it running and in use daily on a server in a client that I support.

The main security issue comes when people and applications forget or don't realize that it is there.

There probably should be an option though to include the forks in the total file size or show them in windows explorer.

Solution 3:

I'd imagine one of the main uses (perhaps even the intended use) would be to transparently allow addition of any kind of meta-data to a file. The reason the file size does not change is in this scenario you do not want the file to look or behave any differently lest the originating application relies on some aspect of the way the file looks.

I could imagine interesting uses in IDEs for example, where sometimes multiple files are involved to form a single unit (code file / form file, etc), which could be attached to the original file in this way so that they cannot accidentally get separated.

I also believe there is a command to find all such 'attachments' in a given directory tree, so they are not actually completely hidden. It also would surprise me if the better virus scanners are not aware of this and check these 'hidden' areas, but you could check that by purposely attaching an infected executable to a text file and seeing if it gets picked up.