Messages in this thread |  | | Date | Thu, 07 Sep 2000 01:16:43 -0600 | From | Trevor Harrison <> | Subject | Re: Glad we did not add NTFS stream support |
| |
Jesse Pollard wrote:
> Ummm maybe. A SANS newsletter indicated that none of the current virus scanners > even look at the other data streams (yet).
I attribute that to MS not showing data streams, er, I just call them forks, in Explorer. If users were more aware of forks, and could manipulate them, virus scanners would be on top of it as well.
> Determining if the default stream > is actually infected could be problematical too - consider that the signature > of the virus might be a VERY short piece of code that looks just like other > pieces that do ligitimate functions (like start another process...). This could > give many false positives, making a scan nearly useless.
Yes, it does present cool (from a virus writer's pov) opportunities for hiding data/code, but you could do a similar thing with a regular file system, using multiple files instead of forks in a single file. The code is the same for opening forks vs. regular files, its just that the forks are (currently) hidden from users.
However, this whole thing is about how a virus hides itself on a host. It has to get there first, and forks aren't gonna help it do that, except, I guess, if you recieved binary software on NTFS formatted zip disks or something like that, but that can't be very common.
> > The current NT utilities also have a problem in that a stream could consume > the entire disk, but not be visible to the standard utilities - they don't > list file size of any but the default stream.
Yeah, again, MS being dumb about Explorer.
> > > Of an interesting note: one of the suggested fixes involved copying the > infected file to a "non windows system such as Linux..." (paraphrased.. not > real quote) and then copying it back without the alternate stream(s). > >
I only read portions of the net-security notice. Probably copying it to a FAT drive under NT will do the same thing. If you copy, via Explorer, a file with some forks to a FAT drive, Explore will pop up a little warning telling you that you are going to lose some data.
The other nefarious use of forks is for hiding data, ie. your p0rn collection, or the real version of your financial books that you don't want the IRS to see.
The whole argument a few weeks back on l-k about how to shoehorn forks into the current "way things work" was kinda disapointing. I almost jumped in, but I chickened out.
I was waiting for someone to notice the really nice equivalence between a file system with forks like NTFS, and directories like X.500/LDAP.
Basically, you've got:
leaf objects equate to files branch objects equate to directories
Directory objects have attributes (ie. objecttype=top, surname=Ford, phonenumber=1234567, etc). In a file system, files and directories can have forks (ie. forkname "objecttype", stream stores "top").
Branch objects in a directory can have children. Directories in a file system can have children.
The metaphor probably breaks down at some level, but it's still pretty cool.
I have no idea if its even a good idea to have a file system be more like a directory, but I just couldn't help seeing the similarity and thinking, gee, what if...
-Trevor
ps. My apologies to to Keith Owens for being a little short tempered in my reply. But, yelling the sky is falling because of some anti-virus vendor's vague warning about something as lovely and innocent and unsullied as file system forks just makes me <pressing palm against side to head to make the voices be quiet>maaad</pressing....> :)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |